用於存儲大量列的最佳數據庫設計？

Question

情況：我們正在研究一項將數據傳送讀入我們公司數據庫的項目。這些數據傳送可以包含大量的字段。我們將這些字段與某些列匹配。

現在我們有大約120種類型的領域。這些都需要一個專欄。我們需要能夠過濾和排序所有列。

問題是我不確定什麼數據庫設計最適合這個。我正在使用MySQL進行這項工作，但我很樂意提供建議。此刻，我打算製作一張全部120列的表格，因爲這是最自然的做事方式。

選項：我的其他選項是一個存儲鍵和值的元表。或者使用基於文檔的數據庫，因此我可以訪問變量模式並在需要時對其進行縮放。

問題： 什麼是最好的方式來存儲所有這些數據？行數可能高達100k行，我需要一個可以選擇，排序和過濾非常快的存儲。

更新： 有關使用情況的更多信息。 XML提要將從該表中實時生成。我們正在談論每小時100-500個請求，但這種情況會不斷增加。田地不會經常變化，但可能每6個月更換一次。我們也將每天更新數據傳輸。所以檢查項目是否更新，刪除舊的和添加新的。

Answer 1

我正在做一個類似的項目，從網上下載轉儲並將它們加載到數據庫中，將更改合併到主表中並正確調整字典表。

首先，你知道你將要使用的數據。所以有必要提前分析並選擇最佳的表格/列布局。如果您的所有120列都包含文本數據，則單個行將佔用幾個K字節的磁盤空間。在這種情況下，您將希望高度選擇所有查詢，以便使用索引來最小化IO。完全掃描可能需要花費大量時間進行這樣的設計。你沒有提到500/h的請求會有多大，每個請求會提取一行，一小排還是很大一部分（最多到整個表）？

其次，看數據，你可能會勾勒出一個數列，將有一組有限的值。我更喜歡對這樣的列進行以下轉換：

• 設置字典表，爲其設置一個整數PK;
• 從字典PK替換主表的列中的實際值。

轉換由C語言編寫的觸發器完成的，所以雖然它給了我上傳點球，我確實有一些好處：

• 數據庫和主表的總規模下降;
• 數據庫和操作系統緩存經常訪問的數據塊的更好選擇;
• 更好的查詢性能。

第三，儘量按照你會做的提取數據分割。通常情況下，表中只有30-40％的字段通常被所有查詢使用，其餘的60-70％均勻分佈在所有查詢中並部分使用。在這種情況下，我會建議相應地拆分主表：將始終使用的字段提取到單個「主」表中，併爲其餘字段創建另一個字段。實際上，您可以有多個「另一個」，邏輯上將數據分組在不同的表中。

在我的實踐，我們已經有包含客戶詳細信息的表格：名字細節，地址的詳細信息，狀態信息，銀行信息，結算明細，財務細節及一組自定義的意見。所有在這樣的表上的查詢都是昂貴的，因爲它在我們的大多數報告中都使用過（報告通常會執行完整掃描）。將此表分成一組較小的表，並在其上創建一個規則視圖（以使外部應用程序開心），我們設法獲得了令人愉快的性能提升（對不起，不再有數字）。

總結：你知道你將要使用的數據，你知道將被用來訪問數據庫，因此分析和設計的查詢。

Answer 2

在100k行120列是不夠的信息，只有真正給出的指標之一：大小。另一個是交易。你在這裏談論每秒多少個交易？

這是一個每週更新一次的經理，每週一次運行一次報告，還是一個小時一百萬頁的請求？

我通常不需要開始尋找'聰明'的解決方案，直到碰到一個10米的記錄表，或每秒數百個查詢。

哦，而不要使用鍵值對錶。它們在關係數據庫中不是很好，所以堅持正確的類型字段。

我個人建議堅持使用傳統的每列一列的方法，如果測試顯示它不是正確的，則只偏離這一點。

關於檢索，如果插入/更新只是每天發生，那麼我認爲在服務器端進行一些仔細的索引，在生成XML的地方進行良好的緩存應該會減少服務器的數量。例如，您說'我們將每天更新數據傳送'，那麼就不需要每次都查詢數據庫。儘管每小時1000次只有每分鐘17次。這可能歸結爲無。