什么时候应该使用Datomic？
我对数据库服务Datomic很感兴趣，但我不确定它是否适合我工作的项目的需求。 Datomic什么时候是一个好select，何时应该避免？
由于我没有在生产中使用Datomic，我想我会给你一个答案。
优点
- Datalog查询function强大（比非recursionSQL更强大），非常有表现力。
- 查询可以使用Clojure数据结构来编写，而且它不像许多SQL库那样是一个弱的DSL，允许您使用数据结构进行查询。
- 它是不可改变的，所以你在Clojure /其他语言中获得了不变性的优势。 这还允许您在保存结构时存储数据库中的所有过去事实 – 这对于审计和更多操作非常有用
缺点
- 它可能会很慢，因为Datalog只会比等效的SQL慢（假设可以写入相同的SQL语句）。
- 如果你正在写很多，你可能需要担心单个交易者不知所措。 这在大多数情况下似乎不太可能，但是这是需要考虑的事情（尽pipe你可以做一些分解，也许可以节省自己;但是这不是用于存储股票价格数据的数据库）。
- 启动和运行起来有点棘手，而且价格昂贵，许可证和价格使得使用托pipe实例很困难：您需要自己处理系统pipe理，而不是像Heroku上的Postgres那样使用类似的东西或MongoHQ的Mongo
我相信我在每一方面都缺less一些，尽pipe我列举了三个不利因素，但我认为，在更多的情况下，这些优势超过了它们，而这些缺点并不排除它的使用。 价格可能是阻止它在大多数小项目中使用的价格（你预计将会持续1年的免费试用期）。
参看 这个简短的post只是为了更多的信息来描述Datomic。
performance力（比较Datalog）和不变性是真棒。 在这方面与Dataomic合作非常有趣，只要使用一下就可以知道它的强大function。
在考虑Datomic是否适合您的应用时，一个重要的事情是考虑您将要存储和查询的数据的形状 – 因为Datomic事实实际上非常类似于RDF三元组（+一级时间概念）非常适合build模复杂的关系（链接图数据） – 传统SQL数据库通常很麻烦。 我发现这个方面对我来说是最吸引人和最重要的一个方面，它工作得非常好，即使这当然不是Datomic专有的东西，因为还有许多其他高质量的图数据库服务，所以必须提到Neo4J当我们谈论基于JVM的解决scheme时。
关于Datomic模式，我认为这只是灵活性和稳定性之间的恰当平衡。
为了完成上面的答案，我想强调，不变性和记忆过去的能力不是适合于审计这样的一些特殊情况的“魔法特征”。 与“可变单元”数据库相比（这是目前99％的数据库），这种方法有几个深远的好处。 Stuart Halloway在这个video中很好地展示了这一点： 阻抗不匹配是我们的错 。
我个人认为，这个方法在概念上更为理智。 经过几个月的使用，我没有看到Datomic拥有疯狂的魔法复杂的力量，而是一个更自然的范式，没有其他一些大问题。
以下是Datomic的一些function，我发现它们非常有价值，其中大部分都是通过不变性实现的：
- 因为阅读不是遥远的，所以你不必像电线上的探险那样devise你的查询。 特别是，您可以将关注点分成几个查询（例如，查找作为查询input的实体 – 回答关于这些实体的一些业务问题 – 获取关联的数据以呈现结果）
- 模式非常灵活，不会牺牲查询能力
- 把你的查询集成到你的应用程序编程语言中是很合适的
- Entity API为您带来了ORM的优秀部分
- 查询语言是可编程的，并且具有用于抽象和重用的原语（规则，谓词，数据库函数）
- performance：作家只有阻碍其他作家，没有人妨碍读者。 另外，大量的caching。
- …是的，有几个超级大国像过去的旅行，投机性的写作或分支的现实。
关于何时不使用Datomic，下面是我看到的当前的限制和限制：
- 你必须在JVM上（也有一个REST API，但是你失去了IMO的大部分好处）
- 不适合写规模，也不适合庞大的数据量
- 将不会特别集成到框架中，例如，您目前不会find从Datomic模式生成CRUD REST端点的库
- 这是一个商业数据库
- 由于读取发生在应用程序过程（“对等”）中，因此必须确保对等体有足够的内存来存放查询中需要遍历的所有数据。
所以我非常模糊和非正式的答案是， Datomic适合于大多数不重要的应用程序，这些应用程序的写入负载是合理的，并且您没有许可证问题，并且不在JVM上 。
作为一个类比，你可以问自己与Git相同的问题，而不是基于不变性的其他版本控制系统。
只是暂时添加其他答案：
可以说，datomic为所有其他当前选项的可查询数据存储提供了更好的概念框架，同时具有部分可扩展性，而且不是特别的高性能。
我只说部分可扩展的，因为查询需要适合在同行RAM或失败。 由于顶尖的SQL引擎可以通过复杂的执行计划来优化查询以适应内存，而这些我还没有在datomic中提到过; 交易和查询的Datomic的解耦可能在总体上抵消了这个特性。
与许多NoSQL引擎不同的是，交易是一stream的公民，在这方面与RDBMS系统相提并论。
对于数据读取不止是写入的应用程序，需要事务处理，查询总是适合内存或内存非常便宜，并且累积数据的整体大小不是太大 ，这可能是一个赢得商业产品可以提供给那些愿意接受API中隐含的新颖概念框架的人。
