Apache Cassandra を使用して開発者が使いやすいデータ サービスを作成する

すべてのアプリケーションはデータに依存していますが、アプリケーション開発者はデータベースについて考えたがりません。特定のデータベースの内部構造とクエリ言語を学習すると、認知負荷が増加し、コンテキストの切り替えが必要になり、生産性が低下します。それでも、成功するアプリケーションは、応答性、回復力、およびスケーラビリティが必要です。これらのすべての特性は、データベースの選択によって決まります。

では、アプリケーション開発者はこれらの考慮事項のバランスをどのようにとるべきでしょうか?

開発者がデータベース固有のイディオムを習得することを期待するのではなく、開発者が使いやすいイディオムでデータ サービスを提供して、バランスを変えることができたらどうでしょうか?

Apache Cassandraと連携するように設計されたオープンソースの API データ ゲートウェイである Stargate プロジェクトでは、JSON 指向の開発者の条件に合う、今後のJSON APIについて公に話し始めることに興奮しています。これは、JSON 指向の開発者にとって朗報であるだけでなく、データ API と高度なデータ モデリングを活用してデータ サービスを生成するための新しい設計パターンを構成する手法です。

この記事では、Cassandra と Stargate を併用して開発者にとって使いやすいイディオムを提供する方法と、 JSONでそれを行うためにどのように取り組んでいるかについて説明します。

データ モデル: 相互運用性とイディオム

初期の頃、Cassandra は「インデックスを作成するためのマシン」と表現されることがありました。これは、Cassandra 固有の弾力性と柔軟性の証であり、より堅牢な構造を成形できる粘土でした。今日の Cassandra は、より大きな可能性を秘めたより豊かな粘土です。

それは優れたデータベースであるだけでなく、データベースを作成するための優れたマシンでもあります。ここ Stargate プロジェクトでは、データベース開発における新しいパラダイムの最初の例として、JSON API を使用してこれを証明しています。

あるデータベースが別のデータベースから構築されることは珍しくありません。十分に掘り下げれば、MongoDB でさえWiredTigerの上に構築されます。 AWS は、DynamoDB に MySQL ストレージ エンジンを使用するなど、舞台裏で MySQL を広範に使用していることで知られています。したがって、固有のスケーラビリティとパフォーマンスを備えた Cassandra を他のデータ システムのビルディング ブロックとして使用するという考えは理にかなっています。

しかし、アプリケーション開発者は実際にはデータベースと対話しません。組織が独自のデータベース インフラストラクチャを管理し、そのインフラストラクチャに対してアプリケーションを構築する場合でも、通常、最初の手順は、アプリケーションに必要なデータ モデルを定義して実装することです。

これらのデータ モデルは、アプリケーションとデータベースの間を仲介します。ある意味で、データ モデリングはデータベースを制限します。成形されていない、つまり汎用の粘土を使用して、特定のアプリケーションの慣用句専用に構築されたものに成形します。慣用的なもののために相互運用性を犠牲にしています。

慣用的なものと交換して、相互運用可能なものを放棄するのは良い考えですか?平均を上回りたいのであれば、答えは強調して「はい」です。データベースを選択するときはあまり考えませんが、プログラミング言語を選択するときは長い間このように考えてきました。

この考えは、何十年も前にPaul Graham によってよく表現されており、Viaweb がどのようにして初期のドットコム レースに勝利し、最初の広く成功した Web ベースの e コマース プラットフォームを作成したかを説明しました。

Viaweb は、必ずしも最速または最もスケーラブルな e コマース プラットフォームではありませんでした。 Graham の言葉を借りれば、それは「かなり効率的」でした。代わりに、Graham は、プログラミング言語については、機械可読から人間可読までの規模で、より人間可読な (したがって高レベルの) 言語は、開発者の生産性を向上させるため、より強力であると主張しています。そして、Viaweb の時代、グラハムは最も強力な言語はLispだと考えていました。グラハムの主張の要点は次のとおりです。

「私たちの仮説は、Lisp でソフトウェアを作成すれば、競合他社よりも速く機能を実行できるようになり、競合他社ができないことをソフトウェアで実行できるようになるというものでした。また、Lisp は非常に高レベルだったので、大規模な開発チームは必要なく、コストも低く抑えられました。もしそうなら、私たちはより良い製品をより少ないお金で提供し、それでも利益を上げることができます.最終的にはすべてのユーザーを獲得することになり、競合他社はユーザーを獲得できず、最終的に廃業することになります。」

開発者の生産性を解き放つ

Graham は 20 年前にこの言葉を書きましたが、開発者の生産性は今でも技術革新の多くを導く北極星です。グラハムが高水準言語のパワーについて語っているところでは、開発者のソフトウェア開発経験により慣用的なツールを開発者に提供するという同じ概念を表現しています。

