1

我想将我的应用程序的通知存储在一个排序集或 Redis 列表中（是一个也有通知的链接缩短器）。我有不同类型的通知，所以我不能像普通字符串一样存储它们。例如，如果我想存储：

  • 通知文本
  • 通知类型

我有两种方法。一种是序列化 Json 并像普通字符串一样存储，并在我想使用它时反序列化。或者另一种方法是将键保存在列表中，然后再次点击 Redis 到另一个数据结构，以通过存储在列表中的键获取通知哈希。

就像一个通知系统，系统会一直在读写。

那么在几行反序列化和序列化 VS 拆分数据和多个 DB 命中？

我对这类决策没有太多经验，所以也许有人遇到过这种情况并且知道在效率和可扩展性方面什么是最好的方法，或者至少可以解释我如何做出决策，因为像许多人一样事情，我/我的应用程序的决定不是其他人/其他应用程序的决定。

谢谢 ：）

4

1 回答 1

4

在做了一些测试之后，最好的成绩归于 Json 序列化数据案例。我想这也取决于序列化结构。在测试用例中，它仅序列化 2 个字段结构。

一些结果（以秒为单位的时间）：

Users: 600
Notifications per user: 1200
--------------------
#### With Json in Set structure ####
Write time: 93.0
Read time: 6.65
dbsize (number of keys): 600
Memory: 150.60M
#### With set and hash data structures ####
Write time: 367.72
Read time: 40.2
dbsize (number of keys): 721200
Memory: 224.17M

我将稍微解释一下测量测试（我使用了 Python）：

对于 Json 序列化案例，我使用了一个排序集（zset）（每个用户的通知 zset），它的分数是 unix 时间戳（浮点数）。它序列化一个 2 字段哈希（Python 字典）并将字符串添加到排序集中。

为了检索，我得到了所有的 zset 字符串，并一一反序列化数据。

对于 Hash 方法，我使用了 3 个数据结构：

  • 最简单的一个是每个通知 zset 的计数器，用于为每个通知创建唯一键（我也用 uuids 测试过，结果或多或少是相同的，所以差别不大）
  • 另一种数据结构是 zsets，与 Json 的情况相同，但我们不存储 Json 数据，而是存储通知哈希键
  • 最后一个是包含所有数据字段的通知哈希

并检索数据。或多或少与 json 案例相同，我从每个 zset 中获取所有密钥，然后一一获取所有通知。

我知道这种情况不是我所面临的，因为通常我不会检索所有通知，而且测试可能有错误或者有更好的方法来解决这种情况。

无论如何，这里有一些测量和测试脚本

于 2013-04-04T14:03:07.910 回答