Clever Geek Handbook

注目すべき新しいデータベーステクノロジー（パート1）

この記事では、私たちが興味を持っている3つの最近のデータベーステクノロジーについて説明します。





2番目の記事では、さらに3つについて説明します。





そして、3番目の記事は結論に専念します。



注：これはコアテクノロジーのみに焦点を当て、エンタープライズ機能などの機能はほとんど無視されます（適切な場合）。



TileD B



TileDBは、多次元配列を中心に構築されたデータベースです。これにより、既存のリレーショナルデータベース管理システム（RDBMS）に完全には適合しないデータタイプ（たとえば、密な配列と疎な配列、データフレーム）での作業を簡素化できます。TileDBは、ゲノミクスや地理空間データなどのユースケース向けに特別に調整されています。



注目すべき機能





私が特に好きだったもの



特定のデータタイプとタスクのセット用にシャープ化された、このような「高度に専門化された」データベースが好きです。もちろん、従来のRDBMSは、非常に幅広いユースケース（冗談なし）をカバーするための比較的汎用性に優れています。ただし、極端な場合には、（a）「従来の」システムの機能が十分ではなく、（b）タスクがビジネスにとって非常に重要である場合があります。



データベースのユースケースの専門化が進み、新しい主題分野が出現するにつれて、他の同様のシステムが出現すると予想されます。もちろん、古き良きRDBMSはどこにも行きませんが、TileDBや他の同様のシステムがどのように開発され、可能なことの境界を拡大するかを見てみたいと思います。特定のユースケースに非常に固有のデータタイプを操作できるように、プラグインを接続するためのインターフェイスを備えた、非常に「ハッキング可能な」非モノリシックデータベースが存在することを願っています。しかし、それについては後で詳しく説明します。



プロジェクトへの質問



  1. ? TileDB , , , ? .
  2. - ? , «TileDB -». ?


Materialize



マテリアライズは「最初の真のストリーミングSQLデータベース」として販売されており、おそらくこれは誇張ではありません。これは基本的に、PostgreSQLと「ワイヤー互換」なリレーショナルデータベースですが、重要な違いが1つあります。それは、リアルタイムで更新されたマテリアライズドビューを提供することです。



マテリアライズの「ストリーミングストレージ」の定義がありますが、これはうまくいくようです。



たとえば、標準のPostgresでは、マテリアライズドビューを手動で更新する必要があります。 



CREATE MATERIALIZED VIEW my_view (/* ... */);
REFRESH MATERIALIZED VIEW my_view;
/* The underlying tables change */
REFRESH MATERIALIZED VIEW my_view;
/* More stuff happens */
REFRESH MATERIALIZED VIEW my_view;


これは、たとえば、スクリプトまたはスケジューラタスクを使用して、任意の頻度で実行できます。私たちがまだ見たことがないのは（私たちはいつも本当に見たかったのですが）、マテリアライズドビューの増分更新をネイティブにサポートするデータベースです。はい、確かに：マテリアライズは、指定されたデータソースの変更を追跡し、これらのソースの変更に応じてビューを更新します。



マテリアライズが成功しないか、市場に十分長く留まらない場合でも、マテリアライズが提供する機能は継続する必要があり、ほぼ確実に他のデータベースに複製されます。



注目すべき機能



  • , ( Postgres), JSON, CSV , Kafka Kinesis, .
  • : «» (timely dataflow) «» (differential dataflow). , . Materialize, , , Materialize — « », , .
  • Materialize «» Postgres, psql Postgres.




マテリアライズは、多くを置き換える可能性があります。最も明白なこと：システムでは、利用可能なすべてのプロセスを使用して、マテリアライズドビューを段階的に更新できます。しかし、それは大きな勝利ではありません。



私たちにとってはるかに重要なのは、マテリアライズを使用すると、データソースの変更を追跡するために割り当てられたデータスタックの部分を非アクティブにできることです。これはネイティブに行うことができます： 



