postgresql hstore key/value vs传统的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中使用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)
);