gpt4 book ai didi

ruby-on-rails-3 - Postgres 序列化与新行与 NoSQL

转载 作者:行者123 更新时间:2023-11-29 12:38:25 25 4
gpt4 key购买 nike

我正在构建一个存储自定义数据集的 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 个条目存储在一个字段中对性能有何影响。

我认为一个请求一个响应的效果会好得多。 (即

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 多个排行榜),我只是想找出最有效的存储方式。

谢谢!

最佳答案

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

这似乎不是一个大到足以考虑在数据库中进行转换的问题——MongoDB 在这里不会有任何直接的优势。主要的症结在于如何设计数据访问查询。使用好的索引选择部分数据集总是比做一个大的开放式的要快 select * ,例如。

看看 'explain plan'针对您预期执行的查询类型,并相应地进行调整。如果您对不同类型查询的成本感兴趣,将一堆测试数据加载到测试数据库中然后查看 Postgres 提供的查询计划通常很有用。不同查询计划成本的相对数量是一个非常有效的指南,可以帮助您了解上线时的痛点。

关于ruby-on-rails-3 - Postgres 序列化与新行与 NoSQL,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14652440/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com