mysql键/值存储问题答案

【问题标题】：mysql key/value store problemmysql键/值存储问题
【发布时间】：2011-10-10 02:13:22
【问题描述】：

我正在尝试使用 mysql 实现键/值存储

我有一个包含 2 列的用户表，一列用于全局 ID，一列用于序列化数据。

现在的问题是，每次用户数据发生任何变化时，我都必须从数据库中检索序列化数据，更改数据，然后重新序列化并将其放回数据库。即使对任何用户数据有非常小的更改，我也必须重复这些步骤（因为无法在数据库本身内更新该单元格）

基本上，我正在研究人们在遇到此问题时通常使用哪些解决方案？

【问题讨论】：

你的序列化数据是什么格式的？
为什么不只存储数据本身而不是数据的序列化版本？
这就是键/值存储的工作方式。通常你不会在不先获取旧数据的情况下更新数据。可以在不获取原始数据的情况下更新的数据示例是计数器，但为什么要序列化计数器。那么，您使用的数据是什么？
当你有圆钉并且想将它们存放在方孔中时，这有点像问解决方案是什么。如果有问题，您需要 RDBMS 或文档存储，而不是键/值存储。
@tehvan 数据的序列化版本就是数据本身。

标签： mysql database key-value-store

【解决方案1】：

当这是一个问题时，人们不使用键/值存储，他们设计了一个规范化的关系数据库架构来将数据存储在可以更新的单独的单值列中。

【讨论】：

【解决方案2】：

也许您应该预处理您的 JSON 数据并将数据插入为分隔到字段中的正确 MySQL 行。

由于您的输入是 JSON，因此您有多种转换数据的方法：

您提到您的情况发生了许多小变化。它们发生在哪里？它们是否发生在列表的成员中？顶级属性？

如果更新主要发生在 JSON 数据的一部分中的列表成员中，那么实际上每个成员都应该在不同的表中表示为单独的行。

如果属性发生更新，则将其表示为字段。

我认为预处理成本不会对您造成影响。

【讨论】：

【解决方案3】：

老实说，您的解决方案是使用数据库作为美化的文件系统 - 对于您的应用程序核心的应用程序数据，我不推荐这种方法。

在我看来，使用关系数据库的最佳方式是存储关系数据——表、列、主键和外键、数据类型。在某些情况下这不起作用 - 例如，如果您的数据确实是文档，或者数据结构事先不知道。对于这些情况，您可以扩展关系模型，或者迁移到文档或对象数据库。

在您的情况下，我首先会看看序列化数据是否可以建模为关系数据，以及您是否需要数据库。如果是这样，请转到关系模型。如果您需要数据库但无法将数据建模为关系集，您可以选择键/值模型，将序列化数据提取到单独的键/值对中；这至少意味着您可以更新/添加单个数据字段，而不是修改整个文档。键/值不适合 RDBMS，但与您当前的架构相比，它可能是一个较小的跳跃。

【讨论】：

【解决方案4】：

当你有一个键/值存储时，假设你的序列化数据是 JSON，它只有在你有 memcached 时才有效，因为你不是每次都更新数据库，而是更新 memcache然后在后台将其推送到您的数据库。因此，您绝对必须更新整个值，而不是更新 JSON 数据中的单个字段，例如数据库中的地址。您可以从 memcached 快速更新和检索数据。由于数据库中没有复杂的关系，因此将数据从数据库推送和拉取到内存缓存会很快。

【讨论】：

【解决方案5】：

我会继续您正在做的事情，并为可索引数据创建单独的表。这使您可以将数据库视为单个数据存储，可以通过大多数操作组（包括更新、备份、恢复、集群等）轻松管理。

如果您需要执行诸如 like 查询之类的操作以提高搜索性能，您可能需要考虑的唯一一件事就是将 ElasticSearch 添加到组合中。

如果空间对您来说不是问题，我什至会将其设为仅插入数据库，因此任何更改都会添加一条新记录，这样您就可以保留历史记录。当然，您可能想要删除较旧的记录，但您可以有一个后台作业，在后台批量删除被取代的记录。（请注意，我描述的基本上是 Kafka）

现在有许多在性能方面优于 RDBMS 的替代方案。但是，它们都增加了额外的操作开销，因为它是另一个需要维护的中间件。

如果您有微服务架构，解决方法是将中间件保留为微服务堆栈的一部分。但是，您必须处理跨微服务传输数据的问题，因此最终还是要切换到 Kafka。

【讨论】：