在经历了关系型 DB/NoSQL 研究辩论之后，我得出的结论是我将继续使用 PG 作为我的数据存储。该决定的一个重要部分是宣布 JSONB 即将推出 9.4。我的问题是我现在应该做什么，从头开始构建一个应用程序，知道我想迁移到（我的意思是立即使用！）jsonb？我的 DaaS 选项将运行 9.3 一段时间。
据我所知，如果我错了请纠正我，hstore 会运行得更快一些，因为我将对 hstore 列中的许多键进行大量查询，如果我要使用纯 json，我不会无法利用索引/GIN 等。但是我可以利用 json 嵌套，但运行任何查询都会非常慢，用户会感到沮丧。
那么，我是否围绕当前版本的 hstore 或 json 数据类型、“good ol”EAV 或其他内容构建我的应用程序？我应该以某种方式构建我的数据库和应用程序代码吗？任何建议将不胜感激。我相信在我们等待 PostgreSQL 的下一个正式版本时，其他人可能会面临同样的问题。
关于我想要构建的应用程序的一些额外细节：
- 非常相关（下面有一个例外）
-强大的社交网络方面（群组、朋友、喜欢、时间线等）
-基于具有可变用户分配属性的单个对象，可能有 10 个或 1000 个以上（这是无模式设计需求发挥作用的地方）
预先感谢您的任何意见！
这取决于。如果您期望拥有大量用户、非常高的事务量或每个查询的属性获取数量惊人，我会建议使用 HSTORE。但是，如果您的应用程序从小规模开始并随着时间的推移而增长，或者获取属性的事务相对较少，或者每次查询只获取一些属性，那么请使用 JSON。即使在后一种情况下，如果您没有获取许多属性，而是经常检查一个或两个键WHERE查询的子句中，您可以创建一个功能索引来加快速度：
CREATE INDEX idx_foo_somekey ON foo((bar ->> 'somekey'));
现在，当你有WHERE bar ->> somekey，它应该使用索引。
当然，使用嵌套数据并在可用时升级到 jsonb 会更容易。
因此，我会倾向于 JSON，除非您确定在有机会升级到 9.4 之前，您会因为大量使用密钥获取而让服务器崩溃。但为了确定这一点，我想说，现在就对预期查询量进行一些基准测试，看看什么最适合您。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