Graham は Lisp を称賛しており (当然)、ドットコム時代以降、Ruby や Rust などの新しい高水準言語が急増しています。また、Swift、Flutter、Dart などのモバイル デバイス開発者用言語とフレームワークの誕生と普及も見られました。

では、なぜ C やC++のような言語がまだ重要なのでしょうか? C に関する古いジョークには、「アセンブリ言語のパワーとアセンブリ言語の使いやすさを組み合わせる」という重要な真実があります。コンパイラを書きたい場合は、機械語のイディオムに近づき、自然言語のイディオムから離れる必要があります。

言い換えれば、他の長所の中でも、C と C++ は新しい言語を構築するための機械です。 Graham が Lisp を称賛する中で見落としやすいのは、Lisp にもこの「言語を構築するための機械」の特徴がいくつかあるということです。

Lisp は、マクロの概念を導入した最初の広く使用されている言語であり、Lisp に慣れていない人がつまずくのはマクロの概念であることがよくあります。マクロを理解すれば、Lisp は言語というよりもメタ言語であり、マクロを使用して特定の問題領域専用の言語を構築できることが理解できます。

マクロの最初のセットを設計して作成することは難しく、知的に挑戦的な作業です。しかし、Graham と Viaweb チームがそれを実行すると、事実上、使用する e コマース プログラミング言語が手に入り、開発者の生産性が向上し、競合他社をしのぐことができるようになりました。

20 年後、これらすべてはプログラミング言語のコンテキストで十分に明確に見えます。では、データベースの世界では何が起こったのでしょうか?簡単に言えば、データベースの進化はよりゆっくりであるということです。

データ API 革命

表形式データがデータベース世界のアセンブリ言語である場合、SQL はクエリ言語の C/C++ です。コンピューティングとストレージが高価だった時代に、スキーマの変更が比較的まれで明確に定義されたユースケースのために、表形式のデータ構造とデータ正規化の概念を開発しました。その文脈では、あらゆる規模で効率的に運用するために、データベースはコンピューターが情報を保存してアクセスする方法を厳密に模倣する必要がありました。

今日の世界は逆であり、比較すると昔のように思えます。コンピューティングとストレージのコストは非常にコモディティ化されていますが、機械学習と人工知能が組み合わされたリアルタイム データの世界では、ユース ケースは無限であり、スキーマの変更は簡単ではありません。頻繁。

データベース テクノロジにおける最新の革命は、NoSQL 革命でした。これは、リレーショナル データベースの世界の高僧によって定められた、表形式の正規化されたデータの規範への直接的な対応です。 「NoSQL レボリューション」とは、 Google がMapReduce ホワイト ペーパーを発表した 2004 年から、Amazon がDynamo ホワイト ペーパーを発表した 2007 年までの期間を指します。

この期間から出現したのは、2 つの重要なリレーショナルの原則を破棄することで、前例のない速度、スケーラビリティ、回復力を達成したデータベースのファミリーでした。 2008 年に最初にリリースされた Cassandra は、この革命から生まれました。

Data API は、データベース テクノロジの次の主要な革命であり、まだ始まったばかりです。データベースの世界の変化は、プログラミング言語やアプリケーション開発の変化より遅れる傾向にあります。したがって、RESTful API はしばらく前から存在し、分散サービス指向アプリケーションのアーキテクチャの先駆けとなってきましたが、データ API がアプリケーション インフラストラクチャの重要な部分として明らかになり始めたばかりです。

この革命の重要性と、Paul Graham の宣言から 20 年後、データベースの世界が開発者の生産性をどのように向上させているかを理解するために、Stargate 自身のストーリーを見てみましょう。まず、相互運用性と慣用性というテーマに戻ります。

Stargate: 忠実度の高い、慣用的な開発者エクスペリエンス

Cassandra エコシステムにデータ ゲートウェイが必要であると判断したとき、緊急に Stargate API のオリジナル セットを構築しました。それはモノリシックなアーキテクチャを意味しました。モノリスは構築が高速ですが、常に優れているとは限りません。 Cassandra Query Language (CQL) API、REST API、RESTful ドキュメント API をリリースしました。 GraphQL を追加の API としてすぐに追加しました。今日まで、Stargate は相互運用可能でした。 Stargate のすべては、ネイティブの CQL データ モデルを使用して保存されるため、原則として、任意の API から任意のテーブルをクエリできます。

実際には、誰も実際にこれを行っていないことを学びました。開発者は、特定のイディオムに固執します。相互運用性を優先することで、開発者のエクスペリエンスに Cassandra 主義を取り入れ、開発者の生産性を妨げました。 Stargate の元のバージョンでは、開発者が Cassandra の幅の広い表形式のデータ構造を理解し、キースペースとパーティションを理解する必要があったため、マシンのイディオムに近すぎて、人間のイディオムから離れすぎました。

