など多くのことを考慮する必要があります。
最初に、Datomicに同梱されているDatalogの実装は熱心であり、ディスクに流出しないため、Datalogクエリの結果セットはメモリに収まる必要があります。
これは、各データログクエリでデータのわずかな部分のみを扱うことができるため、大きなデータ結果との互換性がないことを意味しません。たとえば、Datalogを使用してクエリの「論理」部分(返すエンティティ)とEntity APIまたはPull APIを使用して、クエリの 'content'部分を(遅延して)計算することができます各エンティティごとに)。 Entity IdがちょうどJava Long(8バイト)であることを考えると、これは2つの大きさのメモリフットプリントのうちの1つを節約できます。あなたが熱心に二次ブロブストアに結果全体を格納することによって、このアプローチを補完して、ページネーションのためにそれに対してポーリングすることができ
(defn export-customers
[db search-criteria]
(->>
;; logical part - Datalog-based, eager
(d/q '[:find [?customer ...] :in % $ ?search-criteria :where
(customer-matches-criteria ?search-criteria ?customer)]
(my-rules) db search-criteria)
;; content part - Entity API based, lazy
(map (fn [eid]
(let [customer (d/entity db eid)]
(select-keys customer
[:customer/id
:customer/email
:customer/firstName
:customer/lastName
:customer/subscription-time]))))
))
:エンティティのAPIを使用して実施例。
クエリロジックが複雑すぎない場合は、Datalogをまったく使用しないことも考えられます(たとえば、Datoms APIやIndex Range APIなどのローインデックスアクセスを使用するなど)。
最後に、Datomicが分析クエリのサービスに適していない可能性があることを考慮する必要があります。変更検出はDatomicでは簡単ではないので、解析クエリ(ElasticSearch、Google BigQuery、PostgreSQLなど)を計算するのに適したセカンダリストアに派生データをストリームするのはかなり簡単です
また、(datomic.api/REPLでエンティティを検査するために 'my-entityに触れる ')。 'into 'との違いは、' touch'がプレーンなClojureマップではなく、(人口になった)エンティティを返すことです。 –