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性能

回答

相關問題