Apache Cassandra は、JSON ドキュメントを処理するための最良のデータベースになりつつあります。あなたが Cassandra 開発者で、この発言が挑発的だと思う場合は、読み進めてください。
以前の記事では、データ API とデータ モデリングを使用して、Cassandra を開発者の考え方により慣用的な開発者エクスペリエンスに形作ることについて説明しました。これにより、妥当なデータベース パフォーマンスと規模を維持しながら、開発者の生産性が向上します。これは素晴らしい仮説であり、特定の開発者のイディオムと開発者コミュニティのコンテキストでテストする必要があるものです。
MongoDB ドライバーで通常使用されるオブジェクト データ マッピング ライブラリであるMongoose は、JavaScript 開発者の重要なコミュニティを持つオープン ソース プロジェクトです。 Cassandra と連携するように設計されたオープン ソース API データ ゲートウェイであるStargate プロジェクトでは、Mongoose と提携しており、JSON を介して動作するMongoose のバージョンと共にリリースされる予定のJSON APIに取り組んでいます。 Cassandra に接続するための API。これにより、完全にオープンソースである Mongoose 開発者向けのエンド ツー エンド スタックが作成されます。これは Mongoose 開発者にとって画期的であり、Cassandra にとって重要な新しい章を開きます。
この記事では、Cassandra と Stargate を併用して、開発者にとって使いやすい JSON イディオムを提供する方法と、Mongoose 開発者のためにそれを行うためにどのように取り組んでいるかについて説明します。
2022 年 10 月に、スターゲイトの新しいバージョンをリリースしました。新しいバージョン 2では、個々の API はコアの Stargate コーディネーター コードに組み込まれなくなり、代わりに個々のサービスに分離されました。これにより、Stargate の運用効率が向上します。個々の API サービスを個別にデプロイおよびスケーリングできるようになりました。これにより、新しい API サービスの開発も容易になります。サービス境界を遵守している限り、これらのサービスはコアの Stargate 開発作業と並行して独立して開発できます。
次に、開発者に提供できる真に慣用的なエクスペリエンスを探しました。 1,800 万人の開発者がいる JavaScript は、世界で最も人気のあるプログラミング言語であり、JSON は JavaScript 開発者がデータを構造化する標準的な方法です。しかし、1,800 万人はコミュニティではありません。それは多くのコミュニティです。 JavaScript コミュニティの「Goldilocks」が必要でした。重要なほど大きく、集中できるほど小さいものです。 MongoDB に接続するアプリケーションで使用されるオブジェクト データ マッパー ライブラリである Mongoose を中心に構築された適切なコミュニティを見つけました。マングースにはいくつかの重要な特徴があります。
開発者は、データ モデルほどデータベースと直接対話することはありません。 Stargate のオリジナルの Document API では、API は JSON を従来の Cassandra テーブルのように見せることで処理します。これにより、JSON 指向の開発者は Cassandra データ構造の観点から考える負担がかかり、JSON ドキュメントが複数の行に分散されるため、Cassandra の行指向のインデックス作成ロジックに負担がかかります。
新しい JSON API はこのデータ モデルから離れ、代わりに「スーパー シュレッディング」と呼ばれるデータ モデルに依存しています。最近のCassandra Forwardイベントでの Aaron Morton の講演を見ると、スーパー シュレッディングについて詳しく知ることができます。つまり、Cassandra の行幅が広いという性質を利用して、行ごとに 1 つのドキュメントを格納します。Cassandra の行は非常に大きなドキュメントでも処理できることがわかっています。その行には、JSON ドキュメントの標準メタデータ特性を明示的に格納するための一連の列もあります。これで、より簡単にインデックス付けできるものと、メタデータを保存および取得する手段が得られました。
次に、API がサポートする必要がある呼び出しのガイド要件として Mongoose が使用するのと同じmQuery仕様を使用して、新しい JSON API でこのデータ モデルを前面に出します。これが完了すると、構成を変更するだけで、200 万を超える Mongoose 依存アプリケーションのいずれかを、オープンソースの Cassandra または DataStax がホストする Cassandra サービスであるAstra DBに対して実行できるようになります。
Mongoose と新しい JSON API により、JSON 指向の JavaScript 開発者に完全に慣用的なエクスペリエンスを提供し、本物の JSON データ モデルを支えるCassandra のスケールとパフォーマンスを提供します。
Mongoose の作成者である Karpov は、最近の Cassandra Forward イベント (ここでリプレイを見ることができます) で講演し、Mongoose の Stargate バージョン、オープン ソースの Stargate、および Cassandra の DataStax Enterprise (DSE) バージョンを使用する単純な e コマース アプリケーションを実演しました。このアプリケーションの作業コードとサポート プラットフォーム部分をGitHubからダウンロードできます。このアプリケーションを実行するのに十分なコードがありますが、まだ完全なコードではありません。たとえば、DSE で動作し、今年後半に Cassandra 5.0 でリリースされる予定のStorage Attached Indexing (SAI) が必要なため、現在 DSE に対して実行しています。
Cassandra は静的なソフトウェアではありません。これは活気にあふれ、進化しているオープンソース プロジェクトです。そのため、クライアント側で出現するSAI などの機能を使用してデータベース側の変更を促進するという Cassandra の長年の伝統も継続しています。 Stargate の JSON API と Mongoose クライアントを改善するだけでなく、Cassandra クエリ言語に強力な新機能を追加します。これは、データ エンジニアとアプリケーション開発者が 2 つの異なるコミュニティではなく、拡大された Cassandra コミュニティの補完的なコホートであることを思い出させてくれます。
そして、JSON は最初のステップにすぎません。基本的には、Cassandra、Stargate、およびかなり効率的な Cassandra データ モデルのビルディング ブロックを使用して、JSON API を介してやり取りするドキュメント データベースを構築します。つまり、スーパー シュレッディングを使用して、Mongoose 開発者のコミュニティにより良いサービスを提供する専用のデータベースを作成しました。
Stargate v2のモジュラー アーキテクチャと、慣用的なアプローチに対する Mongoose の実証点により、特定のソフトウェア開発イディオムを中心に組織された新しい開発者コミュニティに参加する準備が整いました。私たちが Mongoose に Cassandra を利用したプロセスは繰り返し可能です。そうすることで、Cassandra が対応できる開発者とユースケースの数を劇的に拡大できます。これは、オープンソース プロジェクトに値する一種の目標です。
マーク・ストーン著。 Mark は DataStax の製品マネージャーです。彼は製品管理、プログラム管理、人材管理の分野で長年の経験を持つテクノロジーのベテランです。ビジネス関係者と技術関係者の間の結合組織の一部として常に働いている Mark は、技術プラットフォームでの開発者エクスペリエンスを擁護し、組織が開発者と出会うのを支援することを愛しています。