注目すべき最新データベース技術（パート１）

この記事は、著者の許可を得て配信しています。
https://blog.pragmaticengineer.com/the-developer-culture-test/

私はデータベースの大ファンで、いわゆる「NoSQL」データベースに関する本を書いたり、影響力の高い分散型データベースRiakに携わったりと、技術職として最も実りある年のいくつかを過ごし、昨年は楽しみのためにPurpleというデータベースを構築したりもしました。

当然のことながら、私はTwitterやReddit、HackerNewsなどをさらっと読む場合、データベースやDB関連ツールの新しくて刺激的な開発に常に気にして見ています。今回の記事では、私が興味をそそられる最近登場した3つのデータベース技術についてお話したいと思います。

• TileDB
• Materialize
• Prisma

後半では次の３つについてお話したいと思っています。

• EdgeDB
• Tremor
• Debezium

パート3では、最後にいくつかの考えを述べて締めくくりたいと思います。注: 私はもっぱらコアな技術に焦点を当て、エンタープライズ機能（該当する場合は）のようなものはほとんど無視しています。

私の選択基準は純粋に主観的なものです。ここにないもので、私がチェックすべきだと思うものがあれば、私にツイートして教えてください！私のハンドルネームは @lucperkins です。

TileDB

TileDBは多次元配列を中心に構築されたDBで、密な配列や疎な配列、データフレームなど、既存のRDBMSシステムにはあまり適していないタイプのデータを簡単に扱うことができます。TileDBは、ゲノミクスや地理空間データなどのユースケースに特化しています。

注目すべき特徴

• Amazon S3, MinIOまた他のものに対応したスワップ可能なデータバックエンド
• HDFS, PrestoDB, Apache Spark, Dask, また他のもののストレージ統合
• C/C++, Python, R, Java, Goのための言語バインディング

気に入っているところ

私は、特定のデータタイプや問題に特化した、このような優れた技術の「専門的な」DBのファンです。従来のRDBMSの素晴らしいところは、ユースケースの非常に広い配列をカバーするのに十分な汎用性を持っていることですが、時には（a）「キッチンシンク」システムの能力を超えた、（b）ビジネスの中核をなす「ラストワンマイル」のエッジケースがあることです。

データベースのユースケースがこれまで以上に専門化し、新しい問題領域が出現するにつれて、このようなシステムがもっと登場することを期待しています。もちろん、保守派のRDBMSはどこにも行かないだろうが、TileDBやその他の企業が限界に挑戦しているのを見るのは励みになります。私が本当に期待しているのは、「ハッキング可能」で、ユースケースに特化したデータ型のためのプラグインインタフェースを提供する、断固として非モノリシックなDBの出現ですが、これについては後ほど話すことにしましょう。

プロジェクトに対する疑問

1. クライアント・ライブラリ側とデータベース側では、どのくらいの作業が行われているのでしょうか？TileDBクライアントは、複雑なデータ型をローカルに操作し、時々その結果を目的のバックエンドに保存するための、本質的に言語固有のmath librariesなのでしょうか、それとも他のDBクライアントライブラリのように、ほとんどがデータベースにコマンドを中継するだけのものなのでしょうか？ドキュメントを見てもよくわかりません。
2. 既存のK/Vオプションの多さを考えると、キーバリューストアを提供する根拠は何でしょうか？ドキュメントには、「TileDBは特別な目的のキーバリューストアとして動作するように設計されていない」とさえ書かれています。このような機能を自由が効かないようにコントロールすることに何の価値があるのでしょうか？

Materialize

Materializeはウェブサイト上で「初の本物のSQLストリーミングデータベース」と謳っていますが、これはあながち嘘ではないかもしれません。これは基本的にPostgreSQLとワイヤ互換性のあるリレーショナルデータベースですが、リアルタイムで更新されるマテリアライズド・ビューを提供するという決定的な違いがあります。

Materializeがストリーミングデータウェアハウスとして説明されているのを見たことがありますが、これは適切な説明だと思います。

例えば、標準の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;

これは、スクリプトやcronジョブを使って、好きなだけ頻繁に行うことができます。しかし、私はまだ見たことがありませんが、常に密かに欲しかったものは、ネイティブでマテリアライド・ビューのインクリメンタルアップデートに対応しているデータベースです。そう、その通りです。Materializeはあなたが指定したデータソースの変更をリッスンし、それらのソースの変更に応じてビューを更新します。

たとえMaterializeが 「勝利 」しない、もしくは長くは続かなかったとしても、有益な機能はここに留まり、将来的にはほぼ確実にDBで再現されることになるでしょう。

注目すべき特徴

• 他のテーブル（標準のPostgresのように）、JSON、CSV、その他のファイル、KafkaやKinesisのトピック、そして将来的には他の多くの可能性のあるデータソースを含む多様なデータソースである。
• コアエンジンは、タイムリーデータフローと差分データフローという、本当に強力な2つの構造を持っている。ここではこれらについては触れませんが、これらの概念を自分で掘り下げてみることを強くお勧めします。Materializeの非常にアカデミックなクリエイターは、両方のプロジェクトに深く関わってきたので、Materializeが「ハッカー的な倫理観」ではなく、非常に慎重に、迅速に行われたプロセスの産物であるということが確信できる。
• Materialize は Postgres とのワイヤ互換性があるので、psqlや慣れ親しんだ他の Postgres ツールを今でも使うことができる。

