MySQLのforkが複雑すぎる!(MySQL/MariaDB/Percona)

もとやんです。
表題の通りです。もともとmysql大好きっ子だったのですが、最近(って言っても、1年2年じゃないけど)mysqlからforkしたプロジェクトがメチャ多くて、しかもそれなりにしっかりとしたプロジェクトが多いから、何がどういいのかマジでわからんくなっています。
その時々でバージョンが変わって、事情も変わっているからまた大変。何かのプロジェクトに導入するときは、その時点で(将来にわたっても)ベスト(だろうと思うよう)なプロダクトを選びたいので、一応少し調べたり覚えたりしている範囲の差を書いておきます。

完全に備忘録。新しい事をしるたびにこの記事は更新される予定です(差の追加や、差がなくなった項目の削除など)。
なので、この記事については特に最終更新日をお確かめください。

MySQL

これを基本にする。
なので差は書かない。

MariaDB

  • 無料にもかかわらず、スレッドプールが使える。(MySQLは有償)
  • indexにrtreeがある(空間インデックスに向く。Btreeでもアプリ的にどうとでもなるが楽)
  • explainがない。optimizerは高性能
  • バイナリログがバージョン1しか対応していない

Percona

  • INFORMATION_SCHEMAが拡張されている
  • スロークエリログも詳細に取れる
  • 無料にもかかわらず、スレッドプールが使える。(MySQLは有償)
  • 監査ログも無料で取れる
  • マルチコア最適化が進んでいたけれど、最近は差が小さい

Drizzleは、もう独自路線行きまくっているのでまぁ良いんでないでしょうか。マイクロカーネルと、コンポーネント化された各種機構、スリムダウンされつつもトランザクションをサポートしたクラウド環境での動作に最適化したストレージとか、理念的には好きです。
ただ、今どきの運用環境で言うとAWS上で動作する、Auroraとガッツリ競合しそうなんですよね‥。

Auroraも当然この中に入りうる、MySQLコンパチブルなRDBMSですが、いかんせんAWSにロックインされまくりなのでまぁ少し意味が違うかなと判断し、外しています。
まぁでもAWS上でシステムを構築し、MySQL互換縛りでDBMSを選択し、AWSから出て行く気がないのだったらAurora選んでおいけばいいと思います。
実際Auroraのレプリカの設定・挙動・価格や性能の伸び方などを見る限りは、RDSでMySQLを特に今選ぶ理由がありません。めちゃくちゃ細かく制御したり、カスタムビルドしたMySQLが欲しいならEC2で動かすことになりますからね。

あとはもうPostgreSQLで良いんでないかな・・。HDDに最適化されているのでSSDで性能でも伸びきらないって言う問題があるけど‥。
メモリ積めばある程度解消するみたいだけど、RAMって今まで見た中で一番積んでるマシンでも256Gとかなんで、まぁそれにホットなデータが乗り切れば・・ッて感じかなぁ。IO-Fusionは強すぎますわ。

スポンサーリンク
Sponsored Link
Sponsored Link

シェアする

  • このエントリーをはてなブックマークに追加

フォローする