こんにちは、吉田行男です。今回は、「新たなDBの潮流」ということで、「分散データベース」についてご紹介したいと思います。
「NoSQL」から「NewSQL」へ
2010年頃、ビッグデータをさまざまなITシステムで取り扱う必要性が高まり、従来のSQLデータベースでは対応できない大量のデータや多様なデータ形式に対応するために「NoSQL」という分野のプロジェクトが活発に動き始めました。ちなみにこの「NoSQL」は「Not SQL」ではなく「Not only SQL」という意味でした。
このNoSQLには、その特徴によって、『キーバリュー型』『カラム指向型』『ドキュメント型』『グラフ型』の４種類のものが含まれます。説明と代表的なものを以下に記します。
| キーバリュー型 |
一意なキーと、キーに1対1で対応するバリューのペアで、データを保持する方式で、複雑な検索等は苦手ですが、単純な処理は高速にこなすことができます。バリューの自由度が高く、ほとんど型に縛られないので、動画や音声、画像などのメディアデータも扱いやすくなっています。特に複数のサーバに分散してデータを保存できる機能を持ったものを「分散KVS」と呼ばれています。 代表例：Basho Riak, Redis,Amazon DynamoDBなど |
| カラム指向型型 |
キーバリュー型のバリュー部分が、更に任意の数のキーバリューの集合(列名と値）になったような構造で、RDBと似た構造をとっています。しかし、行ごとに列の名前や数は自由で、列方向の集約が高速で集計処理などが得意です。時系列に発生するセンサデータの格納に適しており、IoT(Internet of Things)と相性が良いといわれています。 代表例：Google Big Table、Cassandra,HBaseなど |
|
ドキュメント型 |
キーバリュー型のバリュー部分が、JSONやXMLなどの半構造化データ(ドキュメント）になったような構造です。キーバリュー型よりも、データの検索性に優れています。スキーマレスなので、複雑なデータを柔軟に運用することができ、一般的なWebシステムとは相性が良いといわれています。 代表例：MongoDB、Amazon DocumentDBなど |
|
グラフ型 |
グラフ型といっても、円グラフや棒グラフといった図形式のデータベースではなく、以下3つの要素でデータ同士の関係性を表現する「グラフ理論」に基づいたデータベースで、データ同士の関係性が複雑な場合でも検索速度が速いのが大きな特徴です。
代表例：Neo4j, Amazon Neptuneなど |
しかしながら、スケーラビリティという面では非常に有効な選択肢であったNoSQLですが、データの一貫性が保証されていないため、データの更新や削除処理が頻繁に発生すると、データの整合性が保証されない場合があります。整合性を必要とする(特にWriteヘビーな) ユースケースでは、アプリケーション側で最大限の考慮をする必要がありました。また、SQLが使用できないため、複雑な検索ができないという問題がありました。
そこで、新しい概念として登場したのが、『NewSQL』という概念です。現在、NewSQLの代表的なサービスとして、Google Cloud Spanner が挙げられます。これは、2012年に“Spanner: Google’s Globally Distributed Database(*1)”として論文が発表され、Google内部で利用されていたものですが、2017年からはGoogle Cloud Spannerとして一般ユーザも利用可能となっています。
このSpannerの一番の特徴は、「トランザクション処理の大規模分散処理」と実現したことにあります。いわゆるACID特性を実装しているということになります。ACIDとは、トランザクション処理を実行するために必要な特性のことであり、Atomicity (不可分性）、Consistency (一貫性）、Isolation (独立性）、Durability (永続性）の4つの英単語の頭文字を取った言葉になります。詳細が知りたい方は下記のサイト(*2)をご覧ください。また、SQLインターフェースを提供していることやC# 、 C++ 、 Go 、 Java 、 Node.js 、 PHP 、 Python 、 Ruby などのさまざまな言語に対応していることも大きな特徴になります。
このSpannerに影響を受け、強い整合性を持ち、ACIDトランザクションをサポートする、(地球規模の)分散型のSQLデータベースが出てきました。
| 名称 | 開発元 | リリース年 | SQLインタフェース |
| CockroachDB | Cockroach Labs | 2017年（v1.0） | PostgreSQL互換 |
| TiDB | PingCAP | 2017年（v1.0.0） | MySQL互換 |
| YugabyteDB | Yugabyte | 2018年（v1.0.0） | PostgreSQL互換 |
以下、このPostgreSQL互換のYugabyteDBについて、ご紹介したいと思います。
ちなみに、このYugabyteDBの最新バージョンは、“2.15”で2022年6月にリリースされています。
Spannerクローンのアーキテクチャ: YugabyteDB
YugabyteDBのアーキテクチャは、とてもシンプルでQueryを処理する部分とドキュメントストア部分に分かれています。Query処理部分は基本的にPostgreSQLやCassandraの実装をそのまま利用しており、ドキュメントストア部であるDocDBは、Facebookで実装されたものに影響されて開発したものになります。このようにQuery部分を分けたことにより、今後新しいQueryに対応する場合もその部分のみを開発することで新しいQueryに対応することができるように開発されています。
(出典：Yugabyte 社 提供)
また、このドキュメントストアレイヤでは、tabletと呼ばれるシャーディングの単位でレプリケーションを実施しており、下記の図にあるように、各ノードの中からleaderがひとつ選ばれ、他のノードがfollowerノードになります。さらにこのleaderが特定のノードに集中しないように配置される仕組みになっています。
(出典：Yugabyte 社 提供)
すでに海外では、ウォルマート、Amazonに次ぐ米国小売業3位のスーパーマーケットチェーンであるKrogerでshopping list サービスに活用されていたり、国内でも楽天モバイルなどで活用されています。
今後、クラウドネイティブ化が進むにつれて、このような『NewSQL』のニーズが高まることが予想されますので、市場や技術の動向を注視していく必要があると思います。
(*1)https://www.usenix.org/system/files/conference/osdi12/osdi12-final-16.pdf
(*2)ACID特性：
| 不可分性(Atomicity) | トランザクションに含まれるタスクが全て実行されるか、あるいは全く実行されないことを保証する性質 |
| 一貫性(Consistency) | トランザクション開始と終了時にあらかじめ与えられた整合性を満たすことを保証する性質 |
| 独立性(Isolation) | トランザクション中に行われる操作の過程が他の操作から隠蔽されること |
| 永続性(Durability) | トランザクション操作の完了通知をユーザが受けた時点で、その操作は永続的となり、結果が失われないこと |
著者：
吉田 行男
2000年ごろからメーカー系SIerにて、Linux／OSSのビジネス推進、技術検証、OSS全般の活用を目指したビジネスの立ち上げに従事。社内外でOSS活用に関する講演、執筆活動を行ってきた。2019年から独立し、さまざまな会社や団体の顧問として活動。OSSの活用やコンプライアンス管理などを支援している。
オープンソース導入・サポートのことなら、サイオステクノロジーOSSよろず相談室へ
