paint-brush
データベースが API として公開される理由@datastax
1,468 測定値
1,468 測定値

データベースが API として公開される理由

DataStax6m2023/04/17
Read on Terminal Reader

長すぎる; 読むには

Stargate は、開発者が API を操作する方法を簡素化するオープン ソース プロジェクトです。データベースの複雑さを隠す抽象化レイヤーを提供します。 API は、さまざまなスタイルの gRPC、REST などを介してデータへのアクセスを提供するインフラストラクチャの一部です。
featured image - データベースが API として公開される理由
DataStax HackerNoon profile picture

アプリケーションは、本番環境に導入されるまでは価値がありません。開発者にとって、この時点に到達するということは、データベースの起動、管理、保守の詳細について心配することなく、構築する必要があるデータに簡単にアクセスできることを意味します。


API は、アプリケーションをデータベースに接続するためのデファクト スタンダードになりましたが、常にそうであったわけではありません。ここでは、データベースを API として公開することの重要性を高めるために、ソフトウェアの世界で何が変化したかについて説明します。また、開発者がこれらの API を使用して作業する方法を簡素化するオープン ソース プロジェクトである Stargate についても説明します (スケーラビリティと柔軟性の改善を含む Stargate の最新バージョンが最近リリースされました)。

データベースを使用するソフトウェアの構築方法

データベース管理者 (DBA) は、開発者がデータとやり取りする方法を設計するためにデータベースの専門家を必要としたため、クエリを担当していました。しかし、最近まで、開発者は、SQL、クエリ、またはデータ モデルの専門家でなくても、データベースとのやり取りについて多くのことを知っていることが期待されていました。


私は 1990 年代に熟達した開発者でしたが、データベースは私を怖がらせました。 SQL を快適に使用できるようになるまでには、何年もかかりました。また、単に「SQL に似たもの」を提供するだけでは不十分です。 CQL (Cassandra Query Language) は、Apache Cassandra と通信するための SQL に似たクエリ言語を提供するために開発されました。そのアイデアは、Cassandra と通信するための抽象化を提供し、リレーショナル データベースに慣れている人が簡単に通信できるようにすることでした。


しかし、ネットワークの世界では、クエリ言語から完全に切り離された、ID、アクセス許可、およびセキュリティの新しい概念があります。ドライバーが単にバイナリ プロトコルで通信するという概念は、クラウドではうまく機能しません。 HTTP はクラウドの基本的なアプリケーション層プロトコルですが、ほとんどの HTTP ベースの API は低速です。 gRPC などの低レイテンシ オプションは、分散システムでのリアルタイム通信に不可欠です。

ソフトウェアがソフトウェアと対話する方法

クライアントまたはアプリ サーバーがデータベースと対話するために使用する標準的な方法には、データ センター内で実行されるドライバーが含まれていました。現在、すべてがクラウドで実行されていますが、開発者はさまざまな言語で記述しています。 JavaScript 、Python、またはさまざまなフレームワークのホストのいずれかが使用される可能性があるため、ソフトウェアがデータにアクセスする手段は、API (JSON、gRPC、 GraphQL 、またはドキュメント) を使用して、従来のデータベース ドライバーとは異なる方法で抽象化する必要があります。開発者は快適です。


ソフトウェアがソフトウェアと対話する最新の方法は API です。データベースの複雑さを隠すのは抽象化レイヤーです。

データの性質

以前は、データははるかに均一でした。データベース テーブルの行と列にきちんと収まります。しかし、データのダイナミクスは変化しています。データは、ソフトウェアの介入をあまり必要とせずに、シームレスな方法でメモリ内表現からデータベースに戻ります。そして、人々が扱っていたデータ プリミティブよりもはるかに堅牢な新しいタイプのデータ フォーマット、または SQL で扱える半ダースほどのデータ タイプを扱っています。

データベース API

API は、今日の開発者がデータベースを操作する方法です。理由をまとめると次のようになります。

  • HTTP はクラウドのネットワーク プロトコルです。多くの開発者は既に Web API に精通しており、HTTP を使用すると、クラウド アプリケーションのデプロイがはるかに簡単になります。
  • データベースをローカルにインストールして実行する必要はありません。データベースをローカルにインストールするには労力が必要であり、問題をデバッグする必要があるさらに別の環境が作成されます。

シンプルさ、スケーラビリティ、拡張性へのゲートウェイ

データ API ゲートウェイは、REST、gRPC などのさまざまなスタイルの API を介してデータへのアクセスを提供するソフトウェア インフラストラクチャの一部です。ゲートウェイは、1 つ以上の永続ストアを使用して、データの保存と取得の詳細を抽象化します。これにより、アプリケーション開発者は、複雑なデータベース クエリ言語を学習する必要がなくなり、使いやすい API を介してデータにアクセスするビジネス サービスの作成に専念できます。


