javascript - nomsdb 和 gundb 有什么区别

Question

据我了解，这两个数据库似乎遵循几乎相同的原则。两者都支持离线场景，分散并具有灵活的数据模型。我看到的唯一真正的区别是，noms 实现了 git 的一些想法，并且允许自定义合并操作，而 gun 实现自动冲突解决。

这是唯一的区别还是我错过了什么？

Answer 1

主要区别在于一种味道很好，另一种不应该放在嘴里。;) 开个玩笑：

(1) noms 总是存储整个修订历史，就像提到的 git 一样。使用枪时，这是可选的。

(2) 他们都有“开箱即用”的“正常工作”数据同步/合并，都可以支持 DAG 和 Merkle 树。这是枪的做法： http: //gun.js.org/distributed/matters.html。

(3) 对于 ops 问题，gun 还支持可以构建在自动合并算法之上的自定义合并算法。

(4) 我知道 gun 可以支持无向或非循环图，也就是具有循环引用和双向关系的图。我不确定 noms 是否可以，或者我确定您可以，但如果这可行，是否是一流/简单的功能。

(5) noms design doc 说它是“有效的 CA”（关于 CAP 定理），这表明它不应该与离线优先的对等点一起使用。但是我很确定他们的意思是 noms 是 AP（离线优先），并且因为数据永远不会变异/更改（只能像 Datomic 一样被附加）它具有类似 C 的属性（但是你如何访问数据作为开发人员不一定是 C)。这是枪的看法：https ://github.com/amark/gun/wiki/CAP-Theorem

总之，从我有限的概述来看，它们似乎是相似的，两者都可以做对方可以做的事情，但可能更容易：

(A) 如果你正在构建自己的区块链、审计日志或做会计/银行业务，那么命名会更容易。

(B) 如果您正在构建游戏、社交网络、移动应用程序或物联网网络，那么枪支会更容易。

Answer 2

NOMS 是所谓的“内容可寻址”数据库（如 Camlistore），将结构化数据保存为 Merkle DAG。它提供概率 B 树作为索引机制。由于这种结构，许多数据同步/合并问题“开箱即用”。我不完全确定 Gun 的内部结构，但我确实知道它采用了一套合并算法，例如 Operational Transform 进行协调。

GunDB 是用 Javascript 实现的。虽然 NOMS 有一个 JS 实现（并且 Attic Labs 雇佣了具有非常严肃的 JS 背景的工程师），但实现问题导致他们放弃了客户端 JS 支持。看到我在https://github.com/attic-labs/noms/issues/3120上发牢骚

我很想知道其他尝试过这两种方法的人的来信。

Answer 3

这两个数据库的原理几乎相同。两者都支持离线场景，分散并具有灵活的数据模型。noms 实现了 git 中的一些想法，从而允许自定义合并操作，而 gun 实现自动冲突解决。