postgresql hstore 键/值与传统 SQL 性能答案

【问题标题】：postgresql hstore key/value vs traditional SQL performancepostgresql hstore 键/值与传统 SQL 性能
【发布时间】：2012-02-28 18:33:12
【问题描述】：

我需要开发一个键/值后端，如下所示：

Table T1 id-PK, Key - string, Value - string
INSERT into T1('String1', 'Value1')
INSERT INTO T1('String1', 'Value2')

Table T2 id-PK2, id2->external key to id
some other data in T2, which references data in T1 (like users which have those K/V etc)

我听说过带有 GIN/GIST 的 PostgreSQL hstore。什么更好（性能方面）？使用 SQL 连接并具有单独的列（键/值）以传统方式执行此操作？ PostgreSQL hstore 在这种情况下表现更好吗？

数据的格式应该是任意键=>任意值。我也想做文本匹配，例如部分搜索（SQL 中的 LIKE % 或使用 hstore 等效项）。我计划在其中包含大约 1M-2M 条目，并且可能会在某个时候扩展。

你有什么推荐的？采用 SQL 传统方式/PostgreSQL hstore 或任何其他具有持久性的分布式键/值存储？

如果有帮助，我的服务器是具有 1-2GB RAM 的 VPS，所以不是一个很好的硬件。我还想在此之上有一个缓存层，但我认为这会使问题复杂化。我只想要 2M 条目的良好性能。更新会经常进行，但搜索会更频繁。

谢谢。

【问题讨论】：

我认为你应该在 serverfault.com 上问这个问题。
postgres 邮件列表也不错，然后您可以将答案发回这里并获得积分；-) 试试archives.postgresql.org/pgsql-general 或者archives.postgresql.org/pgsql-performance。

标签： sql performance postgresql key

【解决方案1】：

您的问题不清楚，因为您不清楚自己的目标。

这里的关键是索引（双关语） - 如果您要处理大量的键，您希望能够以最少的查找来检索它们并且不提取不相关的数据。

简短的回答是您可能不想使用hstore，但让我们看看更详细的...

每个id 是否有很多键/值对（数百个以上）？不要使用hstore。
您的任何值是否会包含大块文本 (4kb+)？不要使用hstore。
您希望能够通过通配符表达式中的键进行搜索吗？不要使用hstore。
您要执行复杂的联接/聚合/报告吗？不要使用hstore。
您会更新单个键的值吗？不要使用hstore。
id 下有多个同名键？无法使用hstore。

那么hstore 有什么用呢？好吧，一个很好的场景是，如果您想为外部应用程序保存键/值对，您知道您总是想检索 all 键/值，并且总是将数据保存为块（即，它从未就地编辑过）。同时，您确实需要一些灵活性来搜索这些数据——尽管非常简单——而不是将其存储在一个 XML 或 JSON 块中。在这种情况下，由于键/值对的数量很少，您可以节省空间，因为您将多个元组压缩为一个 hstore。

把它当作你的桌子：

CREATE TABLE kv (
  id /* SOME TYPE */ PRIMARY KEY,
  key_name TEXT NOT NULL,
  key_value TEXT,
  UNIQUE(id, key_name)
);

【讨论】：

【解决方案2】：

我认为设计的标准化很差。尝试更多类似的方法：

CREATE TABLE t1
(
  t1_id serial PRIMARY KEY,
  <other data which depends on t1_id and nothing else>,
  -- possibly an hstore, but maybe better as a separate table
  t1_props hstore
);

-- if properties are done as a separate table:
CREATE TABLE t1_properties
(
  t1_id int NOT NULL REFERENCES t1,
  key_name text NOT NULL,
  key_value text,
  PRIMARY KEY (t1_id, key_name)
);

如果属性很小，并且您不需要在连接中大量使用它们或使用花哨的选择标准，那么hstore 可能就足够了。 Elliot 在这方面列出了一些需要考虑的明智事项。

您对用户的引用表明这是不完整的，但您并没有真正提供足够的信息来说明这些用户的归属。您可能会在t1 中使用数组，或者使用单独的表可能会更好。

【讨论】：