Stargate は、アプリとクエリが必要なデータベースの間に位置するオープン ソース データ API ゲートウェイです。 Apache Cassandra は 2020 年 9 月に初めて導入されました。Apache Cassandra が最初のデータベースとして選ばれた理由の 1 つは、世界で最も困難なスケーラビリティと可用性の課題を解決できることです。


データ API ゲートウェイは、開発者が使い慣れたフレームワークと構造で作業できるようにする強力な方法であり、生産性とパフォーマンスの間のさまざまなトレードオフを提供します。 Stargate は、REST、Document、および GraphQL をシンプルな API として提供することで、Cassandra のパワーを提供します。また、パフォーマンスを犠牲にすることなく、CQL のネイティブ ドライバーに代わる、より簡単で軽量でクラウドに適した代替手段として、gRPC を介して CQL を実行するための一連の gRPC ライブラリも提供します。


今年、 DataStaxの Stargate エンジニアリング チームは、Stargate のアーキテクチャの更新に取り組んできました。スターゲイト v2 は、 2022 年 10 月にリリースされました。 Stargate 開発者コミュニティからのフィードバックに基づいて、Stargate v2 では、開発者が使いやすく、コミュニティがプロジェクトに貢献しやすくするためのいくつかの重要な更新を行いました。最も重要なことは、Stargate v2 の高性能 gRPC API が、ネイティブ データベース ドライバーと同等の速度を提供できることです。これにより、開発者は HTTP などのクラウドに適したネットワーク プロトコルを使用してアプリやデータベースに接続でき、ネットワーク上でパフォーマンスを低下させることはありません。

拡張性と適応性

今月のトップダウンの戦略や API のフレーバーは、開発者の大規模なプールとの接触を生き延びたことはありません。 Stargate v2 の主な目標は、実装自体の理解、デバッグ、強化、拡張を容易にすることで、コミュニティが新しい API サービスを迅速かつ簡単に追加できるようにすることです。


新しい API サービスの追加がはるかに簡単になりました。REST、GraphQL、およびドキュメント API サービスのソース コードは、完成した API サービスがどのように見えるべきかを示す有益なサンプル コードを開発者に提供します。


API 層はマルチモデルである必要があります。開発者は、自分の開発作業を別の API に適応させることを余儀なくされるのではなく、好みの API をすぐに利用できるようにしたいと考えています。また、API が利用できない場合は、API 層が適応できる必要があります。

クラウド ネイティブ

データベースの前にコードをスローすることは、何年も前から行われてきました。しかし、データベースに合わせてスケーリングでき、適応性と信頼性に優れたプラットフォームを実際に構築することは、新しいことです。 Cassandra を使用している場合は、おそらくすでに高成長アプリであるか、高成長を目指しています。そのため、その前にあるものはすべて、高成長環境を促進する必要があります。 Stargate は、Cassandra コーディネーター コードのフォークとして誕生したため、Cassandra がよく知られている信頼性と可用性の多くを継承しています。


API 層は大規模な運用に完全に対応できる必要があるため、Stargate v2 のもう 1 つの目標は、よりクラウドに適したものにすることでした。 Stargate のスケーラビリティを促進するためのいくつかの変更には、次のものがあります。

  • Stargate は完全にコンテナー化され、Kubernetes ポッド内で実行されるようになりました。これにより、オペレーターはワークロードのスケーリング方法をより詳細に制御できます。

  • API サービスは、モノリシックな Stargate ノードから個別のマイクロサービスに移動されました。これにより、各 API を個別にスケーリングできるようになります。

  • ストレージ ノードとコーディネーター ノードは、個別に展開可能でスケーラブルであるため、オペレーターはワークロードのスケーリング方法をより詳細に制御できます。


ワークロードがクエリまたはストレージを集中的に使用する場合、クラスター全体を全体としてスケーリングすることに頼らずに調整できます。

使い慣れたもので開発する

クラウド データ サービスはテクノロジの世界で支配的なテーマになっているため、開発者が特定のデータベースに固有のイディオムではなく、JSON のようなデータ抽象化の観点から考える傾向があることは驚くことではありません。 Stargate は、開発者が慣れ親しんだフレームワークや構造で作業できるようにするために、開発者がいる場所に会うための多くの努力の集大成です。


スターゲイトの詳細については、こちらをご覧ください。


エド・アナフ著。

Ed は DataStax の最高製品責任者です。彼は、Google、Apigee、Six Apart、Vignette、Epicentric、Wired などの企業で製品および技術のリーダーとして 25 年以上の経験があります。



ここにも掲載されています。