YugaByteレビュー:惑星規模のCassandraとRedis

データベースアプリケーション開発者としての数十年の間、私は自分の夢の中で、トランザクション型の惑星規模の分散データベースにアクセスできるとは想像もしていませんでした。しかし、Google Cloud Spanner、CockroachDB、Azure Cosmos DB、Neo4j Enterprise、そして最近ではYugaByte DBがすべて本番環境で利用可能になったことで、その1回限りのパイプの夢は今では非常に現実的です。

大まかに言えば、Google Cloud Spannerは、スケーラブルで分散型の一貫性の高いSQLデータベースを、ノードあたり1秒あたり約2,000回の書き込みと1秒あたり10,000回の読み取りを処理できるサービスとして提供し、レイテンシの中央値は約5ミリ秒です。完全に最新のデータを必要としない読み取りを高速化するには、タイムトラベルクエリをサポートしているため、Spannerに古い読み取りを要求できます。 SpannerはSQLのGoogle方言を使用し、Google CloudPlatformでのみ実行されます。

CockroachDBは、PostgreSQLワイヤープロトコルとPostgreSQLSQLダイアレクトをサポートするSpannerのようなオープンソースSQLデータベースです。 CockroachDBは、オープンソースのトランザクション型で一貫性のあるKey-ValueストアであるRocksDB上に構築されています。 Spannerと同様に、タイムトラベルクエリをサポートします。 CockroachDBは、任意のクラウド、オーケストレーションの有無にかかわらずDockerコンテナー、またはLinuxサーバーまたはVMで実行できます。 CockroachDBのエンタープライズバージョンは、ジオパーティショニング、ロールベースのアクセス制御、およびサポートを追加します。

Azure Cosmos DBは、グローバルに分散され、水平にパーティション化された、サービスとしてのマルチモデルデータベースです。 4つのデータモデル(Key-Value、列ファミリー、ドキュメント、グラフ)と5つの調整可能な一貫性レベル(強力な制限付きの失効、セッション、一貫性のあるプレフィックス、最終的な)を提供します。 SQL(方言)、MongoDB互換、Azure Table互換、グラフ(Gremlin)、ApacheCassandra互換の5つのAPIセットを提供します。 MicrosoftAzureクラウドでのみ実行されます。

Neo4jは、Cypherクエリ言語を使用するスケーラブルで存続可能なグラフデータベースです。オープンソースの非クラスター化バージョンは、Windows、MacOS、Linux、Dockerコンテナー、およびVMにインストールできます。Neo4j Enterpriseは、高可用性と因果クラスターをサポートします。因果クラスターは、読み取りレプリカの非同期更新クラスターを可能にし、地理的に分散した展開で高いパフォーマンスを実現します。

YugabyteDBを入力してください

このレビューの対象であるYugaByteDBは、3つのAPIセットをサポートする惑星規模のアプリケーション向けのオープンソースのトランザクション型高性能データベースです。YCQL、Apache Cassandraクエリ言語(CQL)と互換性があります。YEDIS、Redisと互換性があります。およびPostgreSQL(現在は不完全でベータ版)。YugaWareは、YugaByte DB EnterpriseEditionのオーケストレーションレイヤーです。YugaWareは、Amazon Web Services、Google Cloud Platform、および(2018年第4四半期までに)MicrosoftAzure上の分散クラスターをすばやくスピンアップおよび破棄します。YugaByte DBはマルチバージョン同時実行制御(MVCC)を実装していますが、タイムトラベルクエリはまだサポートしていません。

YugaByte DBは、RocksDBKey-Valueストアの拡張フォークの上に構築されています。YugaByte DB1.0は2018年5月に出荷されました。

分散トランザクションデータベースの一貫性と高速性を実現するために使用される2つの主要なテクノロジーは、クラスターコンセンサスアルゴリズムとノードクロック同期です。Google CloudSpannerとAzureCosmos DBはどちらも、LeslieLamportによって提案されたPaxosコンセンサスアルゴリズムを使用しています。CockroachDBとYugaByteDBは、DiegoOngaroとJohnOusterhoutによって提案されたRaftコンセンサスアルゴリズムを使用しています。

Google Cloud Spannerは、GPSと原子時計に基づいたGoogle独自のTrueTimeAPIを使用しています。Azure Cosmos DB、CockroachDB、およびYugaByte DBは、ハイブリッド論理クロック(HLC)タイムスタンプとネットワークタイムプロトコル(NTP)クロック同期を使用します。

YugaByteの設計目標

