键/值 Postgres Sql 表性能

Question

我目前正在构建一个 Rails 应用程序，其中有一个“文档”数据表，用于存储对生活在 S3 服务器上的 pdf 的引用。这些文档可能有 100 种不同的类型。每种类型最多可以有 20 个属性或元信息。

我的困境是我是为每种文档类型创建 100 个关系表，还是只创建一个引用 doc_id 的键/值数据表。

我的直觉告诉我使用 key/value 以获得灵活性，以便随着时间的推移搜索和支持越来越多的文档类型，而无需创建新的迁移。但是，我知道这种技术存在缺陷。我首先关心的当然是桌子的大小。键/值表最终可能包含数百万行。

另一方面，拥有 100 个属性表在全文搜索情况下查询将是一场噩梦。

所以底线是，通过键/值，在具有数百万行的 3 列 Postgres 表上的性能是一个扩展问题吗？还有关于 value 字段的 join 呢？

顺便说一句，这些数据几乎永远不会改变。所以它将是 90% 的读取。

Answer 1

考虑一个带有 hstore 列的表。它是一种用于存储键/值对的 PostgreSQL 数据类型。

http://www.postgresql.org/docs/9.1/static/hstore.html

还有多个 Ruby gem 将 hstore 支持添加到 ActiveRecord。这是我写的一个：https://github.com/JackC/surus您还可以搜索 ruby​​ gems 以找到大约十几个替代品。