我對數據庫服務Datomic很感興趣，但我不確定它是否適合我工作的項目的需求。 Datomic何時是一個很好的選擇，什麼時候應該避免？什麼時候應該使用Datomic？

2014-01-20 Mantas Vidutis

如果您需要1）在您的數據中進行時間旅行，即獲取過去的事實，2）使用適當的數據模式，但仍希望使用「NoSQL」數據存儲來存儲事實。 3）如果您想使用Datalog的強大功能處理您的數據。 4）你並沒有創建一個磨坊網絡應用程序，因爲在那種情況下你現有的數據庫技能更可行。 – Ankur

我可以高度推薦這個由Datomics發明者Rich Hickey發表的演講，他在演示中也演示了其中的一些主要特性構想。 –

由於我沒有在生產中使用過Datomic，我想我會給你一個答案。

優勢

數據記錄查詢功能強大，極具表現力（比非遞歸SQL更是如此）。
查詢可以用Clojure數據結構編寫，它不像許多SQL庫那樣是一個弱DSL，它允許您使用數據結構進行查詢。
它是不可變的，所以你可以獲得Clojure /其他語言中的不變性優勢，以及 a。這也允許你存儲，同時節省結構，在所有歷史事實數據庫，這是審計&非常有用的多

缺點

它可能會很慢，因爲數據記錄只是要比等效的SQL慢（假設可以寫入等效的SQL語句）。
如果你正在寫一個LOT，你可能需要擔心單個交易者不知所措。這似乎不太可能在大多數情況下，但是這是需要考慮的事情（儘管你可以做一些分片，並且可能救自己;但是這不是用於例如存儲股票價格數據的數據庫）。
啓動和運行起來有點棘手，而且代價昂貴，許可證和價格使得使用託管實例很困難：您需要自己處理系統管理，而不是使用類似於在Heroku或Postgres的蒙哥在MongoHQ

我敢肯定，我錯過了一些在每邊，儘管我有缺點下上市3，我認爲利大於弊他們更多的情況下，其中的缺點不排除它的使用。價格可能是阻止其在大多數小型項目中使用的價格（您預計會持續1年的免費試用期）。

參考這short post描述Datomic只是爲了更多的信息。

表達式（c.f. Datalog）和不變性很棒。在這方面與Dataomic一起工作非常有趣，並且只需稍微使用一下即可知道它的強大功能。

來源

2014-01-21 06:55:32 Isaac

艾薩克關於第二點是正確的。回覆：＃1：Datalog和SQL是方法，性能在實現細節。由於Datomic查詢在應用程序進程空間中運行，因此在某些情況下，它們可能比任何可能的RPC查詢更快。 –

回覆：＃3：Datomic Pro初學者版是免費的。 http://blog.datomic.com/2013/11/datomic-pro-starter-edition.html –

回覆＃3，它是免費的，但1）你沒有得到所有的東西，2）你只會得到更新爲期12個月。所以，這主要是12個月的Datomic。這是一個很好的嘗試方法，但如果將其用於生產應用程序，則需要考慮成本。 – Isaac

當考慮Datomic是否適合您的應用程序時，一件重要的事情是考慮您要存儲和查詢的數據的形狀 - 因爲Datomic事實實際上非常類似於RDF三元組（第一類時間概念）它非常適合建模複雜關係（鏈接圖數據） - 這對於傳統SQL數據庫通常很麻煩。我發現這方面對我來說是最吸引人和最重要的一點，它工作得非常好，即使這當然不是Datomic獨有的東西，因爲還有許多其他高質量的圖數據庫產品，必須提到Neo4J當我們談論基於JVM的解決方案時。
關於Datomic schema，我認爲這只是靈活性和穩定性之間的恰當平衡。

來源

2014-01-21 09:46:38 janherich

爲了完成上面的答案，我想強調，不變性和記憶過去的能力不是'巫術功能'，適合於審計等一些特殊情況。與'可變單元'數據庫（現在有99％的數據庫）相比，這種方法有幾個深遠的好處。 Stuart Halloway在此視頻中很好地演示了這一點：the Impedance Mismatch is our fault。

我個人認爲，這種方法在概念上基本上更加健全。經過幾個月的使用，我沒有看到Datomic具有瘋狂的魔法複雜能力，而是一種更自然的範式，沒有其他一些大問題。

這裏有Datomic的一些特點，我覺得有價值的，其中大部分是由不變性啓用：

因爲讀書並不遙遠，你沒有來設計你的查詢，如通過線路的探險。特別是，您可以將關注點分解爲多個查詢（例如，查找作爲我的查詢輸入的實體 - 回答關於這些實體的一些業務問題 - 獲取關聯數據以呈現結果）
模式爲很靈活，在不犧牲查詢功率
它的舒適有集成在您的應用程序編程語言的查詢
實體API帶給你的ORM
查詢語言是可編程的好的部分，並具有原語的抽象和重用（規則，謂詞，數據庫函數）
表現：作家只阻礙其他作家，沒有人妨礙讀者。另外，還有很多緩存。
...是的，一些超級大國喜歡旅行到過去，投機寫作或分支的現實。

關於何時不使用Datomic，這裏是當前制約和限制我看到：

你必須對JVM（還有一個REST API，但你失去了最國際海事組織的好處）
不適合寫入的規模，也沒有龐大的數據量
不會特別融入的框架，例如，你將目前無法找到這從Datomic模式產生CRUD REST端點庫
這是一個商業數據庫
由於讀取發生在應用程序進程（'Peer'）中，所以您必須確保Peer具有足夠的內存來存放需要在查詢中遍歷的所有數據。

所以我非常模糊的和非正式的答案將是Datomic是一個不錯的選擇可寫入負載是最合理不平凡的應用程序，你不必與許可證問題，是在JVM上 。

作爲一個比喻，與其他不基於不變性的版本控制系統相比，對於Git，您可以問自己同樣的問題。

來源

2016-02-02 14:57:25

只是試探性加比其他答案：

它是公平地說datomic提出了其他所有當前的選擇了可查詢的數據存儲更好的概念框架，同時是部分可擴展性和不是特別高性能。

我只說部分可擴展，因爲查詢需要適合對等RAM或失敗。而不是異常性能，因爲頂尖的SQL引擎可以通過複雜的執行計劃優化查詢以適應內存，這是我還沒有看到的作爲datomic功能提及的內容;交易和查詢的Datomic的解耦可能在總體上抵消了這個特性。

雖然與許多NoSQL引擎不同，但事務處理是一流的公民，它在這個關鍵方面與RDBMS系統相提並論。

對於數據讀取不止是寫入的應用程序，需要事務處理，查詢總是適合內存或內存非常便宜，並且累積數據的總體大小不是too large，這可能是一個贏只能爲那些願意接受API中隱含的新穎概念框架的人提供產品。

來源

2017-07-21 21:52:32 matanster

什麼時候應該使用Datomic？

回答

優勢

缺點

相關問題