YugaByteの創設者であるKannanMuthukkaruppan、Karthik Ranganathan、Mikhail Bautinは、Apache HBaseコミッター、Apache Cassandraの初期エンジニア、およびFacebookのNoSQLプラットフォーム(Apache HBaseを利用)のビルダーでした。 YugaByte DBの目標は、哲学的にAzure CosmosDBとGoogleCloudSpannerの間にある分散データベースサーバーでした。つまり、Cosmos DBのマルチモデル属性と高性能属性を、ACIDトランザクションおよびSpannerのグローバルな一貫性と組み合わせたいと考えていました。彼らの目標を説明するもう1つの方法は、YugaByte DBをトランザクション型で、高性能で、惑星規模にすることを一度に望んでいたことです。

彼らはプロセスを5つのステップに分割し、各ステップの構築には約6か月かかりました。最初のステップは、Raftコンセンサスプロトコル、シャーディング、負荷分散を追加し、トランザクションログ、ポイントインタイムバックアップを削除することで、C ++で記述された高性能のKey-ValueストアであるRocksDBの強力な一貫性のあるバージョンを作成することでした。とリカバリ。これは上位層に実装する必要がありました。

次のステップは、ログ構造のドキュメントキーストレージエンジンを構築し、行、マップ、コレクション、JSONなどの非プリミティブタイプとネストタイプを追加することでした。次に、Azure Cosmos DBなどのプラグ可能なAPIレイヤーを追加し、Cassandra互換およびRedis互換のAPIを実装し、PostgreSQL互換のSQLAPIを後の段階に延期しました。次に、拡張クエリ言語が登場しました。

YugaByte Cloud Query Language(YCQL)は、分散トランザクション、強力な整合性のあるセカンダリインデックス、およびJSONをサポートすることでCassandraAPIを拡張します。YugaByte Dictionary Service(YEDIS)は、組み込みの永続性、自動シャーディング、線形スケーラビリティが追加されたRedis互換APIです。YEDISは、オプションで、最も近いデータセンターからのタイムラインの一貫性のある低遅延の読み取りを可能にし、強力な書き込み操作はグローバルな一貫性を維持します。YEDISには、新しい時系列データ型も含まれています。

最後に、バージョン1.0では、YugaByte DB Enterpriseは、複数のリージョンおよび複数のクラウドにわたる本番環境グレードのデプロイを調整、保護、および監視するためのレイヤーを追加し、AmazonS3などの構成可能なエンドポイントに分散バックアップを保存します。PostgreSQLのサポートは不完全なままで、ベータテストレベルです。

分散ACIDトランザクション 

プロセスを完全に単純化しすぎるリスクを冒して、YugaByteが分散ACIDトランザクションを実行する方法を要約してみましょう。ACID(原子性、一貫性、分離、および耐久性を表す)は、SQLデータベースに限定されたプロパティと見なされていました。

トランザクション内の更新を含むYCQLクエリを送信するとします。たとえば、金融データベースの一貫性を維持するために、一方が失敗した場合に両方を中止する必要がある借方と貸方のペアなどです。YugaByte DBは、ステートレストランザクションマネージャーでトランザクションを受け入れます。ステートレストランザクションマネージャーの1つは、クラスター内のすべてのノードで実行されます。次に、トランザクションマネージャーは、パフォーマンスの目的で、トランザクションによってアクセスされるほとんどのデータを所有するタブレットサーバーでトランザクションをスケジュールしようとします。

トランザクションマネージャは、一意のIDを持つトランザクションエントリをトランザクションステータステーブルに追加します。次に、トランザクションが変更しようとしているキーを担当するすべてのタブレットに暫定レコードを書き込みます。競合がある場合、競合するトランザクションの1つがロールバックされます。

すべての暫定レコードが正常に書き込まれると、トランザクションマネージャーは、トランザクションステータスタブレットに、Raftログの「トランザクションコミット」エントリのタイムスタンプを使用して、すべての暫定レコードを通常のレコードに置き換えるように要求します。最後に、トランザクションステータスタブレットは、トランザクションに参加した各タブレットにクリーンアップ要求を送信します。

パフォーマンスを向上させるために、YugaByteは進行中のトランザクションの情報を積極的にキャッシュし、きめ細かいロックを実装し、ハイブリッドタイムリーダーリースを使用して、クライアントが古いリーダーから古い値を読み取らないようにします。単一行のACIDトランザクションは、競合する操作がない場合に待ち時間が短くなるように最適化されています。分散ACIDトランザクションは、待ち時間が長くなる代わりに正確性を維持します。

YCQL、YEDIS、およびPostgreSQL

YugaByteには、CQLのほぼ完全な実装と、いくつかの拡張機能が含まれています。Cassandraに対する大きな改善点の1つは、YugaByteの整合性が高いのに対し、Cassandraは結果整合性があることです。その他の拡張機能は、分散トランザクション、一貫性の高いセカンダリインデックス、およびJSON用です。YugaByteは、Cassandraで必要なクォーラム読み取りの代わりに単一の読み取りを可能にする強力な一貫性のために、短距離スキャンを除くすべての操作でCassandraよりも優れています。

