postgresql hstore 键/值与传统 SQL 性能对比

Question

我需要开发一个键/值后端，像这样:

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 中的 % 或使用等效的 hstore)。我计划在其中包含大约 100 万到 200 万个条目，并可能在某个时候进行扩展。

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

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

谢谢。

Answer 1

你的问题不清楚，因为你不清楚你的目标。

这里的关键是索引(双关语)——如果您处理大量的键，您希望能够以最少的查找次数检索它们，而不提取不相关的数据。

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

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

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

将此视为您的表格:

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