データベースのスケーラビリティをどうやって向上させるか

これまでPublickeyではデータベースのスケーラビリティに関するさまざまなトピックを取り上げてきました。クラウド時代にはスケーラブルなデータベースのニーズがこれまでになく高まっているためです。

この記事では、これまで取り上げてきたデータベースのスケーラビリティに関する技術を少しまとめて紹介しようと思います。

従来のリレーショナルを拡張

従来のリレーショナルデータベースに対して、技術的工夫を凝らすことでスケーラブルなデータベースを実現しようというアプローチにも、さまざまなものがあります。

データベース研究者の大御所、マイケル・ストーンブレイカー氏は、リレーショナルデータベースは決して遅くないと主張。リレーショナルデータベースが遅い原因はロック、ラッチ、リソース管理にあるとして、それらを極力排除した「VoltDB」を開発しています。

• NoSQLを上回る性能のVoltDB、そのアーキテクチャとは
• SQLの都市伝説。マイケル・ストーンブレイカー御大が斬る！

Twitterのフレームワーク「Gizzard」は、MySQLをバックエンドにシャーディング（Sharding）を行い、1つのデータベースをハッシュなどを使って複数の部分に分けて分散して格納し、さらにデータのレプリケーションを行うことで耐障害性を向上させています。

• Twitterが分散フレームワーク「Gizzard」公開！ Scalaで書かれたShardingを実現するミドルウェア

MySQLのストレージエンジンをクラウド対応にすることでスケーラブルにした、というのが、Amazonクラウド上でデータベースサービスを提供する「Xeround」です。

• クラウド対応のスケーラブルなMySQLデータベース、米Xeroundが発表

SSDに最適化したリレーショナルデータベースをスクラッチから開発することで性能向上を実現しようというのが「RethinkDB」

• SSDに最適化したデータベース「RethinkDB」、ロックもログも使わずにトランザクション実現

ソフトウェアとハードウェアを密に統合することを徹底的に追求したのが、オラクルの「Exadata」。最新CPU、大容量メモリ、Flashストレージ、Infinibandなど、あらゆる富豪的アプローチのかたまりです。オラクルの中の人からは「実質、インデックスを付ける必要がないほど速い」との発言を聞いたことも。

• 速報：Oracle+Sun統合製品第一弾はOLTPとDWHの両対応マシン、Xeon5500+Flashストレージ+InfiniBand

インメモリデータベース

ハードウェアの性能向上をリレーショナルデータベースの性能向上に活かす点で、最近注目されているのが、データをメモリ上に保持するインメモリデータベースです。Publickeyで最初に取り上げたのは、オラクルの「TimesTen」でした。

• インメモリデータベースがクラウド時代の主流になるという期待
• キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると

オラクルにはインメモリデータベース的な分散オブジェクトキャッシュとも呼ばれる「Coherence」もあります（追記：Coherenceはインメモリグリッドに分類すべきだったようです）。

最近、インメモリデータベースとして登場したのが、SAPの「HANA」。HANAはインメモリ技術だけでなく、カラム型データベースやデータ圧縮なども組み合わせています。

• SAP、脱オラクルへのロードマップ。インメモリデータベース「HANA」を発表

そのほかインメモリデータベースには、IBMの「solidDB」オープンソースの「Redis」などもあります。

メモリキャッシュ、インメモリデータグリッド

データベースの手前に巨大なキャッシュを置くことで性能向上を実現する手法もよく使われています。

Facebookは、Memcachedを用いてデータベースのデータを積極的にキャッシュに置くことで、大規模なスケーラビリティを実現。

• Facebookが大規模スケーラビリティへの挑戦で学んだこと（後編）～キャッシュが抱えるスケーラビリティの問題とデータセンターにまたがる一貫性

しかもMemcachedには300テラバイトものデータを置いているとのこと。

• Facebook、memcachedに300TB以上のライブデータを置く大規模運用の内側

最近になって登場しているのがインメモリグリッドと呼ばれる分野の製品。VMwareが買収したGemStoneが、そのインメモリデータグリッドの1つ。

• 「データベースのスケーラビリティの解決」のためにGemStoneを買ったVMwareの狙い（前編）

レッドハットもこの分野の製品を「JBoss Enterprise Data Grid」として最近発表しました。データベース製品を持たない2社が同様の戦略を採用している点が興味深いですね。

カラム型データベース

大規模データ分析の分野で最近頭角を現しているのが、カラム型データベース技術（カラムナデータベース、列指向データベース）。

• カラムナデータベース（列指向データベース）とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること
• ビジネスインテリジェンスDBMSの夜明け。あるいはカラム型、インメモリ型など新たなデータベースの勃興

カラム型データベースの代表はサイベースの「SybaseIQ」。前述のSAPの「HANA」もカラム型データベース。ヒューレット・パッカードが買収した「Vertica」もカラム型データベースで、ヒューレット・パッカードはいまVerticaのアプライアンスを開発中です。おそらくオラクルのExadataに対抗するようなものになるのではないでしょうか。

• 「ハイブリッドクラウドへの移行を支援する」 米ヒューレット・パッカードがクラウド戦略を明らかに。HP Summit 2011

NoSQL

クラウドのような分散アーキテクチャに対応したスケーラブルなデータベースが、NoSQLと呼ばれる分野のデータベースで次々に登場し始めました。

• 「NoSQL」は「Not Only SQL」である、と定着するか？
• NoSQL登場の背景、CAP定理、データモデルの分類

グーグルの「BigTable」、アマゾンの「SimpleDB」などがよく知られています。

• グーグルが構築した大規模システムの現実、そしてデザインパターン（2）～BigTable編
• 進化するNoSQLデータベース、SimpleDBやBigTableで一貫性やトランザクションを実現
• グーグルが取り組む次世代Bigtable、全世界規模でサーバ1000万台を自動化して構築する「Spanner」プロジェクト

オープンソースで開発されている「Cassandra」も、NoSQLを代表するソフトウェアです。

• Cassandra入門と、さらに詳しく知るためのリソース集
• TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由
• Twitterが、Cassandraの本採用を断念。「いまは切り替えの時期ではない」
• NoSQLをRDBの代わりに使うと、どういう恐ろしいことが起こるか。PARTAKEの作者が語る

広い意味でのNoSQLとしては、Hadoop、HBaseも非常に注目されているソフトウェアです。

• Hadoopと3つのRDBMSの比較評価。 Hadoop World: NYC 2010
• HBaseとはどんなNoSQLデータベースなのか？ 日本語で読める情報を集めてみた

リレーショナルデータベースにNoSQL的な機能を組み込んでスケーラビリティを実現しようという実装もあります。

• NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
• リレーショナルデータベースはNoSQLを取り込み始めた。NewSQLの登場とNoSQLの終わり、という予想

難しくなる「どんなデータベースを選ぶべきか」

データベースというのは、一度システムが稼働し始めると途中で変更することが非常に困難なコンポーネントです。それゆえに、そのシステムにとってどのようなデータベースがもっともふさわしいのか、設計時に慎重に検討する必要があります。

かつて、データベースの選択といえばほぼリレーショナルデータベース一択で、あとはインデックスとチューニングとハードウェア性能で頑張るしかなかったのですが、ここで見てきたようにデータベースの選択肢はここ数年で飛躍的に拡大しました。選択肢が増えたことでシステム設計の自由度が高まった面もありますが、一方で本当に適切なデータベースを選ぶのが難しい時代になってきたのかもしれません。