「われわれは容易に拡張できる技術を必要としていた」。プラットフォームエンジニアリング責任者のパトリック・ディ・ロレト氏はそう語る。「そこで必然的にNoSQLを選択した。Cassandraは特に成熟度が高く、ビッグテーブルという性質は、タイムシリーズデータの分析に最適だった」

　451 Researchのアスレット氏によると、もし単純にOracle DatabaseやMicrosoft SQL Serverよりコストが安いRDBMSを求めているのであれば、MySQL（現在はOracleにサポートされている）とともに、より従来型のオープンソースであるPostgreSQLが堅実な代替になる。これまでは規模の小さい非営利組織に導入されるのが一般的だったが、これらを使いこなしている企業も数多い。

　「PostgreSQLは継続的に刷新され、革新が行われている。ただしもっと新しいオープンソースデータベースと違って、これを運営する商用組織が存在せず、真のコミュニティー開発によって開発されている」（アスレット氏）

　PostgreSQLは20年以上前から存在していて、Skypeやフランスの児童福祉局、NHSといった大手が利用してきた。コミュニティーの中心となる商業組織は存在しないものの、同OSSのために多数の企業がエンタープライズ級のサポートを提供している。

　そうした企業の1つであるEnterpriseDBのチーフアーキテクト、デイブ・ペイジ氏は、PostgreSQL運営委員会の中心メンバーでもある。「20年前、これは愛好家のプロジェクトだった。だが今では早くから関わってきた私のような人間がみな、PostgreSQL企業に勤務するようになり、エンタープライズ顧客が求める機能の構築に当たっている。中でもセキュリティと安定性を最優先する。時には新機能の提供で競合に先を越されることもあるが、われわれは安定性を確実に固めることに重きを置く。PostgreSQLはエンタープライズ対応が整い、機能セットはビッグスリーに匹敵する」。ペイジ氏はそう話す。

80％のコスト削減

　EnterpriseDBの主張によれば、移行とサポートの経費を考慮しても、PostgreSQLの商用サポートバージョンに移行した企業は一般的に、3年間で80％のコストを削減できる。

　ただしRDBMSが現代のニーズにかなった最高のソリューションとはいえないケースも増えている。JSONやXML文書といった、非構造化データの保存とクエリに対応する必要性、新しいアプリケーションを迅速に導入してスケールアップできる必要性（複数のデータセンターを網羅する可能性もある）という2つの課題が、NoSQLデータベースの成長につながってきた。

　新たに浮上したその人気は、Google、Amazon、Facebookなど、拡張性の高いRDBMSの代替を必要とするネット大手が後押ししてきた。これらは大抵がオープンソースであり、自由にダウンロードでき、ITチームが複数の違うシステムで利用してどれが自分たちのニーズに最もかなうかを探ることもできるため、検討に値するかもしれない。

　PCA Predictが最近開発した新しいカスタマーエクスペリエンスアプリ「Triggar」は、大量のデータを基に顧客の行動に関するモデルを作成する。ターナー氏はMongoDB、Cassandra、MySQL、PostgreSQL、「Elasticsearch」を含め、あらゆる形態のデータベース製品を試したという。

　「全てにそれぞれの限界がある。例えばMongoDBはデータを安定的に保存できず、コーリングモデルはあまり良くなかった。Cassandraはデータを効率的に取得するためにスキーマを非常に慎重に組み立てる必要があり、その場だけのクエリはほとんどできない。Elasticsearchのクエリ環境は驚くほど豊かだが、データを入力すると、再び読める状態になるまで1～2秒の遅れがあり、デフォルトのクエリ言語は最低だ」

　「PostgreSQLは非常にうまく機能していたが、書き込み負荷が非常に重い作業を行ったところ、既存の記録を更新するのではなく、その記録の新しいバージョンが作成されることが分かった。つまり、非常にアクティブなデータベースだと大量のゴミがたまってしまう。Cassandraも同じだった。MySQLはスケーリングモデルがあまり良くない。そしてドキュメントは『Oracle化』されているように思えた。それを回避する方法が見つけられなかったので諦めるしかなかった」

　「他に興味深いと思えたのは、驚異的に速いインメモリデータベースの『VoltDB』と、『Aerospike』だった。いずれもより現代的なハードウェアを指向しており、SSDなど普通はデバイス層に食い込まなければ利用できない機能を活用している」（ターナー氏）

クエリ言語

　最終的にターナー氏はElasticsearchを選んだが、デフォルトのエンジンよりもSQLライクなクエリ言語を使っている。「拡張性とノード障害からの復旧に優れていて、極めて簡単に導入できる。クエリは非常に豊かだ。ただしデータを書き込んだときに表示されるまで1秒かかるのは非常に問題がある。そこで今は別のものと組み合わせるかどうか検討中だ」とターナー氏。

　要するに、こうしたシステムは全て妥協が必要だ。「エンジニアとしての立場から、理想として何を求めるかではなく、本当に達成したいのは何かを問い掛ける必要がある。私は海外旅行に行くときは大理石の内装とソファのある飛行機で行けたらとは思うが、A地点からB地点へ行くために本当に必要なのはエコノミークラスの便だ」。ターナー氏はそう言い添えた。

　451 Researchのアスレット氏も、新しいオープンソースのNoSQLあるいはNewSQLデータベース（SQLが使えるNoSQLデータベース）が自分のアプリケーションやワークロードに対応できるかどうか見極めるには、自分の手を動かすしかないとの見方で一致する。「組織でこれらを使ってみる必要がある。大部分はオープンソースなので、ダウンロードして試行錯誤し、雰囲気をつかむといい」

　選択肢は手に負えないほど多いように思えるかもしれないが、成熟度と現実性、サポートに関してエンタープライズ級とみなせるもののみに目を向けると、「候補はかなり絞られる」とアスレット氏は言う。

　「NoSQLでは、ドキュメントストアの中ではMongoDBが際立っている。一方、キー・バリューストアに目を向けるのならDataStaxのサポートが付くCassandraまたはCouchbase Server、あるいはBashoの『Riak』だ。グラフデータベースなら『Neo4j』が抜きん出る。より分散型のSQLデータベースを求めるのなら『MemSQL』や『NuoDB』のようないわゆるNewSQLをチェックするといい。他にもあるが、評価できないほどの多さではない」