22

在经历了关系 DB/NoSQL 研究辩论之后，我得出的结论是，我将继续使用 PG 作为我的数据存储。该决定的很大一部分是宣布 JSONB 进入 9.4。我的问题是我现在应该做什么，从头开始构建一个应用程序，知道我想迁移到（我的意思是现在使用！）jsonb？对我来说，DaaS 选项将运行 9.3 一段时间。

据我所知，如果我错了，请纠正我，hstore 会运行得更快，因为我将对 hstore 列中的许多键进行大量查询，如果我要使用普通 json，我不会无法利用索引/GIN 等。但是我可以利用 json 嵌套，但是运行任何查询都会非常慢并且用户会感到沮丧。

那么，我是否围绕当前版本的 hstore 或 json 数据类型、“good ol” EAV 或其他东西构建我的应用程序？我应该以某种方式构建我的数据库和应用程序代码吗？任何建议将不胜感激。我敢肯定，在我们等待 PostgreSQL 的下一个正式版本时，其他人可能会面临同样的问题。

关于我要构建的应用程序的一些额外细节：

- 非常相关（以下有一个例外） -
强大的社交网络方面（群组、朋友、喜欢、时间线等） -
基于具有可变用户分配属性的单个对象，可能是 10 或 1000+（这是无模式设计的地方需要发挥作用）

提前感谢您的任何意见！

4

2 回答 2

12

这取决于。如果您希望有很多用户、非常高的交易量，或者每个查询的属性获取数量惊人，我会说使用 HSTORE。但是，如果您的应用程序开始时很小并随着时间的推移而增长，或者获取属性的事务相对较少，或者每个查询只获取一些，那么使用 JSON。即使在后一种情况下，如果您没有获取许多属性，而是经常在WHERE查询子句中检查一个或两个键，您可以创建一个功能索引来加快速度：

CREATE INDEX idx_foo_somekey ON foo((bar ->> 'somekey'));

现在，当您拥有 时WHERE bar ->> somekey，它应该使用索引。

当然，使用嵌套数据并在可用时升级到 jsonb 会更容易。

所以我会倾向于 JSON，除非你确定在你有机会升级到 9.4 之前你会通过大量使用密钥获取来踢你的服务器。但为了确保这一点，我想说，现在对预期的查询量进行一些基准测试，看看什么最适合你。

于 2014-04-16T23:01:23.370 回答
3

您可能没有给出足够详细的答案，但我会这样说......如果您的数据“非常相关”，那么我相信您最好的课程是使用良好的关系设计来构建它。如果它只是一个具有“变量分配属性”的字段，那么这听起来对 hstore 来说是一个很好的用途。在这一点上，这是非常可靠的。我一直在阅读 9.4 和 jsonb 听起来很酷，但是暂时不会出现。我怀疑 9.3 中的良好架构设计 + 非常有针对性地使用 hstore 可能会产生性能和灵活性的良好组合。

于 2014-04-05T01:41:52.407 回答