爲什麼關係數據庫存在可伸縮性問題？

接下來我在網上閱讀了一些文章，指出關係數據庫存在擴展問題，在大數據方面不好用。特別是在數據較大的雲計算中。但我無法找到很好的理由，爲什麼它不能通過Google搜索來擴展。當涉及到可伸縮性時，您能否向我解釋關係數據庫的侷限性？爲什麼關係數據庫存在可伸縮性問題？

謝謝。

來源

2012-08-31 lahiru madhumal

定義「不可擴展」。大量的Fish和Stack Overflow使用關係型數據庫，每天都會有數百萬次點擊。 – Oded

我的觀點與上述相同，許多人認爲關係數據庫不能擴展的人是不知道如何有效使用它們的人。 – Oded

@Oded是的。我看到你有一個點。像堆棧溢出這樣的站點每天可以獲得數百萬次點擊，並且清晰的關係數據庫能夠處理它。但我試圖澄清自己，可能這裏的問題是效率或可能是成本等......這就是我想知道的。我只是想保持開放的態度;） –

關係數據庫根據ACID屬性提供可靠的成熟服務。我們獲得事務處理，有效的日誌記錄以啓用恢復等。這些是關係數據庫的核心服務，以及他們擅長的。它們很難定製，並且可能被視爲瓶頸，特別是如果您在給定的應用程序中不需要它們（例如，爲重要性低的網站內容提供服務;例如，在這種情況下，廣泛使用的MySQL不提供使用默認存儲引擎進行事務處理，因此不滿足ACID）。許多「大數據」問題不需要這些嚴格的限制，例如網絡分析，網絡搜索或處理移動對象軌跡，因爲它們已經包含了不確定性。

當達到給定的計算機（內存，CPU，磁盤：數據太大，或數據處理過於複雜和昂貴）的限制時，分發服務是一個好主意。許多關係數據庫和NoSQL數據庫提供分佈式存儲。然而，在這種情況下，ACID難以滿足：CAP theorem的狀態有些類似，因此無法同時實現可用性，一致性和分區容錯。如果我們放棄ACID（例如滿足BASE），可擴展性可能會增加。請參閱this後，例如。根據CAP對存儲方法進行分類。另一個瓶頸可能是使用SQL操作的靈活和聰明的類型化關係模型本身：在很多情況下，操作更簡單的簡單模型就足夠和更高效（就像無類型的鍵值存儲）。常見的逐行物理存儲模型也可能是有限的：例如，它對於數據壓縮並不是最佳的。

然而，由於關係數據庫的技術已經成熟，經過深入研究並廣泛存在，但是存在快速且可擴展的ACID兼容關係數據庫，包括像VoltDB這樣的新數據庫。我們必須爲給定問題選擇適當的解決方案。

來源

2012-09-03 09:25:36 csaba

「這些不能關閉」。這是一個公然的謊言。 DB2允許關閉日誌（記錄）（如果其他任何大型狗在其產品中缺乏相同的功能，我會感到驚訝）。並猜測，如果你這樣做，你的更新程序可能會運行兩倍的速度。當然，您付出的代價是在更新運行之前進行備份，以及程序失敗時需要恢復的時間。當然，這通常沒有完成，但要說它「**不能**」只是表現出無知而不是知識。 –

是的，「不能」在這裏可能太強大了。我不知道所有的數據庫;但是，例如，使用Oracle nologging子句只會減小日誌大小，但不會將其關閉。事務處理和寫入撤銷信息明確無法關閉，或者如果關閉，數據庫不再符合ACID標準。我錯了嗎？還有一個瓶頸：數據模型和SQL。靈活的模型，聰明的算法;在很多情況下，操作更簡單的簡單模型就足夠且更高效（就像無類型的鍵值存儲）。 – csaba

舉一個最簡單的例子：用生成的ID插入一行。由於表中的ID必須是唯一的，因此數據庫必須以某種方式鎖定某種持久性計數器，以便其他INSERT不使用相同的值。所以你有兩種選擇：要麼只允許一個實例寫數據，要麼有分佈式鎖。這兩種解決方案都是一個重要的瓶頸 - 並且是最簡單的例子！

來源

2012-08-31 12:07:15

有趣的[閱讀]（http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram）關於Instagram如何處理ID生成問題 – Kermit

@Tomasz，...或者只是使用不同的設置用於不同實例的標識符（例如具有不同的前綴代碼或不同範圍的值）。這在關係數據庫中確實不是一個難題！ – sqlvogel

@Tomasz Nurkiewicz。我只想知道NoSQL如何處理這個問題。它的數據模型能夠做到這一點？ – nathan

有一點我認爲人們並不認爲解析SQL有很大的開銷。

這是之一準備好的語句的原因是如此有用。但是，在大多數PHP應用程序的CGI風格的應用程序（運行時間短，許多實例）中，準備好的語句仍然需要解析一次。

通常數據庫服務器本身實際上足夠快，只是在SQL解析中有開銷。 Yoshinori Matsunobu有一個精彩的article關於實現handlerSocket，MySQL + InnoDB的noSQL連接器，據稱每秒鐘可以實現主鍵查找750,000個查詢，這比他爲memcached指出的每秒約420,000個查詢要好。

來源

2012-08-31 12:19:08

想象兩種不同的十字路口。

一個有交通燈或警察調節交通，十字路口的運動速度有限，有一個看門狗準確地註冊了什麼時候準確地在十字路口駕駛什麼車，以及它發生了什麼方向。

另一方面沒有這一點，也沒有人以任何速度到達十字路口，只是潛入並希望儘快通過。

前者是任何傳統的數據庫引擎。十字路口就是數據本身。汽車是想要訪問數據的交易。交通信號燈或警務人員是DBMS。看門狗保存日誌和日誌。

後者是NOACID類型的引擎。

兩者都有一個飽和點，此時到達的汽車被迫開始在入口點排隊。兩者都有最大的吞吐量。對於前一種類型的十字路口，這個門檻值較低，原因應該是顯而易見的。

然而，前一種十字路口的優點也應該是顯而易見的。減少事故發生的機會。在第二種類型的十字路口，只有當交通密度遠低於十字路口的理論最大通過量時，纔可能發生事故。在翻譯成數據管理引擎時，它轉化爲保證一致和一致的結果，只有前一種交叉路口（傳統數據庫引擎，無論是關係型還是網絡型或分層式）才能提供。

該比喻可以進一步延伸。想象一下，如果事故發生會發生什麼。在第二種類型的十字路口，主要擔心的可能是儘可能快地清理道路，因此交通可以恢復，並且在完成後，還有什麼信息可以調查誰造成了這起事故以及如何？一點都沒有。它不會被知道。十字路口正在等待下一次事故的發生。在受管制的十字路口，有警察調查交通情況，看到發生了什麼情況並可以作證。有記錄說明哪輛車準確地在什麼時間進入，準確地在哪個入口點以準確的速度進入，有很多材料可供檢查以確定事故的根本原因。但當然沒有一個是免費的。

足夠豐富的解釋？

來源

2012-09-02 23:09:30

在不受管制的道路上，您只需增加道路寬度即可處理更多交通。在規定的道路上，你必須得到一個新的警察，新的交通燈，攝像頭e.t.c ......而不是複雜的部分：兩名警察和交通燈必須協調工作。 – joshua

+1多彩說明 – FRoZeN

爲什麼關係數據庫存在可伸縮性問題？

回答

相關問題