我有一個關係數據庫的應用程序需要改變，以保持更多的數據。我的問題是隻有2個表將存儲更多的數據（高達數十億條），並且一個表通過fk「鏈接」到其他表。我可以放棄這些表格的關係模型。 我想保持數據庫的其餘部分不變，只更改這兩個表。我也在這些表上做了很多的查詢 - 從簡單的選擇到分組和子查詢 - 在那裏出現更多的問題。SQL NOSQL混合可能與否？
我與NoSQL的經驗是有限的，所以我要問哪一個（如果有的話），它的兄弟姐妹的適合我的需要： - 龐大的數據 - 複雜的查詢 - 與SQL數據庫的集成。這不像前兩個那麼重要，如果它值得的話，我可以將我的整個數據庫遷移到相當的數據庫。
謝謝
關係數據庫和NoSQL方法都可以處理有數十億數據點的數據。利用所提供的信息，很難做出有意義的具體建議。這將有助於更多地瞭解您對數據的處理方式，您的硬件和網絡拓撲結構等選項。
我假設您目前正在使用關係數據庫，您可能已經查看分區或以其他方式構建較大的表，以便查詢性能令人滿意。這個活動本身可以是不平凡的，但恕我直言，一個優化的數據庫設計與優化的SQL可以採取很長的路要走，因爲有明確的需要探索替代方案。但是，如果您的數據使用看起來像寫一次，經常閱讀，加入依賴關係是可管理的，並且您需要對數據集執行一些聚合，那麼您可能會開始尋找其他方法，如Hadoop或MongoDB - 然而，這些選擇在性能，功能，平臺要求，延遲等方面都會帶來折衷。在查詢級別上關於NoSQL存儲庫和SQL數據庫之間的集成的特定問題可能無法實現，而這兩者之間沒有數據的重複。例如，MongoDB不喜歡連接（http://stackoverflow.com/questions/4067197/mongodb-and-joins），所以你必須設計你的持久性模型，這可能涉及到數據的重複。
我試圖做的一點是 - 確定「正確」的方法將取決於您的具體目標和約束。
目前該應用程序正在MySQL上運行。數據庫位於單個節點上，但最多可以有3臺機器。我正在運行的查詢是複雜的，並且可能讓他們涉及表中的所有行（對於大集團來說）。根據我的經驗，MySQL無法在合理的時間內處理這種操作（每個查詢少於1分鐘），這就是我尋找替代品的原因。 – qtm
大部分通常歸類爲「NoSQL」的技術不是彼此兄弟姐妹，而是兄弟姐妹，而不是SQL數據庫的兄弟姐妹。 – Philipp