気に入っているところ

Materialize は、多くのものに置き換わる可能性を秘めています。最も明らかなのは、マテリアライズド・ビューを段階的に更新するための既存のプロセスを完全に放棄できるということです。これも、とてもいいメリットだと思います。

しかし、私にとっての最大のメリットは、Materializeを使用することで、データスタックのうち、データソースの変更をリッスンするために使用していた部分を廃止できるということです。このようなことをネイティブで行うことができます。

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

あなたのDBは、自動更新のマテリアライズド・ビューを構築するために使用できるデータソースを 「認識 」するようになりました。このネイティブな「パイピング」は、ビューの自動更新よりもさらに不思議な感じがします。例えば、サーバーレス関数やHeronジョブ、Flinkパイプラインを実行していて、ここをリッスンしてそこにINSERT文を書いている場合、Materializeを使うことで、スタックのその部分をあっさりと切り取ることができます。

プロジェクトに対する疑問

• なぜPostgresの拡張ではなく、別のDBを使うのか？ここでは拡張機能が必要ではない理由として、アーキテクチャ上の理由があると思うが、それが何なのかを知りたい。
• 他のデータソース用の拡張機能を構築するのは簡単か？例えば、Apache Pulsar用の拡張機能はどうやって書けばいいのか？開発者にこのAPIを公開する予定はあるか？

Prisma

Prismaはデータベースではなく、可能な限りデータベースを抽象化しようとするツールのセットです。現在、DB側ではPostgreSQL、MySQL、SQLiteと互換性があり、言語側ではJavaScriptとTypeScriptと互換性があります（さらに多くのDBと言語に対応していく予定です）。「モダンアプリケーションのためのデータレイヤー」と自画自賛していますが、全くその通りだと思います。

Prismaを使用するための方法です。

1. PrismaのスキーマSDLを使用して、アプリケーションレベルのデータタイプを設定します。
2. 作成したスキーマから、選択した言語用の高度に慣用的なコードを生成します。
3. REST API、GraphQL API、その他構築したいものは何でも作成してください。

全体的には、Prismaのようなツールの使用に対して、躊躇している人がいるということを理解しています。開発者の大部分は、データベースの抽象化を望んでいません。彼らは賢くて便利なDSLやGUIを望んでいません。彼らはプレーンなSQLを書きたいと思っていて、すべてのDBインタラクションコードを自分の手で書きたいと思っています。その程度のコントロールを維持したいという気持ちは完全に理解できますが、それでも20～30分の時間を取ってPrismaを試してみることをお勧めします。Prismaは、あまりにも手間のかかるツールと生SQLの間の中間くらいで、とてもいい仕事をしてくれるツールだと思います。

注目すべき特徴

• Prisma Clientを使用すると、コードを生成するためだけの専用スキーマSDLを使用して、必要なデータタイプを設定できます。データベースの接続情報さえも、アプリケーションコードから消え、生成されたコードに行きます。
• Prisma Migrateを使用すると、（SQLのように強制的にではなく）宣言的にDBの移行を設定することができます。DBがどのようにして状態Aから状態Bに移行するかという面倒な詳細は見えなくなります。
• Prisma Studioがあれば、他のPrismaツール全体にGUIを利用できるようにするビジュアルエディタです。

気に入っているところ

PrismaスキーマDSLは、アプリケーションに必要なデータタイプだけでなく、どのコードジェネレータを使用するかを設定したり、接続先の DB の接続情報を設定する方法です。

さらに、列挙型（ enum）、@id、@relation、@defaultのような便利なアノテーションを提供します。ActiveRecordやEctoのDB移行DSLと、Protocol BuffersやThriftで使われているようなIDLの両方を彷彿とさせます。

PrismaスキーマSDLやそのようなものが、言語ニュートラルな標準（言語固有のライブラリで使用可能）として導入されるのをぜひ見てみたいものです。現状では、すべてのプログラミング言語が土台からやり直しています。アプリケーションとDBの関係を設定する型を言語にとらわれない方法で設定することはとてもメリットのあることだと思います。

それに関連したことですが、Prismaの非常に美しいドキュメントへの称賛の言葉があるそうです。もしあなたのドキュメントがブログ記事の「私が最も好きなもの」のセクションに属していないのであれば、皆さんが技術的な文章を書くことにもっとリソースを投資すべきだと思います。

プロジェクトに対する疑問

1. Prismaはすでに広く使われているORMがある言語でも使えるのか？もし私がRubyでActiveRecordを使っていたり、ElixirでEctoを使っていたりしたら、乗り換えるインセンティブは何だろうか？
2. 聞きにくい質問だけれど、なんでPrismaって会社なんだろう？どうやってお金を払うのかわからないし、そのお金が何のためのものなのか分からない 🤷🏼 無料のものが好きだから貰うけれど、これはどこでどうなってるのか聞いてみたい。