鍵/值Postgres SQL表性能

Question

我目前正在構建一個Rails應用程序，其中有一個「文檔」數據表，用於存儲對S3服務器上生活的pdf的引用。這些文件可能有100種不同的類型。每種類型最多可以有20個屬性或元信息。

我的兩難困境是，我是否爲每種文檔類型製作了100個關係表，或者只是通過引用doc_id創建一個鍵/值數據表。

我的直覺告訴我要找到靈活性的關鍵/價值，以便隨着時間的推移搜索和支持越來越多的文檔類型，而無需創建新的遷移。但是，我知道這種技術存在缺陷。我當然首先關心的是桌子的大小。鍵/值表可能以數百萬行結束。

另一方面，擁有100個屬性表將是全文搜索情況下查詢的惡夢。

因此，最重要的是，通過使用鍵/值，在具有潛在數百萬行的3列Postgres表上執行性能縮放問題？另外關於價值領域的加入呢？

這些數據幾乎不會改變。所以這將是90％的讀數。

Answer 1

考慮帶有hstore列的單個表。這是一個PostgreSQL數據類型，用於存儲鍵/值對。

http://www.postgresql.org/docs/9.1/static/hstore.html

也有多個Ruby寶石是添加hstore到ActiveRecord的支持。這裏是我寫的一個：https://github.com/JackC/surus你也可以搜索紅寶石約十幾個替代品。