タグ

mysqlに関するt-wadaのブックマーク (81)

  • MySQL 8.0登場!立ち止まることを知らない進化はこれからも続く。

    ゴールデンウィークはいかがお過ごしされただろうか。今年は天気も良く、行楽日和が続いたように思う。 さて、先日MySQL 8.0が正式にリリースされた。少し時間が経ってしまったが、今回はMySQL 8.0の新機能について紹介したい。コミュニティ版のダウンロードはこちらから可能だ。 ひとつ前の正式バージョンはMySQL 5.7だったのだが、MySQL 8.0は非常に大きなリファクタリングが含まれており、5.x台のバージョン番号を捨て去ろうという話があった。そこで、次のメジャーバージョンは最初の桁を増やすということになったのだが、MySQL 6.0は過去に既に存在し、買収などの騒ぎで開発が頓挫してしまった経緯がある。7.xはMySQL NDB Clusterと被っている。というわけで、5.7の7の部分の次という意味合いもあって、8.0というバージョン番号を引っさげ、満を持しての登場となった。その

    MySQL 8.0登場!立ち止まることを知らない進化はこれからも続く。
    t-wada
    t-wada 2018/05/07
    祝MySQL 8.0リリース!とうとうCTEが正式にサポートされたので、『SQLアンチパターン』の「ナイーブツリー」はもうアンチパターンではなくなりました。
  • MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ

    こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの?」みたいな経験はありませんか?不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、

    MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
    t-wada
    t-wada 2017/04/20
    とても分かりやすい。「ここを読んでおいて」と言えるエントリ。
  • 寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst

    これまでのMySQLでよく問題になった、絵文字や日語の文字の照合やソート順序の問題に関して、来たるMySQL 8.0では大幅な改善が加えられる予定になっている。この問題の概要と今後の改善方針について、MySQL開発チームからの解説。 免責事項 この記事はManyi Lu氏によるMySQL Server Blogの投稿「Sushi = Beer ?! An introduction of UTF8 support in MySQL 8.0」(2017/1/13)をユーザが翻訳したものであり、Oracle公式の文書ではありません。 MySQL 8.0での私たちの計画として、utf8のサポートを大幅に改善します。utf8サポート自体はMySQL 4.1の頃にさかのぼりますが、いくつかの制限が存在しています。記事タイトルにもある「寿司 = ビール」問題は、バグ#76553のことを指しています。少

    寿司=ビール問題 : MySQL 8.0でのUTF8サポート入門 (MySQL Server Blogより) | Yakst
    t-wada
    t-wada 2017/01/25
    寿司ビール問題を MySQL 開発チーム(ここ重要)が解説した エントリの翻訳
  • MySQL 8.0 Lab版: MySQLの (再帰)共通テーブル式(CTE) | Yakst

    免責事項 この翻訳は MySQL Server Blog の 記事 をユーザーが翻訳したものであり、Oracle公式の翻訳ではありません。 MySQL開発チームはこのたび Lab版 のMySQLサーバーをリリースしました("MySQL Server 8.0.0 Optimizer" として公開されています) 私が開発したこのリリースの特徴的な機能は (再帰)共通テーブル式…(再帰)CTE, (再帰)サブクエリー処理, WITH [RECURSIVE] 句としても知られています…です。 3年前、私はCTEをエミュレートする方法を ブログ で紹介しました。しかし、MySQLは今や物のCTEを備えました。偽物ではなく! これはこの新機能の全ての詳細を紹介するブログポストの最初の一つです。 派生テーブルはFROM句のサブクエリーです。下記の太字の部分がそれにあたります。 SELECT … FRO

    MySQL 8.0 Lab版: MySQLの (再帰)共通テーブル式(CTE) | Yakst
    t-wada
    t-wada 2016/10/27
    MySQL にもとうとう、ようやく CTE (共通テーブル式) が来る。再帰 SQL が書けるぞ!!
  • Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果

    Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果 FacebookはMySQL用の新しいストレージエンジン「MyRocks」をオープンソースで公開しました。同社のエンジニアである松信嘉範(Yoshinori Matsunobu)氏がFacebookのブログに投稿した記事「MyRocks: A space- and write-optimized MySQL database」で紹介しています。 MySQLのデータベースエンジンとして使われているInnoDBは優れているものの、フラッシュストレージと組み合わせたときに書き込まれるデータ量の効率性などに課題があったため、MyRocksに取り組んだと説明されています。 InnoDB is great for performance and reliabil

    Facebook、新しいMySQL用ストレージエンジン「MyRocks」をオープンソースで公開。フラッシュに適したデータの書き込みと圧縮効果
    t-wada
    t-wada 2016/09/02
    おおお松信さん相変わらず凄い
  • 第7回 UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く | gihyo.jp

    IT Cutting Edge ─世界を変えるテクノロジの最前線 第7回UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く デジタルディスラプションを象徴する企業として、いまこの瞬間も破竹の勢いで成長を続け、交通サービスの世界を大胆に塗り替えているUber。未上場ながらすでに企業価値は6兆円を超えているとも言われており、世界最大のユニコーン企業として、その動向はつねに注目されつづけています。 クラウドやビッグデータ分析、オープンソースなど、最先端のITをフル活用し、ごく短期間で劇的にビジネスを拡大させたUberに対しては、やはり技術者からの強い関心があつまります。現在、1200名を超えると言われるUberのエンジニアたちは何をどんな環境で使い、どう動かしているのか ―Uberのエンジニアリングチームが公開している技術ブログ「Ub

    第7回 UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く | gihyo.jp
    t-wada
    t-wada 2016/08/08
    "PostgreSQLに対する勉強不足でうまくいかなかったので,あまり深く考えずにまたMySQLに戻してみたら,たまたま彼らのユースケース(NoSQLっぽい使い方)にはMySQLが合っていた,ということなのではないか"
  • 【翻訳】 On Uber’s Choice of Databases (データベースにおけるUberの選択について)

    数日前、Uberのブログで「Why Uber Engineering Switched from Postgres to MySQL」というエントリが公開されました。 Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog https://eng.uber.com/mysql-migration/ それに対して、PostgreSQLコミュニティ界隈でもいろいろなブログエントリが公開されました。 Robert Haas: Uber's move away from PostgreSQL http://rhaas.blogspot.jp/2016/08/ubers-move-away-from-postgresql.html On Uber’s Choice of Databases http:/

    【翻訳】 On Uber’s Choice of Databases (データベースにおけるUberの選択について)
    t-wada
    t-wada 2016/08/05
    UberはPostgreSQLをMySQLでリプレースしたのではなく、MySQL/InnoDBの上に構築した独自データベースでPostgreSQLを置き換えた。しかし読者の頭の中に残るのは「PostgreSQLがひどい」でアンフェアだという主張
  • 書籍発行のお知らせ:詳解MySQL 5.7 〜進化したMySQLをよく知るためのテクニカルガイド〜

    既に昨日のdb tech showcaseのスライドでご存じの方も多いだろうが、この度MySQL 5.7の新機能を解説するための書籍を発行させていただくこととなった。8月23日発売予定である。 MySQL 5.7の新機能については、これまでブログでは紹介してこなかった。というのも、あまりにもボリュームが多すぎて、ブログという媒体でカジュアルに紹介するには向いていないと思ったからだ。とはいえ、MySQL 5.7を皆さんに使っていただくには、誰かが新機能をしっかりと解説しなければならない。どうするべきか考えた結果、書籍としてまとめて出させていただくことになった。 新機能について真面目に解説しようとすると、新しいポイントがどこなのかということを言及するために、結局のところ元々の機能についてもある程度解説が必要になってしまう。そういうわけで、この書籍では、MySQLが持つ機能の基的なコンセプトや

    書籍発行のお知らせ:詳解MySQL 5.7 〜進化したMySQLをよく知るためのテクニカルガイド〜
    t-wada
    t-wada 2016/08/04
    "「MySQL 5.7は良くなっているらしいが、一体何がどう良くなってるの?」「性能が上がってるらしいけど、何がどう変わったの?」といった疑問をお持ちの方は、ぜひ本書を手に取っていただきたい" 読むしかない
  • gh-ost: GitHub's online schema migration tool for MySQL

    AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be

    gh-ost: GitHub's online schema migration tool for MySQL
    t-wada
    t-wada 2016/08/03
    GitHub 社が自社サービスで運用し、OSS で公開した MySQL のオンラインスキーマ変更ツールの解説。従来のツールとの違いはトリガーを使わないこと。そのため一時停止や流量制御、テスト等も可能になる。
  • Designing Schemaless, Uber Engineering's Scalable Datastore Using MySQL

    While all three systems are able to scale linearly by adding new nodes online, only a couple systems can also receive writes during failover. None of the solutions have a built-in way of notifying downstream dependencies of changes, so we would need to implement that at the application level. They all have indexes, but if you’re going to index many different values, the queries become slow, as the

    Designing Schemaless, Uber Engineering's Scalable Datastore Using MySQL
    t-wada
    t-wada 2016/07/27
    Uber が MySQL 上に構築したデータストア "Schemaless is an append-only sparse three dimensional persistent hash map, very similar to Google’s Bigtable"
  • UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた

    Uber-migrated-pg-to-mysql.md Why Uber Engineering Switched from Postgres to MySQL - Uber Engineering Blog のまとめ Posgresqlだと pgは追記型なので少しの更新でも多くのdiskへのwriteがおきる カラムを一つ更新しただけで多くのindexの書き換えが起こる よって、replicationはWALを送るので更新が多いとWALが大量に送られる repcliationでは物理的なdiskの変更を送る DC間でレプリするときつい bugがあってreplica間でMVCCの不整合が起きる masterとreplica同じdisk上のデータ構成を共有するのでupgradeがつらい cache readはsyscallとosのpage cache経由なので重い 1コネクション1プロセス

    UberのPostgresqlからNoSQL on MySQLへの移行を読んでざっくりまとめた
    t-wada
    t-wada 2016/07/27
    Uber が PostgreSQL から MySQL 上に構築した独自データストア(Schemaless) へ移行した理由の部分を簡潔にまとめている
  • Why Uber Engineering Switched from Postgres to MySQL

    We’ve represented the old version in red and the new row version in green. Under the hood, Postgres uses another field holding the row version to determine which tuple is most recent. This added field lets the database determine which row tuple to serve to a transaction that may not be allowed to see the latest row version. With Postgres, the primary index and secondary indexes all point directly

    Why Uber Engineering Switched from Postgres to MySQL
    t-wada
    t-wada 2016/07/27
    Uber がシステム規模の拡大に従って PostgreSQL から MySQL 上に構築した独自のスケーラブルなデータストアに移行するに至った背景について
  • バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い

    2. 2 自己紹介+所属会社紹介 • 渡部 亮太(わたべ りょうた) – JPOUG 共同創設者、ボードメンバー – Oracle ACE – 著書「プロとしてのOracleアーキテクチャ入門 [第2版]」 「プロとしてのOracle運用管理入門」 – ブログ「コーソルDatabaseエンジニアBlog」 http://cosol.jp/techdb/ • 株式会社コーソル – 「CO-Solutions=共に解決する」の理念のもと、Oracle技術に特 化した事業を展開中。心あるサービスの提供とデータベースエン ジニアの育成に注力している – 社員数: 131名 (2016年7月時点) – ORACLE MASTER Platinum 11g 取得者数 45名 ORACLE MASTER Platinum 12c 取得者数 28名 (現時点でおそらく)取得者数 日 No.1

    バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
    t-wada
    t-wada 2016/07/22
    バックアップ、リストア、リカバリの各段階におけるデータの一貫性の観点から、 Oracle, MySQL, PostgreSQL の仕組みを比較する資料。面白い。
  • Oracle Announces General Availability of MySQL 5.7

    Oracle Announces General Availability of MySQL 5.7 New version of the world’s most popular open source database is up to 3x faster than MySQL 5.6 in benchmark tests Redwood Shores, Calif.—Oct 19, 2015 Oracle today announced the general availability of MySQL 5.7, the latest version of the world’s most popular open source database. The new version delivers greater performance, scalability and manage

    t-wada
    t-wada 2015/10/20
    MySQL 5.7 GA キター!
  • AWS Solutions Architect ブログ

    こんにちは。ソリューションアーキテクトの下佐粉(しもさこ)で す。 先日(7/31)のお昼に緊急開催したAWS Black Belt Tech Webinar では RDSの新しいデータベースエンジン Amazon Auroraの解説を行いました。 これまでプレビューだったAuroraが一般公開(GA)された直後とあって、告知からあまり日にちが無かったにも関わらず非常に沢山の方にご参加いただきました。スライド資料を以下に公開しますので、見逃した方もぜひ参考になさってください。 Q&Aも非常に活発でした。時間の範囲お答えさせていただきましたが、それでも答えきれなかったご質問も多かったので、このエントリの後半にQ&Aをまとめています。こちらもぜひご参照ください。 次回のBlackbeltは8/5(水)18時から、AWSのNoSQL型データベースサービスであるDynamoDBについて解説します。

    t-wada
    t-wada 2015/09/14
    Amazon Aurora に関する講演資料と Q&A
  • ついに解禁!Amazon Aurora徹底検証!

    4. Masashi Terui @ marcy_terui I’m a developer and architect in the operators company (JIG-SAW Inc.) I'm the organizer on the some of events in sapporo with the theme of "Infrastructure as Code”. I’m a AWS Certified DevOps Engineer Professional. I’m a member of JAWS-UG Sapporo and GCPUG Sapporo (Coming soon!) I’m the winner of “Tuningathon 5” (The theme was MySQL!) ABOUT ME 4

    ついに解禁!Amazon Aurora徹底検証!
    t-wada
    t-wada 2015/09/11
    いろいろ謎に包まれていた Amazon Aurora のことがよく分かる資料
  • 論理削除Casual Talks #ronsakucasual でMySQLで論理削除する話をしてきた

    論理削除 Casual Talks #1 : ATND に行ってきました。 アプリケーション方面では色々あるし、DBAから見ても良いことはないはず…と思ってましたが、 *ちゃんとMySQLの都合に沿ってやれば* 意外と忌避する理由もないことにふと気付きました。途中で3回くらいテーマ変更して最終的にこの形に落ち着いたカタチです。はふん。 ごめんなさい、当日流していたスライドに致命的な誤り(5.5以降ではなく、5.5以降 *ではない*)がありました。。まとめてくれた方ごめんなさい…>< DBAっぽく、という背景があったので、「論理削除? それUPDATEじゃん」というのが割と前提にあります。「DELETEじゃなくてUPDATEなんだから、削除とか言わずにスーパー非表示フラグでいいじゃん、システム的に *ちゃんとMySQLの都合に沿ってやれば* はそこまで変わらないし」というのが個人の見解です。

    t-wada
    t-wada 2015/09/01
    "スーパー非表示フラグ" "boolだと必ず"="演算子の等価比較に持ち込める" "カーディナリティーがどうこうというより必ず全てのセカンダリーインデックスの先頭につけろでないとインデックスだけで完結できないぞ"
  • AWS News Blog

    New — File Release for Amazon FSx for Lustre Amazon FSx for Lustre provides fully managed shared storage with the scalability and high performance of the open-source Lustre file systems to support your Linux-based workloads. FSx for Lustre is for workloads where storage speed and throughput matter. This is because FSx for Lustre helps you avoid storage bottlenecks, increase utilization of compute

    t-wada
    t-wada 2015/07/29
    AWS 肝いりの MySQL 互換 DB がついに来た (Tokyo リージョンはまだ)
  • RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita

    "Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に

    RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
    t-wada
    t-wada 2015/07/22
    MySQL の Nested Loop Join について詳しく解説
  • kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々

    インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0

    kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
    t-wada
    t-wada 2015/07/21
    "我々は何故2015年にもなってSELECTして無かったらINSERTする場合のベストパターンを確立できていないのか"