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) );