CREATE SOURCE click_events
FROM KAFKA BROKER 'localhost:9092' TOPIC 'click_events'
FORMAT AVRO USING CONFLUENT SCHEMA REGISTRY 'http://localhost:8081';


これで、データベースは、自動的に更新されるマテリアライズドビューを構築するために使用できるデータソースを「認識」します。このネイティブの「パイプライニング」は、ビューの自動更新よりもさらに魔法のように思えます。たとえば、サーバーレス関数、Heronジョブ、または追跡のみを行うFlinkデータパイプラインを実行し、そこINSERTに演算子を追加すると、Materializeを使用すると、スタックのその部分を簡単に削除できます。



プロジェクトへの質問



  • なぜPostgres拡張機能ではなく別のDBなのですか？ここで拡張機能がこのように機能しないのには、アーキテクチャ上の理由があると確信していますが、その理由を知りたいと思います。
  • 他のデータソースの拡張機能を構築するのはどのくらい簡単ですか？たとえば、Apache Pulsarの拡張機能をどのように作成できますか？この目的のために開発者にAPIを公開する計画はありますか？


プリズマ



Prismaは、データベースを可能な限り抽象化するための一連のツールよりもデータベースではありません。このシステムは現在、データベース側でPostgreSQL、MySQL、SQLiteと互換性があり、言語に関してはJavaScriptとTypeScriptと互換性があります（将来的には他のデータベースと言語をサポートする可能性があります）。これは「最新のアプリケーションのデータレイヤー」として請求されますが、これは一般的に当てはまります。



Prismaを使用する「黄金の方法」は次のようなものです。



  1. PrismaのSDLスキーマを使用して、アプリケーションレベルでデータタイプを定義します。
  2. 作成されたスキームに基づいて、選択した言語の非常に慣用的なコードを生成します。
  3. REST API、GraphQL API、およびその他の構築したいものの構築に忙しくなります。


Prismaのようなツールについて一部の人々が抱く疑問を理解しています。データベースの抽象化に反対する開発者の大規模なグループがあります。スマートDSLやGUIは必要ありません。彼らは単純なSQLを記述し、すべてのデータベース対話コードを手作業で作成したいと考えています。この程度の制御を維持したいという願望は理解していますが、それでもPrismaを試すのに20〜30分を費やすことをお勧めします。「ブルートフォース」と生のSQLの間の「黄金の平均」を見つけるのに非常に良い仕事をしているように私たちには思えます。



注目すべき機能







PrismaのスキーマDSLを使用すると、アプリケーションに必要なデータタイプを指定できるだけでなく、使用するコードジェネレーター、および接続先のデータベースの接続情報を決定することもできます。



また、タイプ（列挙型）、などの便利な注釈を列挙し@id、@relationそして@default。ActiveRecordおよびEctoからデータベースを移行するためのDSL、およびProtocolBuffersおよびThriftで使用されるものと同様のIDLを彷彿とさせます。



PrismaのSDLスキーマ、または言語に依存しない標準（言語固有のライブラリに適した）に類似したものを採用したいと思います。現状は、すべてのプログラミング言語が車輪を再発明することを前提としています。アプリケーションとデータベース間の相互作用を定義するタイプを定義する言語に依存しない方法があると便利だと思います。



ちなみに、優れたドキュメントを提供してくれたPrismaに特に感謝します。これは間違いなく重要な違いであると考えています。ドキュメントがブログ投稿の「最も気に入ったもの」セクションに該当しない場合は、ホワイトペーパーの作成により多くのリソースを投資する必要があります。



プロジェクトへの質問



Prismaは、すでに広く使用されているオブジェクトリレーショナルマッピング（ORM）の言語でも役立ちますか？ActiveRecord forRubyまたはEctofor Elixirを使用している場合、切り替える動機は何ですか？


More articles:


All Articles