我什么时候应该使用Datomic？

Question

我对数据库服务Datomic很感兴趣，但我不确定它是否符合我工作的项目的需要。 Datomic什么时候是一个不错的选择，什么时候应该避免？

Answer 1

条件是我没有在制作中使用过Datomic，我想我会给你一个答案。

优点

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

缺点

1. 它可能很慢，因为Datalog会比等效的SQL慢（假设可以编写等效的SQL语句）。
2. 如果你正在写很多东西，你可能需要担心单个交易者不堪重负。在大多数情况下这似乎不太可能，但是需要考虑一下（你可以做一些碎片，但可能会保存自己;但这不是用于存储股票价格数据的数据库）。
3. 启动和运行起来有点棘手，而且价格昂贵，许可和价格使得使用托管实例变得困难：你需要自己处理系统管理而不是使用像MongoHQ的Heroku或Mongo的Postgres

我确信我在每一方都缺少一些，虽然我有3个列在缺点之下，但我认为在更多情况下优势超过它们，其中缺点不排除其使用。价格可能是阻止其在大多数小型项目中使用的价格（您预计将超过1年的免费试用期）。

比照。这个short post描述了Datomic只是为了获得更多信息。

表现力（c.f。Datalog）和不变性非常棒。在这方面与Dataomic合作非常有趣，你可以通过稍微使用它来说明它的强大功能。

Answer 2

在考虑Datomic是否适合您的应用程序时，最重要的一点是考虑要存储和查询的数据的形状 - 因为Datomic事实实际上非常类似于RDF三元组（+一流时间概念）它非常适合建模复杂的关系（链接的图形数据） - 这对传统的SQL数据库来说往往很麻烦。 我发现这方面对我来说是最吸引人和最重要的方面之一，它工作得非常好，即使这当然不是Datomic独有的东西，因为有许多其他高质量的图形数据库产品，必须提到Neo4J当我们谈论基于JVM的解决方案时 关于Datomic架构，我认为这是灵活性和稳定性之间的恰当平衡。

Answer 3

为了完成上述答案，我想强调一点，不可变性和记住过去的能力不是适合审计等特殊情况的“魔法特征”。与“可变细胞”数据库（目前占99％的数据库）相比，这种方法具有几个深远的优势。 Stuart Halloway在这段视频中很好地演示了这一点：the Impedance Mismatch is our fault。

在我个人看来，这种方法在概念上基本上更加明智。使用它几个月之后，我没有看到Datomic拥有疯狂的神奇复杂的力量，而不是一个更自然的范例，没有其他人遇到的一些大问题。

以下是Datomic的一些我觉得有价值的功能，其中大部分都是通过不变性来实现的：

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

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

1. 你必须在JVM上（还有一个REST API，但你失去了IMO的大部分好处）
2. 不适合写入规模，也不适合大量数据
3. 不会特别集成到框架中，例如，您目前不会找到从Datomic架构生成CRUD REST端点的库
4. 这是一个商业数据库
5. 由于读取发生在应用程序进程（'Peer'）中，您必须确保Peer有足够的内存来保存查询中需要遍历的所有数据。

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

作为类比，与其他不基于不变性的版本控制系统相比，Git可以问自己同样的问题。

Answer 4

暂时添加其他答案：

可能公平地说，datomic为所有其他当前选项的可查询数据存储提供了更好的概念框架，同时具有部分可伸缩性并且不是特别高效的。

我说只有部分可扩展，因为查询需要适合对等RAM或失败。并非特别高性能，因为顶级SQL引擎可以通过复杂的执行计划优化查询以适应内存，这是我在数据组中未提及的一项功能。交易和查询的Datomic解耦可能会在整体偏移此功能。

与许多NoSQL引擎不同，交易是一流的公民，这使得它在关键方面与RDBMS系统相提并论。

对于读取数据而不是编写数据的应用程序，需要进行事务处理，查询总是适合内存或内存非常便宜，并且累积数据的总体大小不是too large，它可能是一个可以提供商业产品的胜利 - 对于那些愿意接受API隐含的新颖概念框架的人来说。