什麼是存儲面向列的表MongoDB中的數據

我有一個大表，其中列USER_ID，user_feature_1，user_feature_2，...的最佳查詢的最佳方式，user_feature_n什麼是存儲面向列的表MongoDB中的數據

所以每一行對應用戶和他或她的特徵。

我通過將每個列的值作爲一個數組存儲在MongoDB中來存儲此表。

{ 
    'name': 'user_feature_1', 
    'values': [ 
    15, 
    10, 
    ... 
    ] 
}

我使用流星從MongoDB中提取數據，並存儲這種方式有利於對圖形繪製整個列值的快速和容易檢索。

但是，這種存儲方式有一個主要缺點;我無法存儲大於16mb的數組。

有幾個可能的解決方案，但其中非似乎不夠好：

商店使用GridFS的每一列的值。我不確定流星是否支持gridFS，並且它不支持切分數據，也就是說，我可能需要獲得列的前1000個值。
以面向行的格式存儲表。例如。

{ 'USER_ID'：1， 'user_feature_1'：10， 'user_feature_2'：0.9，
.... 'user_feature_n'：42 }

但我認爲這種存儲數據的方式對於查詢特徵列的值是低效的

或者MongoDB根本就不適合，sql是要走的路嗎？但流星不支持SQL

更新1： 我發現這個有趣的文章，其在MongoDB中談到陣列是低效的。 https://www.mongosoup.de/blog-entry/Storing-Large-Lists-In-MongoDB.html

以下的說明是從http://bsonspec.org/spec.html

陣列 - 用於陣列中的文件是與用於鍵的整數值，從0開始並依次繼續正常的BSON文檔。例如，數組['red'，'blue']將被編碼爲文檔{'0'：'red'，'1'：'blue'}。鍵必須按升序編號順序。

這意味着我們可以存儲最多百萬值的文檔中，如果值和鍵是浮動型的（16MB/128位）

來源

2015-09-15 Michael

「看起來不錯」，「我認爲」，...表現不是感情或意見，而是關於基準和配置文件。你的在哪裏？ –

還有一個第三個選項。爲每個用戶，並設有一個單獨的文件：

{ u:"1", f:"user_feature_1", v:10 }, 
{ u:"1", f:"user_feature_2", v:11 }, 
{ u:"1", f:"user_feature_3", v:52 }, 
{ u:"2", f:"user_feature_1", v:4 }, 
{ u:"2", f:"user_feature_2", v:13 }, 
{ u:"2", f:"user_feature_3", v:12 },

你不會有任何文獻增長的問題，你可以不還訪問任何不相關的數據查詢都和「爲特徵量x的所有值」「爲用戶X的所有值」。

來源

2015-09-15 12:20:37 Philipp

每個值都需要至少兩個標識符（user_id和user_feature）。這種方法不會佔用空間嗎？我正在考慮使用mongodb和postgres作流星的可能性，結果發現有些庫支持流星的postgres – Michael

@Michael當然這不是最節省空間的解決方案。總是有一個權衡。 – Philipp

16MB/64bit float = 2,000,000 uncompressed datapoints。什麼樣的圖需要最少200萬分每列 ???相反，嘗試：

的S3服務器
上保存圖像使用Hadoop等一個地圖，減少解決方案（可能是你最好的選擇）
減少數字小整數，如果他們目前浮
計算在飛行中的數據，在客戶端（首選，如果可能的話）
使用壓縮算法中，因此您可以保存一個子集&插值其餘

也就是說，在這個用例中，基於文檔的數據庫將勝過SQL DB，因爲SQL DB將完全按照Philipp的建議進行。無論採用哪種方式，如果客戶端不會因爲糟糕的用戶體驗而將多個16MB文件發送給客戶端，那麼您將因服務器成本而失效:-)。

來源

2015-09-15 14:16:54

繪圖圖形是必需的功能之一，我需要將所有值存儲爲其他用途，例如統計計算。 – Michael

聽起來像你應該去與菲利普建議，如果你需要完美的決議。 –

什麼是存儲面向列的表MongoDB中的數據

回答

相關問題