database - 基于键值的数据库，有人可以向我解释如何实际使用它们吗？

Question

似乎对基于键/值的数据库有很大的推动作用，我相信 memcache 就是这样。

该值通常是某种可以保存更有意义数据的集合或 xml 文件吗？

如果是，反序列化数据通常比在返回基于行的结果集的表上执行传统的 JOINS 和选择更快吗？

Answer 1

所发生的事情是，像谷歌和亚马逊这样的一些非常、非常、非常大的网站占据了一个很小很小的利基市场，它们的数据存储和检索要求与其他任何人都如此不同，以至于需要一种新的存储/检索数据的方法。我确信这些人知道他们在做什么，他们非常擅长他们所做的事情。

但是，然后这会被拾取并报告并扭曲为“关系数据库无法处理网络数据”。此外，读者开始认为“嘿，如果关系数据库对 Amazon 和 Google 来说不够好，那么它们对我来说也不够好。”

这些推论都是错误的：99.9% 的数据库（包括网站背后的数据库）与亚马逊和谷歌不在同一个球场——不在几个数量级之内。对于这 99.9%，没有任何改变，关系数据库仍然可以正常工作。

Answer 2

与大多数事情一样，“这取决于”。如果连接相对无关紧要（即，少量连接在良好键控的数据上），并且您正在存储特别复杂的数据，那么坚持使用更复杂的查询可能会更好。

这也是新鲜度的问题。在许多情况下，许多连接的目的是汇集非常不同的数据。也就是说，数据的相对新鲜度差异很大。当跨大量数据对的一小部分数据被更新时，保持键值对表同步会增加相当大的复杂性和开销。系统复杂性通常可以被认为是性能成本的一种形式；在不影响性能的情况下对复杂系统进行更改所花费的时间、风险和成本通常远大于简单的系统。

最好的解决方案总是尽可能简单地编写代码。在大多数情况下，我会说这意味着创建一个完全规范化的数据库设计并加入其中的废话。只有在性能成为明显问题后才重新审视您的设计。当您分析问题时，问题所在以及需要采取哪些措施来解决这些问题也很明显。如果它正在减少连接，那就这样吧。你会知道什么时候需要知道。

Answer 3

我在键/值数据库方面没有很多经验，所以对我所说的话持保留态度。

话虽如此，我首先要指出的是 memcached 不是键/值数据库。数据库意味着某种持久存储，而 memcached 不是。Memcached 旨在成为一个临时存储，用于将查询保存到实际数据库中。

除此之外，我的理解是您将无法用键/值数据库替换您的 RDBMS。它们往往最适合非结构化数据或您可能不知道需要存储的所有属性的其他数据。如果您需要存储高度结构化的数据，那么您无法比传统的 RDBMS 做得更好。

Answer 4

它们可以是需要反序列化的复杂结构化数据。它们也可以是简单的固定大小记录，就像您的 RDBMS 一样。部分好处是您可以自己做出决定。在优化数据库时，您不仅限于 SQL 可以做什么。

你问的方式听起来像是加入或反序列化将永远是瓶颈。但在任何数据库中，事情从来没有那么简单。您也可以将非规范化数据放入 RDBMS 中，或者在键值数据库之上编写 RDBMS 接口，如果您真的需要的话。