目前我有一個mysql數據庫，並且iam收集的數據一年是5 Terrabyte。我會一直保存我的數據，我不認爲我想很早就刪除一些內容。 我問自己是否應該使用分佈式數據庫，因爲我的數據每年都會增長。而5年後，我將有25 Terrabyte沒有索引。 （剛計算出我每天保存的原始數據）分佈式數據庫使用案例
我有5個表，大多數查詢是連接在多個表上。 而且我需要在特定的時間戳上訪問多行1-2列。
會的分佈式數據庫比只有一個mysql數據庫一個首選數據庫？
Paritioning將是困難的，因爲我所有的表都非常高連接。
我知道它取決於查詢和數據庫表設計，我也可以有一個分佈式的mysql數據庫。 我只想知道什麼時候應該考慮分佈式數據庫。 這是一個用例嗎？或者MySQL可以處理這個大數據集？
編輯：
平均，我將有1500個客戶端每秒寫入數據時，它們會影響所有表。
我需要的只是舊數據集分析。像機器學習和 模式匹配。
你的問題是關於「分佈式」，但我看到更多的問題需要先回答。
「高度索引的5TB」會慢慢爬行。索引是BTree。向索引添加新行意味着在該項所屬的樹中定位塊，然後讀取 - 修改 - 寫入該塊。但...
如果索引AUTO_INCREMENT或TIMESTAMP（或類似的東西），則該塊被修改是「總是」在B樹的「結束」。所以幾乎所有的讀寫操作都是可緩存的。也就是說，更新這樣一個索引的開銷非常低。
如果索引是「隨機的」，例如UUID，GUID，md5等，則更新的塊是很少在緩存中找到。也就是說，爲這一行更新這一個索引可能會花費一對IOP。即使使用SSD，您也可能無法跟上。 （假設你沒有幾個TB的內存）。
如果索引位於連續和隨機（比如某種「名稱」）之間，那麼可能有數千個「熱點」在BTree，這些可能是可緩存的。
底線：如果你不能避免隨機索引，你的項目是註定的。
下一個問題...查詢。如果您需要掃描5TB作爲SELECT，那將需要時間。如果這是數據倉庫類型的應用程序，並且需要（比如說）彙總上個月的數據，那麼構建和維護彙總表將非常重要。此外，這可以避免需要「事實」表上的一些索引，從而可能消除我對索引的關注。
「查看歷史數據」 - 查看單個行？或者只看彙總信息？ （同樣，如果它像DW一樣，很少需要看到舊的數據點。）如果彙總就足夠了，那麼大多數25TB都可以避免。
你有一臺25TB的在線機器嗎？如果沒有，那可能會迫使你擁有多臺機器。但是接下來你會遇到在他們之間運行查詢的複雜性。
5TB從INT = 4個字節等估計出來？如果使用InnoDB，則需要2到3的倍數以獲得實際的佔用空間。此外，如果您將來需要修改表，則此操作可能需要將表複製過來，以便將所需的磁盤空間加倍。你的25TB變得更像100TB的存儲空間。
PARTITIONing已經很少有有效的使用情況，所以我不想討論，直到知道更多。
「分片」（跨機器分裂）可能是你的「分佈式」的意思。對於多個表格，您需要認真思考如何分割數據，以便JOINs將繼續工作。我們可以縮小它的範圍 - 使用更小的數據類型，規範化等等。但是不要「過度規範化」，最終會導致性能下降。 （我們需要查看查詢！）
有許多方向採取多TB分貝。我們確實需要更多關於您的表格和查詢的信息，然後才能更具體。
這真的無法提供一個具體的答案如此廣泛的問題。
一般情況下，我建議只擔心性能，一旦你能證明你有問題;如果您擔心，建立測試平臺，使用代表性數據填充它並查看會發生什麼會好得多。
「MySQL可以處理5到25 TB的數據嗎？」是。不，這取決於。如果 - 正如你所說 - 你沒有索引，你的查詢可能會延遲很長時間才能達到5TB。如果它是5TB /年的高度可索引數據，它可能會很好。
這個問題最常見的解決方案是爲所有「常規」工作保留一個「事務性」數據庫，並使用常規的提取/轉換/加載作業來移動數據和歸檔它。數據倉庫通常具有針對查詢優化的模式，通常完全不同於原始模式。
如果你想保持一切在邏輯上一致，你可以使用sharding和羣集 - 一種即時排序功能 - MySQL的開箱即用功能。
但是，我不會推出我自己的「分佈式數據庫」解決方案。這比你想象的要難得多。
鑑於你的查詢負載，你應該考慮分區表。也可能有其他非常合理的解決方案。 –
你的意思是隻在一臺機器上分區，沒有分佈式分區？ – Khan
它需要更多地瞭解使用情況。重要的是多少個連接，平均您有和查詢多麼沉重，他們使用。如果他們仍然會大量使用從往年的數據;如果查詢通常僅限於一個特定的一年中，如何快速反應，預計等你和服務器/實例的配置也哪個版本的MySQL - 的CPU /內存/如果使用僅適用於MySQL等。可能發生在某個時刻，您將需要每年單獨的實例，並使用聯合引擎從主連接數據庫查詢它們。但是，如果沒有詳細的負載知識，很難說... – JosMac