当前位置:  开发笔记 > 编程语言 > 正文

Postgresql JSONB即将推出.现在用什么?Hstore?JSON?EAV?

如何解决《PostgresqlJSONB即将推出.现在用什么?Hstore?JSON?EAV?》经验,为你挑选了1个好方法。

在完成关系DB/NoSQL研究辩论之后,我得出的结论是,我将继续将PG作为我的数据存储.该决定的一个重要部分是宣布JSONB达到9.4.我的问题是我现在应该怎么做,从头开始构建一个应用程序,知道我想要迁移到(我的意思是现在使用!)jsonb?对我来说,DaaS选项将会运行9.3.

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

那么,我是否围绕当前版本的hstore或json数据类型,"good ol"EAV或其他东西构建我的应用程序?我应该以某种方式构建我的数据库和应用程序代码吗?任何建议将不胜感激.我相信其他人可能会面临同样的问题,因为我们等待PostgreSQL的下一次正式发布.

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

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

提前感谢任何输入!



1> theory..:

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

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

现在,当你有WHERE bar ->> somekey,它应该使用索引.

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

所以我会倾向于JSON,除非你确定在你有机会升级到9.4之前,你会大量使用关键提取来踢你的服务器.但是为了确保这一点,我想说,现在对预期的查询量做一些基准测试,看看什么最适合你.

推荐阅读
mobiledu2402851373
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有