Question

首先要做的事情：我知道Key-Value DB是表现最佳的数据库。我的假设是，这是由于它们的简单性（坚持很少的原语）。（ EDIT2 ：显然也因为大部分时间都在记忆中）

无论如何更复杂的数据结构如层次树等。使用像redis这样的数据库，你必须构建一个基于带有链接的“扁平”哈希的结构，而对于像couchdb这样的文档数据库，你只需要自己构建结构：

"menu": {
    "id": "file",
     "value": "File",
     "popup": {
        "menuitem": [
             {
              "value": "New",
              "onclick": "CreateNewDoc()"
              },
              {
              "value": "Open",
              "onclick": "OpenDoc()"
              },
              {
              "value": "Close",
              "onclick": "CloseDoc()"
              }
       ]
}

如果我有这样的结构，使用redis性能和可用性是否有意义？

有趣的是，键值和文档数据库经常以1：1的比例进行比较，同时服务于不同的目的或/和用例恕我直言。

修改

我正在寻找的东西：通常我希望有一个类似JSON的数据库存储，这使我能够轻松地动态定义和构建复杂的结构，并通过使用数据库系统获得好处（故障转移，速度，......）。

谢谢！

Answer 1

如果我有这样的结构，使用redis甚至是有意义的性能和可用性？

您描绘的结构由json文档中的嵌入数据组成，但即使使用文档数据库，embedded和referenced/linked数据之间仍然存在差异。如果将大量数据嵌入到单个文档中，最终可能会出现性能问题和数据碎片。另一方面，引用更灵活，但需要一些连接逻辑。总结一下 - 这取决于您的域模型和您试图解决的问题。关于redis，有像ohm这样的库，它们提供了更多基于OOP的更高级别的数据抽象。

我在寻找：通常我想拥有一个类似JSON的数据库商店，这让我很容易定义和建立复杂的飞行中的结构和使用a获得好东西数据库 - 系统（故障转移，速度，......）。

虽然mongodb可能是最受欢迎的文档数据库，后面是couchdb，但您也可以尝试查看其他解决方案，如arangodb或orientdb。它们中的每一个都建立在一些哲学之上，与其他解决方案相比，它可能在特定领域提供益处，例如， couchdb的map-reduce查询方式可能并不适合所有人，但它很耐用。

Answer 2

像Redis这样的键值存储执行得非常好，因为它们将数据存储在内存中，您可以比存储在磁盘上的数据快多次读/写。

内存存储的问题是容错：如果Redis意外关闭，内存清除，所有数据都丢失。因此，当您经常读取和写入数据时，Redis是合适的，但您不介意这些数据是否丢失。例如：登录会话，丢失数据意味着用户只需再次登录。

CouchDB和其他文档存储了容错的交换速度，确保您的数据在更多情况下更安全。像CouchDB这样的文档存储也提供查询，让您搜索和解析数据，这是Redis无法做到的。当你正在阅读和编写你不能随意丢失的数据时，像CouchDB这样的文档存储是合适的。

DocumentDB与具有层次结构性能的键值DB

2 个答案: