database - いつ Datomic を使用する必要がありますか?

Question

私はデータベース サービス Datomic に興味を持っていますが、それが私が取り組んでいるプロジェクトのニーズに合っているかどうかはわかりません。Datomic が適切な選択となるのはいつで、どのような場合に避けるべきですか?

Answer 1

本番環境で Datomic を使用したことがないという条件付きで、お答えしたいと思います。

利点

1. データログ クエリは (非再帰的 SQL よりも) 強力で、非常に表現力があります。
2. クエリは Clojure データ構造で記述でき、データ構造でクエリできる多くの SQL ライブラリのような弱い DSL ではありません。
3. これは不変であるため、Clojure やその他の言語でも不変性がもたらす利点を享受できます。これにより、構造を保存しながら、過去のすべての事実をデータベースに保存することもできます。これは、監査などに非常に役立ちます。

短所

1. Datalog は同等の SQL よりも遅くなるだけなので、遅くなる可能性があります (同等の SQL ステートメントを記述できると仮定して)。
2. LOT を書いている場合、単一のトランザクションが圧倒されることを心配する必要があるかもしれません。ほとんどの場合、これはありそうにないように思えますが、考えておくべきことです (ただし、一種のシャードを実行して、おそらく自分自身を救うことができます。ただし、これは、たとえば株価データを格納するための DB ではありません)。
3. 起動して実行するのは少し難しいです。高価です。また、ライセンスと価格がホストされたインスタンスを使用するのを難しくしています。Heroku で Postgres のようなものを使用する代わりに、システム管理を自分で処理する必要があります。または MongoHQ の Mongo

私はそれぞれの側でいくつか欠けていると確信しており、欠点の下に3つ挙げていますが、欠点がその使用を妨げないより多くの状況では、利点がそれらを上回ると思います. 価格はおそらく、ほとんどの小規模なプロジェクト (1 年間の無料試用期間よりも長持ちすると予想されるプロジェクト) での使用を妨げるものです。

参照。詳細については、Datomic について説明したこの短い投稿を参照してください。

表現力 (Datalog を参照) と不変性は素晴らしいものです。その点で Dataomic を使用するのは非常に楽しく、少し使っただけでその強力さがわかります。

Answer 2

上記の回答を完成させるために、不変性と過去を思い出す能力は、監査のようないくつかの特殊なケースに適した「魔法のような機能」ではないことを強調したいと思います。これは、「ミュータブル セル」データベース (今日のデータベースの 99% を占める) と比較して、いくつかの大きなメリットがあるアプローチです。Stuart Halloway は、このビデオでこれをうまく示しています。インピーダンスの不一致は私たちのせいです。

私の個人的な意見では、このアプローチは基本的に概念的により正気です。数ヶ月使ってみたが、Datomic がクレイジーで洗練された魔法の力を持っているとは思わない。

以下は、私が貴重だと思う Datomic の機能の一部です。そのほとんどは、不変性によって有効になっています。

1. 読み取りはリモートではないため、回線を介した遠征のようにクエリを設計する必要はありません。特に、懸念事項をいくつかのクエリに分けることができます (たとえば、クエリへの入力であるエンティティを見つける - これらのエンティティに関するビジネス上の質問に答える - 結果を表示するために関連データを取得する)
2. クエリ能力を犠牲にすることなく、スキーマは非常に柔軟です
3. クエリをアプリケーション プログラミング言語に統合すると便利です
4. Entity API は ORM の優れた部分をもたらします
5. クエリ言語はプログラム可能であり、抽象化と再利用のためのプリミティブ (ルール、述語、データベース関数) を備えています。
6. パフォーマンス: ライターは他のライターだけを妨害し、誰もリーダーを妨害しません。さらに、多くのキャッシング。
7. ...そして、はい、過去への旅行、投機的な書き込み、現実の分岐などのいくつかの超大国.

Datomic を使用しない場合について、現在の制約と制限を以下に示します。

1. JVM を使用する必要があります (REST API もありますが、IMO の利点のほとんどが失われます)。
2. 書き込みスケールや巨大なデータ ボリュームには適していません
3. フレームワークに特に統合されることはありません。たとえば、現在、Datomic スキーマから CRUD REST エンドポイントを生成するライブラリは見つかりません。
4. 商用データベースです
5. 読み取りはアプリケーション プロセス (「ピア」) で行われるため、クエリでトラバースする必要があるすべてのデータを保持するのに十分なメモリがピアにあることを確認する必要があります。

したがって、私の非常に漠然とした非公式な答えは、Datomic は、書き込み負荷が妥当であり、ライセンスに問題がなく、JVM にいるほとんどの重要なアプリケーションに適しているということです。

類推として、不変性に基づいていない他のバージョン管理システムと比較して、Git について同じ質問を自問することができます。

Answer 3

Datomic がアプリケーションに適しているかどうかを検討する際に重要なことの 1 つは、保存してクエリを実行するデータの形状を考慮することです。Datomic のファクトは、実際には RDF トリプル (+ ファースト クラス時間の概念) と非常によく似ているためです。複雑な関係 (リンクされたグラフ データ) をモデル化するのに非常に適しています。これは、従来の SQL データベースではしばしば扱いにくいものです。この側面は私にとって最も魅力的で重要なものの 1 つであることがわかりました。これはもちろん Datomic だけのものではありませんが、グラフ データベースには他にも多くの高品質の製品があるため、Neo4J に言及する必要があります。 JVM ベースのソリューションについて話しているとき。
Datomic スキーマに関しては、柔軟性と安定性のちょうどいいバランスだと思います。

Answer 4

他の回答を暫定的に追加するだけです：

datomic は、部分的にスケーラブルであり、例外的にパフォーマンスが優れているわけではありませんが、他のすべての現在のオプションのクエリ可能なデータ ストアのためのより優れた概念的フレームワークを提示すると言っても過言ではありません。

クエリはピア RAM に収まるか、失敗する必要があるため、部分的にのみスケーラブルだと言います。一流の SQL エンジンは、洗練された実行計画を通じてメモリに収まるようにクエリを最適化できるため、並外れたパフォーマンスではありません。Datomic のトランザクションとクエリの分離は、全体的にこの機能を相殺する可能性があります。

ただし、多くの NoSQL エンジンとは異なり、トランザクションは第一級の市民であり、その重要な点で RDBMS システムと同等です。

データが書き込まれるよりも読み取られることが多く、トランザクションが必要であり、クエリが常にメモリに収まるか、メモリが非常に安価で、蓄積されたデータの全体的なサイズが大きすぎないアプリケーションの場合、商用専用の製品が有利になる可能性があります。 API に含まれる新しい概念フレームワークを喜んで受け入れたい人向けです。