Datomicはいつ使用する必要がありますか？
データベースサービスDatomicに興味がありますが、私が取り組んでいるプロジェクトのニーズに合うかどうかはわかりません。 Datomicが適切な選択となるのはいつですか？
私がプロダクションでDatomicを使用していないという条件で、答えをあげると思いました。
長所
- データログクエリは強力で（非再帰SQLよりも）、非常に表現力があります。
- クエリはClojureデータ構造で記述できますが、データ構造でクエリを実行できる多くのSQLライブラリのような弱いDSLではありません。
- 不変であるため、Clojure /他の言語でも不変がもたらす利点が得られます。これにより、構造を保存しながら、データベースに過去のすべての事実を保存することもできます。これは、監査などに非常に役立ちます。
欠点
- Datalogは同等のSQLよりも低速になるため、低速になる可能性があります（同等のSQLステートメントを記述できる場合）。
- LOTを作成している場合、単一のトランザクターが圧倒されるのを心配する必要があるかもしれません。これはほとんどの場合、起こりそうにないように思えますが、考える必要があります（ただし、一種の破片を行うことができ、おそらく自分自身を救うことができます;しかし、これは、例えば株式ティックデータを保存するためのDBではありません）。
- 立ち上げて実行するのは少しトリッキーであり、高価であり、ライセンスと価格のためにホストされたインスタンスを使用するのが難しくなります。またはMongoHQのMongo
私はそれぞれの側面にいくつか欠けていると確信しており、不利益の下に3つリストされていますが、不利益がその使用を排除しないより多くの状況で利点がそれらを上回ると思います。おそらく価格は、ほとんどの小規模プロジェクト（1年間の無料試用期間よりも長く続くことを期待しているプロジェクト）での使用を妨げるものです。
Cf.これ 短い投稿 いくつかのより多くの情報のために単純にDatomicを記述する。
表現力（c.f.データログ）と不変性は素晴らしいです。その点でDataomicを操作するのはSOとても楽しいです。少しだけ使用するだけで強力であることがわかります。
Datomicがアプリケーションに適しているかどうかを検討する際の重要なことの1つは、保存および照会するデータの形状について考えることです。Datomicファクトは実際にはRDF triples（ +ファーストクラスの概念）複雑な関係（リンクグラフデータ）のモデリングに非常に適しています-これは、従来のSQLデータベースでは面倒なことが多いものです。この側面は、私にとって最も魅力的で重要なものの1つでした。もちろん、これはもちろんDatomicだけのものではありませんが、グラフデータベースには他にも多くの高品質な製品がありますが、JVMベースのソリューションについて話すときはNeo4Jに言及する必要があります。
Datomicスキーマについては、柔軟性と安定性のちょうど良いバランスだと思います。
上記の答えを完成させるために、不変性と過去を記憶する能力は、監査のようないくつかの特別な場合に適した「奇妙な機能」ではないことを強調したいと思います。これは、「可変セル」データベース（今日のデータベースの99％）と比較して、いくつかの深い利点があるアプローチです。スチュアート・ハロウェイは、このビデオでこれをうまく示しています： インピーダンスの不一致は私たちのせいです 。
私の意見では、このアプローチは基本的に概念上より正気です。数ヶ月使用したので、Datomicがクレイジーで魔法のような洗練された力を持っているとは思えません。
ここに私が価値があると思うDatomicの機能がいくつかありますが、そのほとんどは不変性によって可能になっています。
- 読み取りはリモートではないため、ネットワークを介した遠征のようにクエリを設計する必要はありません。特に、懸念事項をいくつかのクエリに分けることができます（たとえば、クエリへの入力であるエンティティを見つける-これらのエンティティに関するビジネス上の質問に答える-結果を提示するために関連データを取得する）
- スキーマはvery柔軟で、クエリの能力を犠牲にしません
- クエリをアプリケーションプログラミング言語に統合しても問題ありません
- entity APIはORMの優れた部分を提供します
- クエリ言語はプログラム可能で、抽象化と再利用のためのプリミティブ（ルール、述語、データベース関数）を備えています
- パフォーマンス：作家は他の作家だけを妨げ、誰も読者を妨げません。さらに、多くのキャッシング。
- ...そしてはい、過去への旅行、投機的な書き物、または分岐する現実のようないくつかの超大国。
notがDatomicを使用するタイミングについて、現在の制約と制限を以下に示します。
- jVMを使用する必要があります（REST APIもありますが、IMOの利点のほとんどを失います）
- 書き込みスケールにも大量のデータ量にも適さない
- フレームワークに特に統合されません。たとえば、現在、DatomicスキーマからCRUD RESTエンドポイントを生成するライブラリは見つかりません。
- 商用データベースです
- 読み取りはアプリケーションプロセス（「ピア」）で行われるため、クエリでトラバースする必要があるすべてのデータを保持するのに十分なメモリがピアにあることを確認する必要があります。
私の非常に曖昧で非公式な答えは、ロードは合理的であり、ライセンスとJVMに問題がないほとんどの非自明なアプリケーションに適していますです。
類推として、不変性に基づいていない他のバージョン管理システムと比較して、Gitについて同じ質問を自問することができます。
暫定的に他の答えを追加するために：
Datomicは、他のすべての現在のオプションのクエリ可能なデータストアのより優れた概念的フレームワークを提供する一方で、部分的にスケーラブルであり、非常に優れたパフォーマンスを発揮しないと言ってもよいでしょう。
部分的にスケーラブルです。なぜなら、クエリはピアに収まる必要があるためですRAMまたは失敗します。そして、例外的にパフォーマンスは最高ですSQLエンジンは、洗練された実行計画を通じてメモリに収まるようにクエリを最適化できます。これは、datomicの機能としてはまだ言及していませんが、トランザクションとクエリのDatomicの分離により、この機能が全体的に相殺される可能性があります。
ただし、多くのNoSQLエンジンとは異なり、トランザクションは第一級の市民であり、重要な点でRDBMSシステムと同等です。
データが書き込まれるよりも多く読み込まれ、トランザクションが必要であり、クエリが常にメモリに収まるか、メモリが非常に安価であり、蓄積されたデータの全体サイズが 大きすぎる ではないアプリケーションの場合、 APIで暗示されている新しい概念フレームワークを採用したい人のために、商用専用の製品を提供できる場所で勝ちます。