在数据库列中存储键值对答案

【问题标题】：Storing key-value pairs in a database column在数据库列中存储键值对
【发布时间】：2012-03-09 00:27:40
【问题描述】：

在我的代码库中，我最近遇到了团队做出的一项设计决策，其中键值对以格式化的方式存储在数据库 (Relational-mysql) 列中。有一组通用的元数据，并且该元数据的一个子集可能存在于特定记录中。对于给定的记录，其元数据子集及其值以如下格式存储在列中：

Key1:Value1\n\nKey2:Value2\n\nKey3:Value3\n\n.....

要获取给定记录 ID 的元数据，可以归结为只运行一个简单的选择，然后解析结果以在内存中填充字典。

这样做的理由如下：

比维护由 recordId/Key/Value 列组成的非实体化表具有更好的性能。

可扩展性

在数据库服务器上的空间上要保守一点。

我可以看到将这些配对存储在数据库列中的逻辑，但有些事情告诉我，从长远来看这可能会导致问题，并且可能不是解决“可扩展性”问题的灵丹妙药。

有人可以就这种方法可能存在的问题提供一些反馈，以及在高负载系统上存储和检索此类信息的最佳实践是什么。

谢谢

【问题讨论】：

如果您正在做大量的键值工作，那么关系数据库是错误的工具。为什么不使用 nosql 数据库呢？
嗯..系统的大部分本质上是事务性的，引入 NoSql 数据库（带有它的花里胡哨）来解决系统的这一方面几乎没有意义。

标签： database dictionary scalability key-value

【解决方案1】：

显然，这取决于特定情况，但这种违反 1NF 的行为通常是一种不好的方法。一个重要的问题是您永远无法查询元数据。（例如，“SELECT WHERE key2 = 'value3'”）另一个问题是，如果不解析、调整、取消解析和重写整个大集合，您永远无法更新单个键/值。单独处理索赔：

此声明是否已针对您的数据进行过实际测试？如果您只需要记录中的一个键/值，则当前必须支付数据库开销来读取整个集合，网络开销将其传输到客户端，以及 cpu 开销来解析出您需要的一个部分。做这项工作本质上正是数据库的设计目的，因此您实际上是在禁用擅长此类工作的组件，并使用不必要的客户端编程来模拟它。
他们是怎么理解的？将所有键/值对存储在单个字段中会随着对数的增加而降级。
几乎可以肯定是无关紧要的。磁盘空间比糟糕的设计便宜。

附：如果你有一个包含两个换行符的值会发生什么？

【讨论】：

这些都是很好的观点。我也有点偏爱 Kolinks 关于 memcaching 这些值的响应，但这种方法也需要评估。
另外请注意，您的键/值集的总大小将受到数据库字段的最大大小的限制。对于您今天的特定用途而言，这可能不是问题，但这并不是我所说的可扩展性。而且，它并不像空的数据库字段实际上占用空间。而且，如果磁盘空间如此重要，那么为什么不压缩现有数据呢？即，我认为您收到的解释非常冒昧。感谢挑战他们，这是一个很好的收获。

【解决方案2】：

最大的问题是它们是否有意义/您需要多久选择一次单独的对。

如果主要是一个属性包，存储为name = value，并且pair是相关的，那么一次性存储可以节省空间和时间。

如果您想轻松快速地访问单个对，那么带有名称和值列的表是有意义的，只要它们具有唯一的名称。这将占用更多空间，如果您需要一次访问多个空间，则会失去一些优势。

这个没有对错。可能有最好的，但这很容易改变。我们会根据具体情况使用这两种方法。

【讨论】：

【解决方案3】：

根据需要它们的频率，键/值对可以更好地存储在 Memcache 之类的东西中，这样任何人都可以即时虚拟地访问和更新它们。

对于不太重要的事情，一个简单的键/值数据库表会很好地工作，尤其是在有正确的引擎支持的情况下（例如，一个更适合快速读取而不是写入的引擎）。

如果它更像是一个存档，那么您所拥有的格式可以在服务器上的数据文件中运行，而不是在数据库中。

这完全取决于它的用途，真的。

【讨论】：

【解决方案4】：

这实际上是一种使您的关系数据库有效地变为NoSQL database 的方法。我之前在系统中使用过这种技术，我们试图从系统中挤出每一点性能，并且效果很好。在一种情况下，信息实际用于调用 REST API 并且需要在查询字符串中传递，因此信息被存储为查询字符串（例如：“var1=val1&var2=val2”），因此整个字符串可以按原样传递给 API。解析这种格式非常容易。但是您的问题是使用这种存储数据的方法有什么问题。我认为这些问题与normalizing your database as proposed by E.F. Codd 解决的问题相同。但现实情况是，为了达到预期的性能结果，数据库经常被去规范化，而 NoSQL 方法正在取得进展，因为当今系统需要处理大量数据。

【讨论】：