1

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

快速示例：

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

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

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

我开始看到异步执行计算时存在缺陷（我需要等待所有计算完成，监控它们是否完成，然后存储所有数据），看起来好像创建了一个名为 LeaderboardEntry 的单独模型会更有意义。我想知道的是存储和查询 30,000 个不同对象与将所有 30,000 个条目存储在单个字段中的性能影响，就像我已经在做的那样。

我认为一个请求和一个响应会执行得更好。（IE

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

对比

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

我假设将其存储在序列化字段中是否正确？或者单独存储条目不是什么大不了的事？我在这里有另一个想法：使用像 MongoDB 这样的 nosql 解决方案可能更有效，然后我可以按 leaderboard_entry 字段排序并将结果限制为少量（一次 50 个结果）。

最终，我每天将生成超过 100 万个排行榜条目（用于 20 多个排行榜），我只是想找出最有效的存储方式。

谢谢！

4

1 回答 1

4

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

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

查看您预期执行的查询类型的“解释计划” ，并进行相应调整。如果您对不同类型查询的成本感兴趣，通常只需将一堆测试数据加载到测试数据库中，然后查看 Postgres 提出的查询计划。不同查询计划的成本相对数量是您上线时痛点所在位置的非常有效的指南。

于 2013-02-01T19:55:04.543 回答