ようやく24コアのマシンでTransactdのベンチマークを取ることができました。
Xeon E5-2697 V2 2.7GHz　24コア48スレッドの物理マシンです。32または36コアでできれば良かったのですが、お借りできたこのマシン*1でベンチマークを行いました。

結果はタイトルの通りで、パフォーマンスの改善されたMySQL 5.7.7にて驚きの117万QPSを記録しました。
…

まもなくリリースされるTransactd 2.1は、2.0に比べてクエリーの速度が大幅に高速になります。

SQLより高速なクエリー

2.1ではJoinなどに関する処理を徹底的に見直し、SQLを凌ぐクエリーレスポンスを実現しました。

TransactdのJoinを含むクエリーは、テーブルごとにクライアントからリクエストを送信するため、サーバー側ですべてを処理して結果を返す …

Transactdの開発過程でMySQLのパフォーマンス問題を調べてみたところ、ほとんどは「クエリーが遅い」といった問題のようでした。また、NoSQLデータベースへの移行理由としても「MySQLが遅いから」といった意見が結構あります。しかし、そのような理由でMySQLからNoSQLに移行しようとしているのなら、「ちょっと待った」です。（他の理由なら別ですが。）

NoSQLに移行すれば何もかもがバラ色というわけではありません。本当に移行する必要があるか、これを読んで考えてみてください。

TransactdはNoSQLですが、 …

ほとんどのNoSQLは、容易なスケーリングと、アクセス頻度の高い処理の高速化を目的として使われます。今回はTransactd 2.0について、スケーリングがどのように実現されるか書きたいと思います。

1. なぜNoSQLか？(SQLの欠点) テーブル間の依存

スケールアウトは、データを分割し別のサーバーに移動することで負荷を分散させます。SQLの場合、特にJOINは、サーバー内でデータを連結するため、あるテーブルだけ外部に移動するといったことができません。この欠点を回避するために、SQLにも関わらずJOINを禁止するといった使い方をするところもあるようです。

…

その３は、select * from tablename where fieldname in(a,b,c...)です。
IN句による検索ですが、前回までと同じようにMySQLの処理とtransactdでの処理を見ていきましょう。

使用するインデックス解析

MySQLはまず …

前回はselect * from tablename where fieldname = xxxのfieldnameをキーセグメントの先頭に持つインデックスがない場合を書きました。今回は、インデックスがある場合です。

MySQLでfieldnameフィールドのインデックスがある場合

今回の例は条件式が一つですので簡単です。MySQLはまず、レコードバッファ内のfieldnameフィールドの位置にキー値(xxx)をセットしてhandler::ha_index_read_map(HA_READ_KEY_EXACT)を呼び出します。

…

その２はselect * from tablename where fieldname = xxxです。長くなるのでまずは２の１から。

なんとも簡単なSQL文ですが、テーブルの定義やデータの状況によって全くパフォーマンスが異なってきます。

使用するインデックス解析

MySQLはまず …

よく、SQLが遅いといった話を耳にしますが、サーバー側がどう処理して遅いのかまで書いたものがあまり見当たらないので、Transactdの開発経験を生かし、その使い方と合わせて書いてみたいと思います。

MySQLは、プラガブルデータベースエンジンという仕組みでさまざまなデータベースエンジンを利用できるようになっています。その内部は、データベースエンジンの操作インターフェースを定義してエンジンごとに実装をするというC++の …