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的表现是否更好？

数据格式应为任意键=＆gt;任何值。我也想做文字匹配，例如部分搜索（在SQL中使用LIKE％或使用等效的hstore）。我打算在其中包含大约1M-2M的条目，并且可能在某些时候进行扩展。

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

如果有帮助，我的服务器是一个带1-2GB RAM的VPS，所以硬件不是很好。我还想在此基础上设置一个缓存层，但我认为它使问题复杂化。我只想要2M条目的良好表现。更新将经常进行，但更频繁地进行搜索。

感谢。

Answer 1

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

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

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

每个id是否有很多键/值对（数百+）？请勿使用hstore。
您的任何值都包含大块文本（4kb +）吗？请勿使用hstore。
您是否希望能够通过通配符表达式按键搜索？请勿使用hstore。
您想进行复杂的连接/聚合/报告吗？请勿使用hstore。
您是否会更新单个密钥的值？请勿使用hstore。
id下具有相同名称的多个密钥？无法使用hstore。

那么hstore的用途是什么？好吧，一个好的方案是，如果你想为外部应用程序保存键/值对，你知道你总是想要检索所有键/值，并且总是将数据保存为块（即，它永远不会就地编辑）。与此同时，您确实希望能够灵活地搜索这些数据 - 非常简单 - 而不是将其存储在XML或JSON块中。在这种情况下，由于键/值对的数量很小，因此您可以节省空间，因为您将几个元组压缩为一个hstore。

将此视为您的表：

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

Answer 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可能就足够了。艾略特在这方面提出了一些值得考虑的合理事项。

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

postgresql hstore key / value vs传统的SQL性能

2 个答案: