我对数据库服务Datomic感兴趣，但是我不确定它是否适合我从事的项目的需求。什么时候Datomic是一个好的选择，什么时候应该避免？

鉴于我没有在生产中使用Datomic的附带条件，想想我会给你一个答案。

优点

1. 数据记录查询功能强大（比非递归SQL更为强大）且表达能力强。
2. 可以使用Clojure数据结构编写查询，并且它不是像许多SQL库一样允许您使用数据结构进行查询的弱DSL。
3. 它是不可变的，因此您可以获得不可变性在Clojure /其他语言中的优势。这还允许您在保存结构的同时将过去的所有事实存储在数据库中-这对于审核非常有用，而且功能更多

缺点

1. 它可能很慢，因为Datalog只会比等效的SQL慢（假设可以编写等效的SQL语句）。
2. 如果您正在编写很多，则可能需要担心单个事务处理程序不堪重负。在大多数情况下，这似乎不太可能，但这是需要考虑的事情（不过，您可以进行某种分片操作，并且可以保存自己；但这不是例如用于存储股票报价数据的数据库）。
3. 要启动并运行它有点棘手，而且价格昂贵，而且许可和价格使其难以使用托管实例：您需要自己进行系统管理，而不是在Heroku上使用诸如Postgres之类的东西或MongoHQ的Mongo

我确定我双方都缺席了一些，尽管我在劣势项下列出了3个，但我认为在劣势不排除使用劣势的更多情况下，优势多于优势。价格可能是阻止其在大多数小型项目中使用的价格（您希望它能超过1年的免费试用期）。

cf. 这篇简短的文章仅介绍Datomic，以获取更多信息。

表现力（参见Datalog）和不变性很棒。在这方面，与Dataomic一起工作真是太有趣了，只要稍加使用，就可以证明它的功能强大。

考虑Datomic是否适合您的应用程序时，一件重要的事情是考虑要存储和查询的数据的形状-因为Datomic事实实际上与RDF三元组（+一流时间概念）非常相似，因此它很适合自己非常适合对复杂的关系（链接的图数据）进行建模-传统SQL数据库通常很麻烦。我发现这对我来说是最吸引人且最重要的方面，它确实运行良好，即使这当然不是Datomic独有的，因为还有许多其他高质量的图形数据库产品，其中一个必须提及Neo4J当我们谈论基于JVM的解决方案时。
关于Datomic模式，我认为这是灵活性和稳定性之间的正确平衡。

为了完成上述回答，我想强调的是，不变性和记住过去的能力并不是适合于审计等特殊情况的“杂项功能”。与“可变单元”数据库（目前占数据库的99％）相比，这种方法具有许多深远的好处。斯图尔特·哈洛韦（Stuart Halloway）在视频中很好地演示了这一点：阻抗不匹配是我们的错。

我个人认为，从概念上讲，这种方法从根本上更加合理。使用了几个月后，我看不到Datomic具有疯狂的神奇复杂能力，而是一种更自然的范例，没有其他人遇到的一些大问题。

这是我发现有价值的Datomic的一些功能，其中大多数是通过不变性实现的：

1. 因为阅读不是遥不可及的，所以您不必像在线探险一样设计查询。特别是，您可以将关注点分为几个查询（例如，找到作为我查询输入的实体-回答有关这些实体的一些业务问题-获取相关数据以显示结果）
2. 该模式非常灵活，并且不会牺牲查询能力
3. 将查询与您的应用程序编程语言集成在一起很舒服
4. 实体API为您带来ORM的优势
5. 查询语言是可编程的，并且具有用于抽象和重用的原语（规则，谓词，数据库函数）
6. 表现：作家只阻碍其他作家，没有人阻碍读者。另外，还有很多缓存。
7. ...是的，有一些超级大国，例如过去，投机性写作或分支现实。

关于何时不使用Datomic，以下是我目前看到的限制和限制：

1. 您必须使用JVM（也有REST API，但失去了IMO的大部分好处）
2. 不适合写入规模，也不适合海量数据
3. 不会特别集成到框架中，例如，您当前找不到可从Datomic模式生成CRUD REST端点的库
4. 这是一个商业数据库
5. 由于读取是在应用程序过程中发生的（“对等体”），因此您必须确保对等体具有足够的内存来容纳它在查询中需要遍历的所有数据。

因此，我非常模糊和非正式的回答是，Datomic非常适合大多数非平凡的应用程序，这些应用程序的写负载是合理的，并且您的许可证和使用JVM都没有问题。

打个比方，与其他不基于不变性的版本控制系统相比，您可以对Git询问相同的问题。

暂时添加其他答案：

可以说datomic为可查询的数据存储提供了一个更好的概念框架，其中可存储所有其他当前选项，同时具有部分可伸缩性和出色的性能。

我说的只是部分可伸缩的，因为查询需要适合对等RAM或失败。而且性能不是特别出色，因为一流的SQL引擎可以通过复杂的执行计划优化查询以使其适合内存，这在datomic中还没有提到。Datomic对事务和查询的解耦可能在总体上抵消了此功能。

但是，与许多NoSQL引擎不同，事务是一等公民，因此在关键方面与RDBMS系统相当。

对于读取数据多于写入数据，需要事务处理，查询总是适合内存或内存非常便宜，并且累积数据的整体大小不太大的应用程序，在仅商业化产品的情况下可能是一个胜利可以提供给那些愿意接受API暗示的新颖概念框架的人。