Postgres序列化与新行与NoSQL

Question

我正在构建一个存储自定义数据集的Rails应用程序。更具体地说，我正在存储排行榜的档案。排行榜每个都有一组LeaderboardEntries，可以自定义字段(换句话说，并不是所有的排行榜都有相同的格式)。

快速示例：

Leaderboard 1 (Fields)
-------------
7_day_exponential_moving_average
total_count

Leaderboard 2 (Fields)
-------------
10_day_exponential_moving_average
total_count

现在，我正在将所有的排行榜条目序列化为排行榜中名为"data“的字段。结果是我对超过30,000个对象执行计算，并将结果存储在单个字段中。

我开始发现在异步执行计算时有一个缺陷(我需要等待所有计算完成，监视它们是否完成，然后存储所有数据)，似乎创建一个名为LeaderboardEntry的单独模型更有意义。我想知道的是，存储和查询30,000个不同的对象，而不是像我已经在做的那样，在一个字段中存储所有30,000个条目的性能影响。

我认为一个带有一个响应的请求会执行得更好。(即

SELECT serialized_data FROM leaderboards WHERE leaderboard_id=123  <-- 1 row with a very large field

vs

SELECT * FROM leaderboard_entries WHERE leaderboard_id=123 <-- 30,000 rows with small sets of data

我将其存储在序列化字段中的假设正确吗？或者，单独存储这些条目并不是什么大问题？我在这里想到的另一个想法是:使用像MongoDB这样的非small解决方案可能会更有效，然后我可以按leaderboard_entry字段排序，并将结果限制为小数量(一次50个结果)。

最终，我每天将生成超过100万个排行榜条目(对于20+排行榜)，我只是想找出存储它们的最有效的方法。

谢谢!

Answer 1

一个大的序列化字段存储和检索肯定比一堆小条目更有效(Postgres将整个存储为CLOB)。也就是说，这几乎可以肯定是一个过早的优化。规范化数据的优势是显著的-您可以通过使用select where field > xxx and field < yyy分段地跨过30k行的查询，这将使您的访问速度非常快。Postgres可以非常高效地对许多小对象进行操作。如果你的数据只是半结构化的，看看'hstore‘和JSON数据类型，postgres可以通过查询来检查它们。

这似乎不是一个足够大的问题来考虑数据库的转换- MongoDB在这里不会有任何立竿见影的优势。主要的症结在于如何设计用于数据访问的查询。例如，使用良好的索引选择部分数据集总是比使用大型开放式select *更快。

查看您预期要执行的查询类型的'explain plan'，并进行相应的调优。如果您对不同类型查询的成本感兴趣，那么将一组测试数据加载到测试数据库中，然后查看Postgres提出的查询计划通常很有用。不同查询计划的成本的相对数字是一个非常有效的指南，可以指导您在上线时的痛点在哪里。