MariaDB 列儲存適用於數據倉庫
我們希望建立一個數據倉庫來在整個組織中分發有效資訊（報告）並獲得對我們數據的一些見解（分析）。經過一些研究，我們發現MariaDB 使用列儲存是一個有吸引力的選擇。但是，我們都是數據倉庫領域的非專業人士。這就是為什麼我想听聽一些關於適用性和所需硬體的意見。
來自源系統（Oracle、IBM DB2、MariaDBs）的數據總計達 1 TB（包括 PK/FK 和索引），包含 36 個月的數據歷史記錄。數據由具有主要整數鍵的表、整數/雙精度組合 (65%)、大多數較短的 VARCAHR (30%) 和 5% 的 GEO 數據組成。數據來自 15-20 個不同權重的不同主題。這意味著有些人在數據倉庫中製造了 50GB 一些 5GB。並非所有主題（表）都可以並且將被連接，因為根本沒有公共鍵。對於上報案例，不同的topic大多會被隔離查詢（最多加入5個topic）。很少使用查詢所有時間點（月）。我認為有理由假設將查詢長達 17 個月的數據來進行產品性能比較。新數據將在批處理作業中在一夜之間寫入。MariaDB 數據庫伺服器計劃在 8 PHY 上執行。具有 1,25 TB SSD 儲存和 64GB RAM 的核心機器。總的來說，我們預計大約有 50 人查詢數據，其中 45 人使用匯總報告表，5 人是重度分析使用者——加入表格、分組、將內容導出到其他 ML 工具。複雜的字元串搜尋不在我們的數據倉庫範圍內。我們不希望 45 個人同時查詢數據，但最多可以有 20 個並髮使用者。我們不希望基本報告查詢需要 10 秒或更長時間。5 個分析使用者的更複雜查詢可能需要更長的時間。分組，將內容導出到其他 ML 工具。複雜的字元串搜尋不在我們的數據倉庫範圍內。我們不希望 45 個人同時查詢數據，但最多可以有 20 個並髮使用者。我們不希望基本報告查詢需要 10 秒或更長時間。5 個分析使用者的更複雜查詢可能需要更長的時間。分組，將內容導出到其他 ML 工具。複雜的字元串搜尋不在我們的數據倉庫範圍內。我們不希望 45 個人同時查詢數據，但最多可以有 20 個並髮使用者。我們不希望基本報告查詢需要 10 秒或更長時間。5 個分析使用者的更複雜查詢可能需要更長的時間。
我們有一些考慮，我很樂意聽取您的意見：
- 商業供應商是否提供了比 MariaDB 列儲存更好的解決方案，我們應該考慮這種情況？或者是否可以使用開源 RDBMS 來做到這一點？
- 擁有一台更強大的機器或 2-3 台較弱的機器更好地平衡負載是否有意義？那麼他們是否需要所有數據的完整副本？（所以 1,25 TB SSD x 3 工人？）。
- 沒有一個大 SSD，而是五個（每個 256 GB）較小的 SSD 來增加 IO 是否有意義？（將相似表的主題保存在同一個 SSD 上，因為它們會更頻繁地連接。）
- 擁有 64GB 或 RAM 是否有意義，還是需要更多？需要 RAM 的決定因素是什麼？
如您所見，我們缺乏經驗會導致所需硬體的一些基本問題。是否有可能根據所提供的資訊就可能的表現得出結論？如果不是，需要什麼樣的資訊？
這就是我對沒有列儲存的 MySQL/MariaDB所說的：
不好：“總計 1 TB”與“1.25 TB 的 SSD 儲存”。作為經驗法則，您應該有一半的磁碟空閒用於維護和增長。至少，應該有足夠的空間容納最大表的額外副本——數據+索引。這允許任何
ALTER執行而不會耗盡磁碟空間。讓我們討論最大的表。請向我們展示
SHOW CREATE TABLE主要查詢——插入、更新和刪除（如果需要）以及選擇。有了它，我們可以討論縮小磁碟佔用空間、索引和分區（或不分區）。這是我對 DW 的討論：http: //mysql.rjweb.org/doc.php/datawarehouse另請參閱其指向摘要表討論的連結。
請詳細說明“根本沒有通用鍵”。
使用“隔夜批量載入”，我強烈建議：
- 載入到臨時表中；
- 規範化（另一個連結中的提示）；
- 從臨時表中擴充匯總表；
- 將數據複製到主 Fact 表中；
- 刪除臨時表。
如果您正在“清除”“舊”數據，那麼
PARTITION用DELETE快速的DROP PARTITION. 更多細節：http: //mysql.rjweb.org/doc.php/partitionmaint您的其他數字規格並不可怕，但可能有問題。需要進入實際的解析查詢才能看到。
注意：如果您的團隊增長並且系統無法提供足夠的並發查詢，您可以建構一個 Replication 系統，其中 Primary 複製到只讀副本。每個 Replica 可以獨立處理幾個大的分析查詢。
RAM 的數量將由表大小、查詢複雜性等決定。更多的 ram 更好——但有一個無法預測的“收益遞減”點。從你的 64GB 開始，嘗試優化“最差查詢”；然後決定是否添加Replicas。
SSD 的佈局並不重要。（除了需要更多空間。）對於多個小型驅動器，您可以使用 RAID 條帶化和/或奇偶校驗。我想要一個帶有電池支持的寫入記憶體的 raid 控制器（成本高，很好，但可能有點矯枉過正，因為你只每晚寫一次，而且可能不在乎它是否需要 2 小時而不是 1 小時？）這將允許 `RAID -5 部署 4x500g 或 7x250G 驅動器，任何一種都可以有效地為您提供 1.5TB 加上奇偶校驗。
（幾年前，我做了一個類似的項目（0.5TB 數據；HHD；RAID-5；每小時載入；大約 7 分鐘內載入了 7 個匯總表。實現了 Primary-Replica，但在我的情況下是多餘的。匯總表變成了小時- 長查詢變成一分鐘長的查詢；YMMV。）
列儲存
列儲存將典型數據縮小 10 倍。（我懷疑 InnoDB 上設計良好的模式不能縮小那麼多。）一些性能特徵來自這種壓縮；一些來自並行操作。
你的 1TB 是從哪裡來的？這是否意味著您只需要 0.1TB 的磁碟來儲存列儲存？或者那個 InnoDB 需要 10TB？（我上面的討論可能需要相應地調整。）
列儲存非常適合查詢任意列，因為每一列都被索引。但是，當您過濾不止一列時，它會有效地過濾一列，然後（也許）不得不對其他列進行強力過濾。
如果沒有更深入地了解您的查詢，我無法判斷
- 列儲存
- 具有正常索引的 MySQL/MariaDB
- 帶有分區/全文/空間的 MySQL/MariaDB
在沒有 CS 的情況下，CS 的性能可能會優於或低於等效數據庫——具體取決於查詢。