【ITニュース解説】The Database Zoo: Exotic Data Storage Engines

データの世界は過去20年間で劇的に変化した。以前はビジネスの取引記録や顧客情報といった定型的なデータが中心だったが、現在では監視システムやIoTデバイスから送られてくる大量のログデータや測定値、機械学習で利用される高次元のベクトルデータ、ソーシャルメディアにおけるユーザー間の関係性を示すグラフデータ、リアルタイムで発生するイベントの連続した流れ、そしてGPSや地図アプリが扱う地理空間データなど、多種多様なデータが日々生成されている。これらのデータはそれぞれ異なる特徴を持ち、その量もこれまでにない規模に達しているため、エンジニアにとってデータを効率的に保存し、必要に応じて取り出すことは大きな課題となっている。

長らくデータの保存といえばリレーショナルデータベースが主流だった。これは、1970年にIBMの研究者であるE. F. Coddが提唱した「リレーショナルモデル」に基づいている。彼の画期的なアイデアは、データをファイルの物理的な構造ではなく、数学的な「関係」（テーブル）として論理的に表現することだった。これにより、ユーザーは「SQL」という標準化された宣言型言語を使ってデータに対する操作を指示するだけでよくなり、データベースの内部でインデックスやストレージ、データの整合性やリカバリといった複雑な処理が自動的に行われるようになった。リレーショナルデータベースは、データの物理構造が変更されてもアプリケーション側の修正が不要になる「データ独立性」を実現し、データの信頼性、一貫性、分離性、永続性を保証するACID特性を備えていることから、金融システム、ERP（統合基幹業務システム）、一般的なウェブアプリケーションなど、データの正確性と信頼性が最も重要視されるシステムで幅広く利用されてきた。Oracle、IBM DB2、Microsoft SQL Serverといった商用データベースに加え、MySQLやPostgreSQLのようなオープンソースのデータベースも普及し、データ管理の基盤として確固たる地位を築いた。

しかし、リレーショナルデータベースには限界も存在する。データが構造化されており、厳密なスキーマを持つため、データの形式が頻繁に変わるような状況には対応しにくい。また、単一の強力なサーバーで処理を完結させる「垂直スケーリング」には強いものの、複数のサーバーに負荷を分散させる「水平スケーリング」は複雑で難しい。ログデータやIoTデータのように秒間何百万もの書き込みが発生するような大量のデータ投入には対応が難しく、数十億件のデータを集計するといった大規模な分析処理にも効率が悪い場合がある。

2000年代後半になると、Google、Amazon、Facebookといった巨大なインターネット企業は、これまでのリレーショナルデータベースでは対応しきれないほどの膨大なユーザー数、データ量、そしてリアルタイム性を要求するサービスを構築する必要に迫られた。この状況が、リレーショナルデータベースが持つ厳密な制約の一部を緩和し、スケーラビリティや柔軟性、特定の処理性能を向上させることを目指した新しいタイプのデータベース、通称「NoSQL」の登場を促した。

NoSQLは「非リレーショナル」を意味し、分散システムにおいて「整合性」「可用性」「分断耐性」のうち二つを同時に満たすことができるというCAP定理の考え方に基づき、厳密な整合性よりも可用性やスケーラビリティを優先するケースが多い。NoSQLデータベースにはいくつかの主要なカテゴリがある。一つは「キーバリューストア」で、データを単純なキーと値のペアとして保存し、キーによる検索や保存が非常に高速なのが特徴だ。RedisやDynamoDBがその例で、キャッシュやセッション管理によく使われる。次に「ドキュメントストア」があり、JSONやBSONといった柔軟な形式のドキュメントでデータを格納する。スキーマに縛られず、ネストされた複雑なデータ構造も扱えるため、コンテンツ管理システムやユーザープロファイルなどの半構造化データの扱いに適している。MongoDBやCouchDBが代表的だ。さらに「ワイドカラムストア」は、行ごとに異なるカラムを持つことができる柔軟なテーブル構造で、大量の書き込みや分散ストレージに最適化されている。CassandraやHBaseがこれに該当し、時系列データやIoTデバイスからのデータ収集、大規模な分析基盤などに利用される。最後に「グラフデータベース」は、エンティティ（ノード）とその関係性（エッジ）を中心にデータを保存し、複雑なネットワーク構造の探索や関係性に基づくクエリを効率的に実行できる。Neo4jやDgraphが例として挙げられ、ソーシャルネットワーク、レコメンデーションシステム、不正検出などに活用されている。

NoSQLデータベースは、大量のデータに対する高速な読み書き、開発が迅速に進む柔軟なスキーマ、そして複数のサーバーにわたる容易な水平スケーラビリティといった強みを持つ。しかし、汎用的なリレーショナルクエリ（複雑な複数テーブル結合など）は不得意な場合が多く、最終的にデータが一致する「結果整合性」を採用しているため、アプリケーション側でデータの整合性に関する考慮が必要になることもある。また、それぞれのNoSQLタイプが特定のワークロードに特化しているため、その専門分野から外れると性能を発揮しにくいという弱点もある。

このように、リレーショナルデータベースとNoSQLデータベースはそれぞれ得意な領域を持つが、現代の多様で大規模なワークロードにおいては、これら汎用的なデータベースでは完全に解決できない課題も出てきている。例えば、監視システムやIoTデバイスから得られる膨大な時系列データを効率的に保存し、特定の期間のデータを高速に集計する処理、機械学習で使われる何百、何千もの次元を持つベクトルデータを高速に比較して類似のものを検索する処理、何十億ものデータからなる超大規模な分析クエリ、イベントソーシングのようにデータを追加するだけの記録システム、あるいは地図やGPSといった地理空間データに特化した高度な検索処理などだ。これらの特殊な要件は、一般的なデータベースでは性能の限界やストレージの非効率性、クエリの制限といった問題を引き起こす。

そこで登場するのが「専門データベース」である。これらは、特定の種類のデータと特定のワークロードのためにゼロから設計されており、汎用データベースの限界を克服することを目指している。例えば、時系列データ専用のデータベースは、その特性に合わせたストレージ形式、圧縮技術、インデックス戦略、クエリ実行モデルを採用することで、一般的なデータベースでは実現できないような圧倒的なパフォーマンスと効率を提供する。これらの専門データベースは、既存のSQLやNoSQLデータベースを置き換えるものではなく、特定の課題を解決するための補完的なツールとして機能する。

本シリーズ「The Database Zoo: Exotic Data Storage Engines」では、このような専門データベースについて深く掘り下げていく。それぞれのデータベースがどのような問題を解決するために生まれたのか、内部のストレージ構造やインデックス付けの手法、データ処理のアルゴリズムはどうなっているのか、そしてどのようなクエリモデルを持ち、どのような最適化が行われているのかを詳しく解説する。具体的なユースケースや実例を交えながら、それぞれのデータベースがなぜ存在するのか、どのように機能するのか、そしてどのような場合にあなたのシステムに最適なツールとなり得るのかを明らかにしていく。まずは、大量のタイムスタンプ付きデータを効率的に保存、圧縮、クエリする方法に特化した「時系列データベース」から解説を始める予定だ。