选择多模型 DBMS 时要考虑哪些因素？ （OrientDB 与 ArangoDB）
What factors to consider when choosing a Multi-model DBMS? (OrientDB vs ArangoDB)
我想涉足多模型 DBMS 的世界，我没有特定的用例，只是想开始学习。
我发现有两个突出的 - OrientDB vs ArangoDB, but was unable to find any meaningful comparison, unopinionated 在它们之间。有人可以阐明两者之间 功能 的区别，以及使用其中一个的任何注意事项吗？如果我学会了一个，我可以轻松过渡到另一个吗？
（我也标记了FoundationDB，但它是专有的，我可能不会考虑它）
此问题要求对 OrientDB 与 ArangoDB 进行一般性比较 对于希望学习 多模型的人DBMS，不是关于哪个更好的自以为是的答案。
Disclaimer: I would no longer recommend OrientDB, see my comments below.
我可以提供一个稍微不那么偏颇的意见，因为我同时使用了 ArangoDB 和 OrientDB。它仍然有偏见，因为我是 OrientDB 的 node.js 驱动程序的作者 - oriento 但我对公司或产品都没有既得利益，我只是必须使用 OrientDB 更多.
ArangoDB 和 OrientDB 都针对类似的市场并且有很多相似之处：
- 两者都是多模型，您可以使用它们来存储文档、图形和简单的键/值。
- 两者都支持 Gremlin，但与他们自己的首选查询语言相比，它绝对是第二个 class 公民。
- 两者都支持 Java 脚本中的服务器端 "stored procedures"。在这两个系统中，这是通过稍微不那么惯用的 JavaScript API 实现的，尽管 ArangoDB 的要好得多。这将在即将发布的 OrientDB 版本中得到修复。
- 两者都提供 REST APIs，都旨在通过 Java 脚本请求处理程序用作 "API Server"。这在ArangoDB中比在OrientDB中实用很多。
- 两者均在许可下分发。
- 两者都是 ACID 并且具有事务支持，但是在这两个事务中都是服务器端操作 - 它们更像是命令的原子批处理，而不是您在传统 RDBMS 中可能习惯的事务类型。
但是，还是有很多不同的地方：
- ArangoDB没有"links"的概念，这是OrientDB中一个非常有用的特性。它们允许单向关系（就像网络上的超链接），而没有边的开销。
- ArangoDB 是用 C++（和 JavaScript）编写的，而 OrientDB 是用 Java 编写的。两者各有优势：
- 用 C++ 编写意味着 ArangoDB 使用 V8，同样的高性能 Java脚本引擎，为 node.js 和 Google Chrome 提供支持。而写成 Java 意味着 OrientDB 使用 Nashorn，它仍然很快但不是最快的。这意味着与 OrientDB 相比，ArangoDB 可以提供与 node.js 生态系统更高级别的兼容性。
- 在Java中编写意味着 OrientDB 可以在更多平台上运行，包括例如Raspberry PI。这也意味着 OrientDB 可以利用 Java 中编写的许多其他技术，例如OrientDB 通过 Lucene 提供极好的全文/地理空间搜索支持，这是 ArangoDB 所不具备的。
- OrientDB 使用 SQL 方言作为查询语言，而 ArangoDB 使用自己的自定义语言 AQL。从理论上讲，AQL 更好，因为它是专门针对该问题设计的，但在实践中，尽管它感觉与 SQL 非常相似，但关键字不同，并且是另一种需要学习的语言，而如果您对 OrientDB 的实现感觉更舒服重新习惯了SQL。 SQL 是声明式的，而 AQL 是命令式的 - 这里是 YMMV。
- ArangoDB 是一个 "mostly-memory" 数据库，当您的大部分数据都在 RAM 中时，它的性能最佳。这可能适合也可能不适合您的需要。 OrientDB 没有这个限制（但也喜欢 RAM）。
- OrientDB 是完全面向对象的 - 它支持 classes 属性和继承。这是非常有用的，因为它意味着您的数据库结构可以 1-1 映射到您的应用程序结构，而不需要像 ActiveRecord 这样丑陋的 hack。 ArangoDB 通过 Foxx 中的模型支持一些非常相似的东西，但它更像是一个可选的插件，而不是数据库工作方式的核心部分。
- ArangoDB 通过 Foxx, but it has not been designed by people with strong server-side JS backgrounds and reinvents the wheel a lot of the time. Rather than leveraging frameworks like express for their request handling, they created their own clone of Sinatra 提供了很大的灵活性，这当然使它与 express 几乎相同（express 也是 Sinatra 的克隆），但有细微的不同，这意味着 none express 的中间件或插件可以复用。同样，它们嵌入了 V8，但没有嵌入 libuv，这意味着它们不提供与 node.js 相同的非阻塞 APIs，因此用户无法确定给定的 npm 模块是否可以在那里工作。这意味着重要的应用程序不能使用 ArangoDB 作为后端的替代品，这否定了 Foxx 的许多潜在用途。
- OrientDB 首先支持 class 属性 级别和数据库级别的索引。您可以直接查询和插入特定索引以获得最大效率。我在 ArangoDB 中没有看到对此的支持。
- OrientDB 是更成熟的选择，拥有许多高知名度的用户。 ArangoDB 较新，知名度较低，但增长很快。
- ArangoDB 的文档非常好，它们为许多不同的编程语言提供了官方驱动程序。 OrientDB 的文档不是很好，虽然大多数平台都有驱动程序，但它们是由社区提供支持的，因此并不总是与最新的 OrientDB 功能保持同步。
- 如果您正在使用 Java（或 Java 网桥），您可以将 OrientDB 作为一个库直接嵌入到您的应用程序中。这个用例在 ArangoDB 中是不可能的。
- OrientDB有用户和角色的概念，还有Record Level Security。这对你来说可能是一个杀手级功能，对我来说是这样。它还支持基于令牌的身份验证，因此可以使用 OrientDB 作为 authorizing/authenticating 用户的主要方式。 OrientDB 也有 LDAP 集成。相比之下，ArangoDB 只支持一个非常简单的 auth 选项。
两种系统各有优势，选择哪种取决于你自己的情况：
如果您正在构建一个小型应用程序，并且您是一名正在优化开发人员生产力的 Web 开发人员，那么使用 ArangoDB 可能会更容易上手并运行 快速。
如果您正在构建一个更大的应用程序，它可能会存储许多 GB 或 TB 的数据，或者有成千上万的并发用户，或者有 "enterprise" 个用例，或者需要细粒度的安全控制，OrientDB 是适合你的。
如果要存储 RDF 或类似结构的链接数据，请选择 OrientDB。
如果您正在使用 Java，只需选择 OrientDB。
Note: This is (my opinion of) the state of play today, things change quickly and I would not underestimate the ruthless efficiency of the awesome team behind ArangoDB, I just think that it's not quite there yet :)
查尔斯·皮克 (codemix.com)
我想涉足多模型 DBMS 的世界，我没有特定的用例，只是想开始学习。
我发现有两个突出的 - OrientDB vs ArangoDB, but was unable to find any meaningful comparison, unopinionated 在它们之间。有人可以阐明两者之间 功能 的区别，以及使用其中一个的任何注意事项吗？如果我学会了一个，我可以轻松过渡到另一个吗？
（我也标记了FoundationDB，但它是专有的，我可能不会考虑它）
此问题要求对 OrientDB 与 ArangoDB 进行一般性比较 对于希望学习 多模型的人DBMS，不是关于哪个更好的自以为是的答案。
Disclaimer: I would no longer recommend OrientDB, see my comments below.
我可以提供一个稍微不那么偏颇的意见，因为我同时使用了 ArangoDB 和 OrientDB。它仍然有偏见，因为我是 OrientDB 的 node.js 驱动程序的作者 - oriento 但我对公司或产品都没有既得利益，我只是必须使用 OrientDB 更多.
ArangoDB 和 OrientDB 都针对类似的市场并且有很多相似之处：
- 两者都是多模型，您可以使用它们来存储文档、图形和简单的键/值。
- 两者都支持 Gremlin，但与他们自己的首选查询语言相比，它绝对是第二个 class 公民。
- 两者都支持 Java 脚本中的服务器端 "stored procedures"。在这两个系统中，这是通过稍微不那么惯用的 JavaScript API 实现的，尽管 ArangoDB 的要好得多。这将在即将发布的 OrientDB 版本中得到修复。
- 两者都提供 REST APIs，都旨在通过 Java 脚本请求处理程序用作 "API Server"。这在ArangoDB中比在OrientDB中实用很多。
- 两者均在许可下分发。
- 两者都是 ACID 并且具有事务支持，但是在这两个事务中都是服务器端操作 - 它们更像是命令的原子批处理，而不是您在传统 RDBMS 中可能习惯的事务类型。
但是，还是有很多不同的地方：
- ArangoDB没有"links"的概念，这是OrientDB中一个非常有用的特性。它们允许单向关系（就像网络上的超链接），而没有边的开销。
- ArangoDB 是用 C++（和 JavaScript）编写的，而 OrientDB 是用 Java 编写的。两者各有优势：
- 用 C++ 编写意味着 ArangoDB 使用 V8，同样的高性能 Java脚本引擎，为 node.js 和 Google Chrome 提供支持。而写成 Java 意味着 OrientDB 使用 Nashorn，它仍然很快但不是最快的。这意味着与 OrientDB 相比，ArangoDB 可以提供与 node.js 生态系统更高级别的兼容性。
- 在Java中编写意味着 OrientDB 可以在更多平台上运行，包括例如Raspberry PI。这也意味着 OrientDB 可以利用 Java 中编写的许多其他技术，例如OrientDB 通过 Lucene 提供极好的全文/地理空间搜索支持，这是 ArangoDB 所不具备的。
- OrientDB 使用 SQL 方言作为查询语言，而 ArangoDB 使用自己的自定义语言 AQL。从理论上讲，AQL 更好，因为它是专门针对该问题设计的，但在实践中，尽管它感觉与 SQL 非常相似，但关键字不同，并且是另一种需要学习的语言，而如果您对 OrientDB 的实现感觉更舒服重新习惯了SQL。 SQL 是声明式的，而 AQL 是命令式的 - 这里是 YMMV。
- ArangoDB 是一个 "mostly-memory" 数据库，当您的大部分数据都在 RAM 中时，它的性能最佳。这可能适合也可能不适合您的需要。 OrientDB 没有这个限制（但也喜欢 RAM）。
- OrientDB 是完全面向对象的 - 它支持 classes 属性和继承。这是非常有用的，因为它意味着您的数据库结构可以 1-1 映射到您的应用程序结构，而不需要像 ActiveRecord 这样丑陋的 hack。 ArangoDB 通过 Foxx 中的模型支持一些非常相似的东西，但它更像是一个可选的插件，而不是数据库工作方式的核心部分。
- ArangoDB 通过 Foxx, but it has not been designed by people with strong server-side JS backgrounds and reinvents the wheel a lot of the time. Rather than leveraging frameworks like express for their request handling, they created their own clone of Sinatra 提供了很大的灵活性，这当然使它与 express 几乎相同（express 也是 Sinatra 的克隆），但有细微的不同，这意味着 none express 的中间件或插件可以复用。同样，它们嵌入了 V8，但没有嵌入 libuv，这意味着它们不提供与 node.js 相同的非阻塞 APIs，因此用户无法确定给定的 npm 模块是否可以在那里工作。这意味着重要的应用程序不能使用 ArangoDB 作为后端的替代品，这否定了 Foxx 的许多潜在用途。
- OrientDB 首先支持 class 属性 级别和数据库级别的索引。您可以直接查询和插入特定索引以获得最大效率。我在 ArangoDB 中没有看到对此的支持。
- OrientDB 是更成熟的选择，拥有许多高知名度的用户。 ArangoDB 较新，知名度较低，但增长很快。
- ArangoDB 的文档非常好，它们为许多不同的编程语言提供了官方驱动程序。 OrientDB 的文档不是很好，虽然大多数平台都有驱动程序，但它们是由社区提供支持的，因此并不总是与最新的 OrientDB 功能保持同步。
- 如果您正在使用 Java（或 Java 网桥），您可以将 OrientDB 作为一个库直接嵌入到您的应用程序中。这个用例在 ArangoDB 中是不可能的。
- OrientDB有用户和角色的概念，还有Record Level Security。这对你来说可能是一个杀手级功能，对我来说是这样。它还支持基于令牌的身份验证，因此可以使用 OrientDB 作为 authorizing/authenticating 用户的主要方式。 OrientDB 也有 LDAP 集成。相比之下，ArangoDB 只支持一个非常简单的 auth 选项。
两种系统各有优势，选择哪种取决于你自己的情况：
如果您正在构建一个小型应用程序，并且您是一名正在优化开发人员生产力的 Web 开发人员，那么使用 ArangoDB 可能会更容易上手并运行 快速。
如果您正在构建一个更大的应用程序，它可能会存储许多 GB 或 TB 的数据，或者有成千上万的并发用户，或者有 "enterprise" 个用例，或者需要细粒度的安全控制，OrientDB 是适合你的。
如果要存储 RDF 或类似结构的链接数据，请选择 OrientDB。
如果您正在使用 Java，只需选择 OrientDB。
Note: This is (my opinion of) the state of play today, things change quickly and I would not underestimate the ruthless efficiency of the awesome team behind ArangoDB, I just think that it's not quite there yet :)
查尔斯·皮克 (codemix.com)