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

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

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条目的良好表现.更新将经常进行,但更频繁地进行搜索.

谢谢.

您的问题不明确,因为您不清楚自己的目标.

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

简短的回答是你可能不想使用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)
);