この記事は、著者の許可を得て配信しています。 https://blog.pragmaticengineer.com/the-developer-culture-test/
私はデータベースの大ファンで、いわゆる「NoSQL」データベースに関する本を書いたり、影響力の高い分散型データベースRiakに携わったりと、技術職として最も実りある年のいくつかを過ごし、昨年は楽しみのためにPurpleというデータベースを構築したりもしました。
当然のことながら、私はTwitterやReddit、HackerNewsなどをさらっと読む場合、データベースやDB関連ツールの新しくて刺激的な開発に常に気にして見ています。今回の記事では、私が興味をそそられる最近登場した3つのデータベース技術についてお話したいと思います。
後半では次の３つについてお話したいと思っています。
パート3では、最後にいくつかの考えを述べて締めくくりたいと思います。注: 私はもっぱらコアな技術に焦点を当て、エンタープライズ機能（該当する場合は）のようなものはほとんど無視しています。
私の選択基準は純粋に主観的なものです。ここにないもので、私がチェックすべきだと思うものがあれば、私にツイートして教えてください！私のハンドルネームは @lucperkins です。
TileDBは多次元配列を中心に構築されたDBで、密な配列や疎な配列、データフレームなど、既存のRDBMSシステムにはあまり適していないタイプのデータを簡単に扱うことができます。TileDBは、ゲノミクスや地理空間データなどのユースケースに特化しています。
私は、特定のデータタイプや問題に特化した、このような優れた技術の「専門的な」DBのファンです。従来のRDBMSの素晴らしいところは、ユースケースの非常に広い配列をカバーするのに十分な汎用性を持っていることですが、時には（a）「キッチンシンク」システムの能力を超えた、（b）ビジネスの中核をなす「ラストワンマイル」のエッジケースがあることです。
データベースのユースケースがこれまで以上に専門化し、新しい問題領域が出現するにつれて、このようなシステムがもっと登場することを期待しています。もちろん、保守派のRDBMSはどこにも行かないだろうが、TileDBやその他の企業が限界に挑戦しているのを見るのは励みになります。私が本当に期待しているのは、「ハッキング可能」で、ユースケースに特化したデータ型のためのプラグインインタフェースを提供する、断固として非モノリシックなDBの出現ですが、これについては後ほど話すことにしましょう。
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で再現されることになるでしょう。
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を使うことで、スタックのその部分をあっさりと切り取ることができます。
Prismaはデータベースではなく、可能な限りデータベースを抽象化しようとするツールのセットです。現在、DB側ではPostgreSQL、MySQL、SQLiteと互換性があり、言語側ではJavaScriptとTypeScriptと互換性があります（さらに多くのDBと言語に対応していく予定です）。「モダンアプリケーションのためのデータレイヤー」と自画自賛していますが、全くその通りだと思います。
Prismaを使用するための方法です。
全体的には、Prismaのようなツールの使用に対して、躊躇している人がいるということを理解しています。開発者の大部分は、データベースの抽象化を望んでいません。彼らは賢くて便利なDSLやGUIを望んでいません。彼らはプレーンなSQLを書きたいと思っていて、すべてのDBインタラクションコードを自分の手で書きたいと思っています。その程度のコントロールを維持したいという気持ちは完全に理解できますが、それでも20～30分の時間を取ってPrismaを試してみることをお勧めします。Prismaは、あまりにも手間のかかるツールと生SQLの間の中間くらいで、とてもいい仕事をしてくれるツールだと思います。
PrismaスキーマDSLは、アプリケーションに必要なデータタイプだけでなく、どのコードジェネレータを使用するかを設定したり、接続先の DB の接続情報を設定する方法です。
さらに、列挙型（ enum）、@id、@relation、@defaultのような便利なアノテーションを提供します。ActiveRecordやEctoのDB移行DSLと、Protocol BuffersやThriftで使われているようなIDLの両方を彷彿とさせます。
PrismaスキーマSDLやそのようなものが、言語ニュートラルな標準（言語固有のライブラリで使用可能）として導入されるのをぜひ見てみたいものです。現状では、すべてのプログラミング言語が土台からやり直しています。アプリケーションとDBの関係を設定する型を言語にとらわれない方法で設定することはとてもメリットのあることだと思います。
それに関連したことですが、Prismaの非常に美しいドキュメントへの称賛の言葉があるそうです。もしあなたのドキュメントがブログ記事の「私が最も好きなもの」のセクションに属していないのであれば、皆さんが技術的な文章を書くことにもっとリソースを投資すべきだと思います。
注目のコメント
2ヶ月
5ヶ月
5ヶ月