我正在尝试决定数据库设计,在这个阶段尽可能少的假设(关于 Web 应用程序的实际发展方式)。
作为第一步,了解 JOINS 的成本很高,我正在考虑使用少量的整体表,而不是大量规范化的小表。作为第二点,我在使用 hstore、常规表和 JSONB(使用 GiST 索引)之间感到困惑。
AFAIK(请随时纠正):
通常,在 Postgres 中,已知 hstore 的性能优于其他数据类型。FOSDEM PGDAY 的这个演示文稿有一些有趣的统计数据(在幻灯片的后半部分)。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
hstore 的一个优势是快速索引(GiN 或 GiST)。但是,使用 JSONB,GiN 和 GiST 索引也可以应用于 JSON 数据。
来自 2nd Quadrant 的专业人士的这篇博客说:“在这一点上,在所有新应用程序中用 jsonb 替换 hstore 可能是值得的”(滚动到最后): http ://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-动态列/
所以我想决定以下几点:
- 对于数据的主要(结构化)部分:它应该放在几个关系表中(相对较大,有很多列),还是应该是使用 hstore 的多个键值存储?
- 对于临时(用户贡献/非结构化)数据,它应该是 JSON 还是 hstore 中的临时键值存储(键存储在主要关系表之一中)?
关系数据库是围绕连接设计的,并经过优化以做好它们。
除非您有充分的理由不使用标准化设计,否则请使用标准化设计。
jsonb
hstore
当您不能使用规范化数据模型时,例如当数据模型快速变化并且是用户定义的时候,类似的事情很有用。如果您可以对它进行关系建模,请对其进行关系建模。如果不能,请考虑 json 等。如果您在 json/jsonb/hstore 之间进行选择,通常选择 jsonb,除非您有理由不这样做。
这就是我在我的博客文章中所说的,它只是针对这个主题。请阅读整篇文章。您引用的段落指出,如果您选择动态结构,则应该选择 jsonb 而不是 hstore,但博客文章的其余部分是关于为什么您通常应该尽可能地选择关系模型。
所以。对主要结构化部分进行建模。如果表真的很宽,有很多列,这可能表明需要进一步规范化。不要害怕加入。学会爱加入。连接许多小表通常比查询和维护大的非规范化表要快。仅当您需要针对特定情况进行非规范化时,最好通过物化视图......但在您知道需要并且有实际的具体问题要解决之前不要这样做。
对于自由格式和非结构化的用户贡献数据,请使用 jsonb。它的性能应该与 hstore 一样好,但它更灵活且更易于使用。
要理解的一件相关事情:像 jsonb 上使用的 GiST 和 GIN 索引通常比普通的 b-tree 索引效率低得多。它们更灵活,但是普通列上的 b 树索引几乎总是要快得多。