Question

我正在考虑将PostgreSQL的jsonb列类型用于新的后端项目，该项目主要用作REST-ful JSON API。我相信PostgreSQL的jsonb将非常适合这个项目，因为它将为我提供JSON对象而无需在后端进行转换。

但是，我已经读过，jsonb数据类型在添加密钥时会变慢，而我的架构需要使用主键和外键引用。

我想知道在自己的列中是否有主键/外键（以标准的关系数据库方式），然后对其余数据使用jsonb列将是有益的，否则会导致问题（无论现在还是未来）？

简而言之，就是：

table car(id int, manufacturer_id int, data jsonb)

表现更好或更差：

table car(data jsonb)

特别是在经常查找外键时？从性能或架构的角度来看，第一个会有缺点吗？

Answer 1

PRIMARY KEY或FOREIGN KEY约束 中涉及的所有值必须 存储为专用列（最好采用标准化格式）。约束和引用不适用于嵌套 json / jsonb列内的值。

至于其他数据： 取决于 。将它们置于jsonb（最好）值内，具有存储非结构化文档类型数据的众所周知的优点和缺点。

对于所有或大多数行都存在的属性，将它们作为单独的列存储将更可能更好（更快，更清洁，更小的存储）。索引更容易，查询也更简单。即使新的jsonb具有amazing index capabilities，索引专用列仍然更简单/更快。

对于很少使用或动态显示的属性，或者如果要在数据库内部进行大量处理而存储和检索JSON值，请查看jsonb。

对于主要包含字符数据的基本EAV structures，如果没有嵌套且没有与JSON的连接，我会考虑hstore。还有xml（更复杂和冗长）和json数据类型（被jsonb取代），这些数据正在逐渐消失。

Answer 2

哪个表现更好？取决于使用情况。当您比较SQL（关系）和NoSQL（KeyValue或Document）数据库时，这是同一个问题。对于某些用例，NoSQL数据库执行得非常好，而其他用户则没有。

关系概念（规范化架构）针对典型的OLTP使用进行了优化 - 70％读取/ 30％写入，多用户，大量更新，报告计算，一些即席查询。关系概念相对较广泛..具有非常广泛的可用性（证据，会计，处理支持，......）。通常情况并非如此。

很明显，专门的数据库（Document，KeyValue，Graph）在专业用例上可以明显更好（一个订单更快）。但它们的使用范围要窄得多。如果您没有优化用例，那么性能可能会很差。

其他问题是数据库大小 - 记录数字。生产数据库的性能差异可能在十万行中很大。对于一些较小的数据库，影响可能并不显着。

Postgres是关系数据库，我的首选是对数据库中的所有重要数据使用规范化模式。当你使用它时，它很快很快。非关系类型非常适合某些模糊数据（HStore，JSON，XML，Jsonb） - 它明显优于EAV模式（在更大的数据上表现更差）。

如果您需要做一些重要的决定，请准备原型，填写预期数据（3年）并检查系统的一些重要查询的速度。注意：对这些基准测试的强烈影响使用了hw，当前负载，电流sw。