サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
bizstation.hatenablog.com
前回のブログ「MySQL/MariaDBとTransactdのInnoDBロック制御詳細」で、「ロックなし読み取りと更新の混在に注意」と書きましたが、「更新前の値を条件で指定したUPDATEやDELETEは問題ないと思うが心配だ」という質問をいただきました。そこで今回は、UPDATEとDELETE文のInnoDBロックについて説明したいと思います。とは言っても、ロックの内容については既に説明済なので、更新処理の内部ロジックについて説明します。それが今回の質問の答えでもあります。 更新前の値をWHERE句で特定した更新 更新前の値をWHERE句で特定した更新の例としては、statusを1から2に変更して状態遷移させるような更新があります。たとえば以下のようなSQL文です。 UPDATE user SET status = 2 WHERE id = 1 and status = 1; ポイント
2016年12月22日にTransactd PHP ORMをリリースしました。 これはTransactdを使用したMySQL/MariaDB用のORMライブラリです。 今回はこのTransactd PHP ORMを紹介します。 Contents 主な特徴 高速なDBアクセス 省メモリ 高スループット 高可用性 自在なトランザクションとロック、スナップショット 詳細なドキュメント 欠点 詳細 ORMインターフェース リレーションのロードタイミング インピーダンスミスマッチ モデルのキャッシュ IDEのコード補完支援 プロパティアクセス速度 複雑なデータベース処理 まとめ 主な特徴 高速なDBアクセス Transactd PHP ORMは、ORMでありながらPDOを直接使用したアクセスよりも高速なデータアクセスができます。 下図は、TransactdとPDO、Laravel EloquentO
今回は、MySQL/MariaDB GTID レプリケーションの詳細を説明します。これは、Transactdによるレプリケーションセットアップ(修復)ツールを構築する際に調べたものです。 主に従来のバイナリログとポジションを使ったレプリケーションとGTIDによるレプリケーションの違いについて説明します。ある程度従来のレプリケーションのセットアップなどを理解していることを前提にしています。 Index なぜGTIDが必要なのか GTIDが活きるシナリオ GTIDによるポジションの解決 具体的なGTID GTIDを使うための設定 MariaDBでGTIDを使う 2つのGTIDポジションモード 新規セットアップ スレーブで、マスターを新マスターに切り替える ダウンしたマスターをスレーブ群に加える SQLスレッドのエラーを修復する MySQLでGTIDを使う GTIDセット GTIDセットの表現方
ようやく24コアのマシンでTransactdのベンチマークを取ることができました。 Xeon E5-2697 V2 2.7GHz 24コア48スレッドの物理マシンです。32または36コアでできれば良かったのですが、お借りできたこのマシン*1でベンチマークを行いました。 結果はタイトルの通りで、パフォーマンスの改善されたMySQL 5.7.7にて驚きの117万QPSを記録しました。 以下はその結果グラフです。横軸がクライアント数、縦軸が1秒間に処理したクエリー(読み取りレコード)数です。 memcached-pluginなどと基本的な考え方は同じですので、100万QPSを出すには48コア位は必要かと思っていましたが、24コアでこの値には少し驚いています。 MySQL 5.6.20でも87万QPSを出しました。5.7の結果が良いので5.6が少なく見えますが、24コアで87万QPSは好結果です。
前回の MySQL/MariaDBとTransactdのInnoDBロック制御詳細 その1 - BizStationブログ では、InnoDBのロックの詳細について説明しました。 今回は、TransactdのトランザクションにおいてInnoDBのロックをどう扱うかを説明します。Transactdは、InnoDBロックを自在に操って同時実行性を高めることができます。 ロック制御は、マルチスレッドプログラミングとmutex lockなどの制御とよく似ています。これらを扱ったことがあるようでしたら、Transactdのロック制御はとてもやり易く感じると思います。 書き込みにおけるパフォーマンスの確保には、ロックを最小限にし同時実行性を高めることが不可欠です。ミッションクリティカルなアプリケーションもパフォーマンスの良いものにしましょう。 Transactdのロック制御 TransactdのAPI
昨日のブログ記事のアクセスが想像以上に多く、とても驚いています。 この中で、REPEATABLE-READのトランザクションで、「ロックなし読み取りした値を元に更新してはいけない」と書いたのですが、具体的なサンプルを入れていなかったので、ここで紹介したいと思います。 REPEATABLE-READにならないトランザクションを試す 更新 (update)よりも、Insertの方がより驚きがありますので、Insertで示します。 まずは前準備です。MySQLのコマンドプロンプトを開いて、以下のSQLでデータベースとテーブルを用意します。 CREATE DATABASE test1; USE test1; CREATE TABLE `test1`.`test1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `field2` int(11) NOT NULL,
今回から数回にわたり、TransactdのオペレーションとInnoDBにおけるロックについて解説します。 ロックについてはあまり良くわからなくてもとりあえずそれなりに動くアプリケーションは作れてしまいます。ですが、マルチユーザー環境でミッションクリティカルなアプリケーションを書くには、ロックの理解が不可欠です。ロックをうまく使って、矛盾や間違いのない読み書きをしつつ同時実行性も高いアプリケーションにしましょう。 その1では、Transactdを実装する上でMySQLのソースやドキュメントから得た知見を基に、InnoDBのロックの種類と分離レベルに応じてそれをどのように使うかをまとめてみます。 Index MySQLのトランザクション関連用語 MySQLのREPEATABLE-READ InnoDBのロック 行ロック (row-level locking) GAPロック GAPロック単体 ネ
前回はselect * from tablename where fieldname = xxxのfieldnameをキーセグメントの先頭に持つインデックスがない場合を書きました。今回は、インデックスがある場合です。 MySQLでfieldnameフィールドのインデックスがある場合 今回の例は条件式が一つですので簡単です。MySQLはまず、レコードバッファ内のfieldnameフィールドの位置にキー値(xxx)をセットしてhandler::ha_index_read_map(HA_READ_KEY_EXACT)を呼び出します。 レコードがなければ(エラーならば)検索終了です。レコードが存在する場合、uniqueキーでなければhandler::ha_index_next_same()をエラーになるまで繰り返し呼び出し、順次レコードを取得します。 handlerでアクセスしたレコード数は、fi
その2はselect * from tablename where fieldname = xxxです。長くなるのでまずは2の1から。 なんとも簡単なSQL文ですが、テーブルの定義やデータの状況によって全くパフォーマンスが異なってきます。 使用するインデックス解析 MySQLはまずSQL文を解析し、fieldnameフィールドをキーセグメントの先頭に持つインデックスが存在するか調べます。存在すれば、そのインデックスを使用したオペレーションhandler::ha_index_read_map(HA_READ_KEY_EXACT)を使い操作を組み立てます。無ければ、hanndler::ha_rnd_next()かhandler::ha_index_next()を使ったレコードスキャンをします。 実は、このインデックスの選択と、handler::ha_index_read_map()オペレーショ
よく、SQLが遅いといった話を耳にしますが、サーバー側がどう処理して遅いのかまで書いたものがあまり見当たらないので、Transactdの開発経験を生かし、その使い方と合わせて書いてみたいと思います。 MySQLは、プラガブルデータベースエンジンという仕組みでさまざまなデータベースエンジンを利用できるようになっています。その内部は、データベースエンジンの操作インターフェースを定義してエンジンごとに実装をするというC++のポリモーフィズムを利用したものとなっています。インターフェースはclass handlerで定義され、SQLの解析結果からhandlerインターフェースのメソッドを組み合わせて実行し結果を得ます。 これからサーバー側の内部の説明をしてゆきますが、各エンジンごとの詳細ではなく、主にhandlerインターフェースの操作レベルの話になります。SQLのパフォーマンスで最も重要なのは内
このページを最初にブックマークしてみませんか?
『bizstation.hatenablog.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く