我正在构建存储自定义数据集的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这样的nosql解决方案可能更高效，然后我可以按leaderboard_entry字段排序并将结果限制为少量（一次50个结果）。
最终，我每天将生成超过100万个排行榜条目（20多个排行榜），我只是想找出最有效的存储方式。
谢谢！
答案 0 :(得分：4)
一个大的序列化字段肯定比一堆小条目更有效地存储和检索（Postgres将整个东西存储为CLOB）。也就是说，这几乎肯定是一个不成熟的优化。规范化数据的优势非常明显 - 您可以使用select where field > xxx and field < yyy分段切换30k行查询，这将使您的访问时间非常快。 Postgres可以非常有效地对许多小物体进行操作。如果您的数据只是半结构化的，请查看“hstore＆＃39;和JSON数据类型，postgres可以使用查询进行检查。
考虑在数据库中进行切换似乎不是一个足够大的问题 - MongoDB在这里没有任何直接的优势。大多数问题的关键在于您如何设计数据访问查询。例如，使用好的索引选择部分数据集总是比做一个大的开放式select *更快。
查看'explain plan'您预期要执行的查询类型，并相应调整。如果您对不同类型的查询的成本感兴趣，那么将一堆测试数据加载到测试数据库中然后查看Postgres提出的查询计划通常很有用。不同查询计划的相对成本数量是一个非常有效的指南，可以指导您在上线时的痛点。