MVCCとInnoDBでの実装について - shallowな暮らし
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
TCPパケットを解析して構造化ログでダンプするツール tcpdp を作った - Copy/Cut/Paste/Hatena
やっと形になってきました。 github.com 「データベースのクエリログを取得したい」 例えば、データベース（RDBMS）のクエリログを取得したいとき一番確実な方法は、そのRDBMSに備わっているログ機構を利用することです。 一方で、全てのクエリログを出力するとなるとそれなりにIO負荷がかかることが予想されるので、負荷状況によってはクエリログ出力（のIO負荷）を別サーバに分離したくなります。 では、どうすればよいかというと、例えば アプリケーションサーバとデータベースサーバの間にプロキシサーバを挟んでそこで記録することでIO負荷を分離する アプリケーションサーバ側で（notアプリケーションで）記録することで（大抵、サーバ台数の多い）アプリケーション側にIO負荷を分散する というような方法を思いつきます。 そこで、「もし、TCPコネクション上に流れている（例えば）クエリログを解析してログ
How to sync your MySQL data to Elasticsearch
I have been using MySQL for many years. The performance is very very high in many scenarios, but not in full-test search or some sophisticated query. I considered introducing Sphinx to solve the problem before, but gave up quickly because I found it was not easy for me to learn and use Sphinx (or maybe I was too lazy at that time :simle: ). Luckily, I met Elaticsearch(ES). ES uses Lucene to supply
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というバージョン番号を引っさげ、満を持しての登場となった。その
Rails Developers Meetup 2018 で「MySQL/InnoDB の裏側」を発表しました
Rails Developers Meetup 2018: Day 1 で「MySQL/InnoDB の裏側」と題して SELECT クエリの実行フローや InnoDB のインデックス周りの発表しました。MySQL with InnoDB のインデックスの基礎知識とありがちな間違い + α の内容です。 Nested Loop Join のスライドは無理やり差し込んだ感が溢れてますがご了承ください＞＜ 追記: 動画も公開されたので貼り付けておきます。1 key_len について発表で全然触れなかったんですが、重要な内容なので次のエントリーにまとめました。 MySQL で複合インデックスを作成する際には必ず key_len を確認すべきという話 補足 サンプルデータ MySQL のサンプルデータとしては world や employee が有名だと思うんですが、前々から world は物足り
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
オーロラは雲の上 — RDBのScalabilityとAvailability | DevelopersIO
Amazonは、なぜ、Aurora（オーロラ）という名前をつけたのだろう？ 僕は、どこかで見かけた、「それは、オーロラは雲（Cloud）の上にあるからさ」という一節が、とても気に入っている。 まさに、Auroraの最大の特徴は、Amazonのクラウド・サービスの上に構築されたデータベースであるというところにある。小論では、クラウド上（「雲の上」）のデータベースであるAuroraが、どのようにクラウドの機能を利用しているのかを、そのScalabilityとAvailabilityに焦点を合わせて紹介しようと思う。 AuroraのScalabilityとAvailability まず最初に、Auroraの主要なScalabilityとAvailabilityを確認しておこう。 Push-button Compute Scaling：コンソール画面で数クリックするだけで、CPU数・メモリーサイズ
第8回 MySQLのバージョン体系を知る | gihyo.jp
第6回 mysqlコマンドラインクライアントにページャーを指定するの際にも少しだけ触れましたが、去る2015/10/21、MySQLの最新版となるMySQL 5.7が製品リリースされました。筆者が執筆してきた第2回、第4回、第6回ではそれぞれ、第2回の執筆時に「MySQL Yum Repositoryを導入し、執筆時点で最新のmysql-community-server-5.6.26-2.el6.x86_64をyumコマンドでインストール」したものを利用していました。 今回はそれらをMySQL 5.7にアップグレードする方法と、「MySQL 5.6から5.7ってマイナーバージョンアップじゃないの？」「GA（General Availability）とかRC（Release Candidate）とか一体何なの？」というバージョンにまつわる説明をしたいと思います。 MySQLのバージョンに
MySQLのbinlogを使ってSSPの配信設定反映を40倍速くした話 - GENIEEエンジニアブログ
はじめに こんにちは、R&D本部アドプラットフォーム開発部の村岡です。 九州工業大学の先端情報工学専攻を予定通り修了してジーニーに17卒入社し、現在は主にGenieeSSPの開発を行っています。 以前こちらの記事を書きましたが、今回もMySQL関連の記事となります。 GenieeSSPについて GenieeSSPは、広告配信のレスポンスタイムを短くするために、数十万の広告枠の配信設定をすべてインメモリで保持しています。 全広告枠の配信設定はMySQLに保存されています。配信設定を変更する、つまりDBのデータを変更する方法は、現在の運用では4つあります。 営業担当や、広告運用チームなどが操作画面を使って更新する。 操作画面では対応できない場合などに、エンジニアの運用チームが手作業で更新する。 配信パラメータ最適化のためのバッチが更新する。 リリース時などにエンジニアが権限をもらって更新する（
VOYAGE GROUP エンジニアブログ : MySQL InnoDBのinsertとlockの話
2015年03月08日17:06 カテゴリ MySQL InnoDBのinsertとlockの話 こんにちは。ECナビでアプリケーションエンジニアをやっている駒崎です。 今回はMySQLのInnoDBエンジンにおけるINSERTとロックの挙動について書きたいと思います。 はじめに アプリケーションでレコードの重複チェックをしてからINSERTをする。テーブルにはUNIQUE制約をかけてデータ不整合が起きないようにしている。という仕様はよくあるケースだと思います。 こういったケースでINSERTしたときにどのような仕組みが働いて重複データを防いでいるのだろう？アプリケーションで重複チェックをしてはいるけどMySQLではどんな挙動をしているんだろう？というのが気になったので調べました。 調べること INSERTした場合のロックの挙動 FOR UPDATE文で排他ロックをかけた場合のロックの挙動
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://developer.hatenastaff.com/entry/2019/01/15/120431
GitHub - schemalex/schemalex: Generate difference sql of two mysql schema