3

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

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

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

基本上我正在研究人们在遇到这个问题时通常使用什么解决方案？

4

5 回答 5

1

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

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

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

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

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

我认为预处理的成本不会对您造成伤害。

于 2011-07-21T11:52:23.117 回答
0

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

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

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

于 2011-07-22T09:08:27.723 回答
0

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

于 2011-07-21T10:22:56.890 回答
0

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

于 2012-06-29T01:15:27.227 回答
0

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

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

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

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

如果你有一个微服务架构，解决这个问题的方法是将中间件作为你的微服务堆栈的一部分。但是，您必须处理跨微服务传输数据的问题，因此您最终仍会在这一切下切换到 Kafka。

于 2020-12-02T07:27:08.167 回答