PostgreSQL的hstore键/值VS传统SQL性能

我需要开发一个键/值后端，这样的事情：PostgreSQL的hstore键/值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)

我听说PostgreSQL的hstore与GIN/GIST。什么更好（性能方面）？这样做与传统的方式与SQL连接并有单独的列（键/值）？ PostgreSQL hstore在这种情况下表现更好吗？

数据的格式应该是任意键=>任何值。我也想做文字匹配例如部分搜索（SQL中LIKE％或使用hstore等效项）。我打算在其中有大约1M-2M的条目，并可能在某个时间点进行缩放。

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

如果有帮助，我的服务器是一个带有1-2GB内存的VPS，所以不是很好的硬件。我也在考虑在此之上建立一个缓存层，但我认为这会让问题复杂化。我只想要2M条目的良好表现。更新将经常进行，但更频繁地进行搜索。

谢谢。

来源

2012-02-28 florinp

我想你应该在serverfault.com上提出这个问题。 – uvesten 2012-06-26 08:37:45

postgres邮件列表也不错，然后你可以在这里发布答案，并拿起要点;-)尝试http://archives.postgresql.org/pgsql-general/或者http：// archives。 postgresql.org/pgsql-performance/。 – iain 2012-06-27 17:23:00

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

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

简短的回答是，你可能不希望使用hstore，但让我们看看更详细...

是否每个id有很多键/值对（几百+）？请勿使用hstore。
您的任何值是否包含大块文本（4kb +）？请勿使用hstore。
你想通过通配符表达式中的键进行搜索吗？请勿使用hstore。
你想做复杂的连接/汇总/报告吗？请勿使用hstore。
你会更新单个密钥的值吗？请勿使用hstore。
在id下有多个同名的密钥？不能使用hstore。

那么hstore有什么用？那么，如果您希望为外部应用程序保存键/值对，并且您始终希望检索所有键/值并始终将数据保存为块（即，它从未编辑过）到位）。同时，您希望能够灵活地搜索这些数据 - albiet非常简单 - 而不是像XML或JSON那样存储它。在这种情况下，由于键/值对的数量很小，所以节省空间是因为您将几个元组压缩到一个hstore。

认为这是你的表：

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

来源

2012-07-04 05:05:26

我认为设计是标准化很差。尝试更多的东西是这样的：

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中的数组，或者您可能会使用单独的表格更好。

来源

2013-07-10 15:33:04 kgrittn

PostgreSQL的hstore键/值VS传统SQL性能

回答

相关问题