相互運用性の落とし穴は、目的に合わせた組み込みのデザイン思考よりも汎用性を優先することです。私たちは、より具体的な表現方法と一般的な機能を交換して、人間の慣用句に近づき、機械の慣用句から遠ざける、専用の観点から考えることに軸足を移しました。 Cassandra の NoSQL 基盤の利点 (スケール、可用性、パフォーマンス) を維持しながら、忠実度の高い慣用的な開発者エクスペリエンスを提供できるかどうかを考え始めました。

その鍵はデータモデリングにあります。 Cassandra を「データベースの Lisp」に変えるには、Lisp マクロに似た目的を果たすことができるデータ モデルと、開発者がそのデータ モデルと慣用的にやり取りできるようにする Stargate API が必要でした。アプリケーション開発者の間でデータ構造の最大の共通点である JSON から始め、Stargate 用の JSON API の構築を開始しました。次に、Cassandra で JSON をモデル化する最善の方法を見つけなければなりませんでした。

Stargate にはすでに Document API がありますが、Stargate の元の Document API では、 「シュレッディング」と呼ばれるデータ モデルを使用して、JSON ドキュメントを Cassandra テーブルとしてレンダリングしました。このモデルは、1 つのドキュメントを 1 つの Cassandra テーブルの複数の行にマップし、相互運用性を維持します。 CQL を使用して結果のテーブルをクエリすると、意味のある結果が返されます。

この元のシュレッディング データ モデルには欠点があります。ドキュメントに関するメタデータは保持されません。たとえば、配列を含むドキュメントの場合、ドキュメントが作成されると、ドキュメントを完全に検査しない限り、配列のサイズについては何もわかりません。さらに重要なことは、インデックス作成に関する Cassandra の期待から逸脱したことです。 Cassandra は行にインデックスを付けますが、ドキュメントを複数の行に分散させたため、ドキュメントのネイティブ Cassandra インデックスを作成できなくなりました。

Cassandra を JSON に適したストレージ エンジンにするためには、シュレッディングよりも優れた新しいデータ モデルが必要でした。私たちはそれを「スーパーシュレッディング」と呼んだ。スーパー シュレッディングの詳細については、12 月に開催される Aaron Morton のCassandra Summit の講演で学ぶことができますが、ここで少しティーザーを紹介します。Cassandra の行ごとに 1 つのドキュメントを格納するために、Cassandra の幅の広い列の性質を利用しています。ドキュメント。

その行には、JSON ドキュメントの標準メタデータ特性を明示的に格納するための一連の列もあります。これで、より簡単にインデックス付けできるものと、メタデータを保存および取得する手段が得られました。

Cassandra への貢献

はい、これらすべてを大規模に機能させるには、Cassandra にいくつかの基本的な変更が必要です。 Apple が Cassandra 5 に貢献している Accord は、よりトランザクション的な方法でデータ変更を処理するのに役立ちます。 DataStax が Cassandra 5 に貢献しているStorage-attached indexing (SAI) と Global Sort は、JSON ドキュメントに対する範囲指定クエリをより効率的な方法で処理するのに役立ちます。

Cassandra は静的なソフトウェアではありません。これは活気にあふれ、進化しているオープンソース プロジェクトです。そのため、クライアント側で発生する要件を使用してデータベース側の変更を促進するという Cassandra の長年の伝統も継続しています。ユーザーのニーズにより、Accord、SAI、および Global Sort の提案が促されました。これらは Stargate の JSON API を改善するだけでなく、Cassandra を改善します。これは、データ エンジニアとアプリケーション開発者が 2 つの異なるコミュニティではなく、拡大された Cassandra コミュニティの補完的なコホートであることを思い出させてくれます。

そして、JSON は最初のステップにすぎません。基本的に、Cassandra、Stargate、およびかなり効率的な Cassandra データ モデルから、JSON API を介してやり取りするドキュメント データベースを構築します。スーパーシュレッディングは私たちのマクロです。このアプローチにより、Cassandra はデータベースを作成するためのマシンになります。

このアプローチは、Cassandra 以外の別のデータベースで使用できますか?簡単ではありません。その理由は次のとおりです。 Cassandra に有利に働く熱力学第二法則の一種のデータベース類似物があります。私たちは、高速でスケーラブルで回復力のあるものから始めますが、開発者にとってあまり慣用的ではありません。合理的な効率の制約内で、開発者に提示するより慣用的なインターフェイスと、その速度、規模、回復力の一部を交換します。簡単にできないことは、逆方向に行くことです。非常に慣用的なものから始めて、それを高速でスケーラブルで回復力のあるものにする方法を見つけようとすることは、不可能なほど困難な作業です。

この熱力学的原理が、データ API が新しいデータベース革命である理由であり、Cassandra がこの革命を推進するデータベースである理由です。

こちらにも掲載。