logo标签列表

什么时候应该使用Datomic？

clojuredatomic
77

我对数据库服务Datomic很感兴趣，但我不确定它是否适合我工作的项目需求。在什么情况下选择Datomic是明智的，什么情况下应该避免使用？

1
如果您需要 1）在数据中进行时间旅行，即获取过去的事实，2）使用正确的数据架构，但仍希望使用“NoSQL”数据存储来存储事实。3）如果您想使用Datalog的能力处理数据。4）如果您不是创建普通的Web应用程序，如果是这种情况，则您现有的数据库技能更可行。 - Ankur
2
我强烈推荐Datomic发明者Rich Hickey的这个演讲http://www.infoq.com/presentations/datomic-functional-database，他在演讲中还展示了一些其关键特性的实际应用。 - Leon Grapenthin
4个回答
52

在我还没有在生产环境中使用Datomic的前提下，我想给你一个答案。

优点

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

缺点

  1. 它可能会慢一些，因为Datalog比等效的SQL要慢（假设可以编写等效的SQL语句）。
  2. 如果你要写很多数据，你可能需要担心单个事务处理器被压垮。对于大多数情况来说，这似乎不太可能发生，但这是一个需要考虑的问题（你可以进行一种分片操作，可能会节省自己的麻烦；但这不是用于存储股票行情数据的数据库）。
  3. 它有点难以启动和运行，而且价格昂贵，许可证和价格使得使用托管实例变得困难：你需要自己处理系统管理，而不能像在Heroku上使用Postgres或在MongoHQ上使用Mongo那样简单。

我确定我在每个方面都漏掉了一些内容，尽管我在缺点下列出了3个，但我认为优点在更多情况下超过了缺点，除非缺点阻止了它的使用。价格可能是阻止其在大多数小项目中使用的因素（你希望这些项目能超过1年的免费试用期）。

参考这篇简短文章，以了解更多关于Datomic的信息。

表达力（参见Datalog）和不可变性真是太棒了。在这方面，使用Dataomic工作非常有趣，而且你只需稍微使用一下就能感受到它的强大。
4
关于第二点，Isaac是正确的。至于第一点，Datalog和SQL是两种方法，性能取决于实现细节。因为Datomic查询在应用程序进程空间中运行，所以在某些情况下它们比任何可能的RPC查询更快。 - Stuart Dabbs Halloway
6
回复：#3：Datomic Pro Starter Edition是免费的。http://blog.datomic.com/2013/11/datomic-pro-starter-edition.html - Stuart Dabbs Halloway
4
关于 #3，它是免费的，但是 1) 没有提供全部内容，2) 只能获得 12 个月的更新。因此，你只能使用 Datomic 12 个月。这是尝试使用它的好方法，但如果将其用于生产应用程序，则需要考虑成本。 - Isaac
3
关于第三点，我认为与其他商业数据库相比声称它昂贵有些不公平。当被视为一款“企业级软件”时，它并不是那么昂贵，虽然它不是FOSS。这完全取决于使用情况和预算。对于业余爱好者项目，您可以使用几乎与Datomic Pro相同的功能的Datomic Pro Starter版本。 - romatthe
4
关于#3的快速更新 - Datomic Cloud（http://blog.datomic.com/2018/01/datomic-cloud.html）现已推出，适用于较小的项目，并减轻了一些系统管理员的负担。 - bmaddy
显示剩余2条评论
20
为了完善上面的答案，我想强调不可变性和记忆过去的能力并不是像审计这样的一些特殊情况所适用的“巫术功能”。与今天的“可变单元格”数据库相比，它具有几个深层次的优势。Stuart Halloway在这个视频中很好地展示了这一点：阻抗不匹配是我们的错。
在我个人看来，这种方法在概念上基本上更加明智。使用它已经有几个月了，我并没有看到Datomic有着疯狂的魔法般的复杂功能，而是一个更自然的范例，避免了其他更大的问题。
以下是我发现有价值的Datomic功能，其中大多数都是由不可变性启用的：
  1. 由于读取不是远程的，所以您不必像远足一样设计查询。特别是，您可以将关注点分成几个查询（例如查找作为我的查询输入的实体-回答关于这些实体的业务问题-获取用于呈现结果的相关数据）
  2. 模式非常灵活，而不会牺牲查询功能
  3. 在应用程序编程语言中集成查询非常方便
  4. 实体API带来了ORM的好处
  5. 查询语言是可编程的，并具有用于抽象和重用的原语（规则、谓词、数据库函数）
  6. 性能：编写者仅会妨碍其他编写者，而没有人会妨碍读者。此外，还有大量缓存。
  7. ... 是的，还有一些超能力，如穿越时空、推测性写入或分支现实。

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

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

所以，我的非常笼统和非正式的答案是，Datomic对于大多数非平凡的应用程序来说都是合适的，只要写入负载是合理的，你没有许可证问题并且运行在JVM上。

类比一下，你可以问自己相同的问题，将Git与其他不基于不变性的版本控制系统进行比较。

1
关于第三个缺点，Datomic与Fulcro RAD（https://github.com/fulcrologic/fulcro-rad）集成在一起。Fulcro RAD非常适合开发基于React的Web应用程序。Fulcro RAD的缺点是你需要先学习Fulcro，这虽然简单但并不容易。 - undefined
19
考虑Datomic是否适合您的应用程序时，一个重要的事情是考虑您将要存储和查询的数据形状-因为Datomic事实实际上与RDF三元组非常相似（+一级时间概念），它非常适合建模复杂关系（链接图形数据） - 这通常是传统SQL数据库中很繁琐的事情。我发现这个方面是我最吸引人和最重要的方面之一，它运行得非常好，即使这当然不是Datomic所独有的，因为在图形数据库的高质量选择中有许多其他选项，当我们谈论基于JVM的解决方案时，必须提到Neo4J。
关于Datomic架构，我认为它恰到好处地平衡了灵活性和稳定性。
4

仅供参考，其他答案已经提到：

可以说，Datomic是当前所有可选项中最好的可查询数据存储的概念框架，但在部分可扩展性和表现方面略显不足。

我之所以说只有部分可扩展性，是因为查询需要适合对等方RAM或失败。而在表现方面，顶级的SQL引擎可以通过复杂的执行计划优化查询以适应内存，这是我尚未在Datomic中看到的功能；Datomic事务和查询的解耦可能会抵消这个特征。

与许多NoSQL引擎不同，事务是一等公民，这使得它在这个关键方面与RDBMS系统相当。

对于读取数据比写入数据更频繁的应用程序，需要事务，查询始终适合内存或内存非常便宜，并且累积数据的总体大小不太大，如果可以承担商业产品的费用，那么它可能是一个胜利――对于那些愿意接受API中隐含的新颖概念框架的人来说。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接