Cassandraは、YugaByteでまだサポートされていない4つのプリミティブデータ型(日付、時刻、タプル、およびバリント)をサポートします。YugaByteには、式にもいくつかの制限があります。 

YugaByteのRedisの実装にはリストデータ型がありませんが、時系列データ型が追加されています。組み込みの永続性、自動シャーディング、線形スケーラビリティに加えて、最も近いデータセンターから読み取る機能を追加して低レイテンシを実現します。

YugaByteのPostgreSQLの実装はそれほど進んでいません。現在、UPDATEおよびDELETEステートメント、式がなく、SELECTステートメントには結合句がありません。

YugaByteのインストールとテスト

オープンソースのYugaByteDBは、ソースコード、MacOS、Centos 7、Ubuntu 16.04以降のtarball、DockerまたはKubernetesのDockerイメージからインストールできます。次に、クラスターを作成し、3つのクエリAPIといくつかのサンプルワークロードジェネレーターをテストできます。

YugaByte DBEnterpriseをGoogleCloudPlatformにインストールすることにしました。手動で行う手順は思ったよりも多かったのですが、Enterprise Editionのライセンスキーを取得した後、1日の午後にインストールとテストを行うことができました。

YugaWareインスタンスがGoogleCloudの4CPUインスタンスで実行されたら、データベースクラスターのクラウドプロバイダーとしてGoogle CloudPlatformを構成しました。

次に、米国東部地域に8CPUインスタンスの3ノードクラスターを作成しました。

CQLAPIとRedisAPIの両方を使用して負荷テストを実行しました。

コマンドラインからCQLデータとRedisデータの両方をクエリすることができました。

また、世界中に広がるさまざまな地域に3ノードクラスターを作成しました(以下)。これは作成に時間がかかり(約45分)、予想どおり、書き込みレイテンシがはるかに長くなりました。残念ながら、光速を回避することはできません。

YugaByteの費用

3ノードのYugaByteDB Enterprise Editionライセンスの価格は、年間4万ドルからです。それに加えて、サーバーのコストを考慮する必要があります。8 CPUVMインスタンスを使用するGoogleCloud Platform上の3ノードクラスターの場合、そのコストは月額800ドルから900ドルの範囲に加えて、ネットワークトラフィック、おそらく年額11,000ドルになります。

午後のテストの私自身のコストは、インスタンスで0.38ドル、ゾーン間出口で0.01ドルでした。YugaByte DB Enterpriseインターフェイスからデータベースクラスターを削除するのは簡単で、管理およびオーケストレーションインターフェイスを実行しているVMインスタンスを停止すると、大きな料金は発生しなくなりました。

より速く、より良く、分散

全体として、YugaByteDBは宣伝どおりに機能しました。開発のこの時点では、より高速で、より優れた、分散型のRedisおよびCassandraとして役立ちます。私の経験では、特にリレーショナル結合を調整しようとする時点で、長い時間(数か月ではなく数年)がかかりますが、最終的にはより優れたPostgreSQLになるはずです。

YugaByte DBは、具体化されたSQLインターフェースがないため、Google Cloud Spanner、CockroachDB、またはAzure CosmosDBへのSQLインターフェースとまだ競合していません。グラフデータベースのサポートがないため、Neo4jやCosmosDBへのグラフインターフェイスとはまだ競合していません。これは、Redis、Cassandra、およびCosmosDBへのCassandra互換インターフェイスと競合します。

YugaByte DBを自分で試してみるべきですか? RedisまたはCassandraの分散バージョンが必要な場合、またはグローバルに分散されたシナリオでMongoDBを置き換える必要がある場合は、はい。 YugaByte DBを使用して、YugaByteの顧客であるNarvarが行ったように、CassandraデータベースとRedisキャッシングを組み合わせるなど、複数の目的で単一のデータベースを標準化することもできます。 YugaByte DBはまた、高性能のセカンダリインデックスとJSONタイプをCassandraに追加し、トランザクションデータベースとしての有用性を高めます。

YugaByte DBのオープンソースバージョンとエンタープライズバージョンのどちらが必要かは、予算によって異なります。概して、あなたがスタートアップなら、おそらくオープンソースバージョンが欲しいでしょう。多くのトランザクションデータベースアプリケーションを備えた確立されたグローバル企業である場合、特にクラスターを頻繁にスケールアップおよびスケールダウンする必要がある場合は、エンタープライズバージョンの追加機能の恩恵を受ける可能性があります。