[[419550]]

你需要集群數據庫嗎?

集群數據庫與單節點數據庫相比有多個優點，但費用和復雜性更高。除此之外，集群數據庫還有更高的可用性、更高的吞吐量，在一些情況下還有更低的延遲。

對于每個節點都有整個數據庫副本的集群而言，你可以獲得更高的冗余性和更高的可用性。視策略而定，讀取操作可能只需要一個節點，否則集群中的一組節點可能需要就返回值達成一致。

使用有多個節點的集群可以讓數據庫使用更多的CPU，從而增加吞吐量，并提高事務率。使用允許最近節點返回值的讀取策略，讀取延遲通常會降低。另一方面，必須等待所有節點提交的寫入或事務策略，有時會增加寫入延遲。

使用共識組有助于縮短延遲。如果你有一個三節點集群，一個節點負載過大，另兩個節點就可以批準共識事務，并在第三個節點可用時更新該節點。

分片是一種通過劃分數據庫來處理更多數據的方法。手動分片可能費時又麻煩，許多數據庫都有自動分片功能。

你需要分布式數據庫嗎?

集群不是擴展數據庫的終極方法，不過是第一步。下一步是分布式數據庫，這通常意味著在多個區域有集群。一些數據庫允許分布式只讀副本和主讀寫實例或集群。其他數據庫允許分布式讀寫實例或集群，并具有同步機制。

分布式數據庫常常可以為遠程用戶提供更低的延遲和更高的吞吐量。東京的用戶訪問巴塞羅那的服務器可能會有260 毫秒的延遲，但如果日本有數據庫副本，他們的平均讀取延遲可能只有10毫秒。這對寫入和事務的影響取決于數據庫的一致性要求以及遠程集群是如何配置的。

早期的分布式數據庫是具有最終一致性的NoSQL數據庫。最終一致性意味著不能保證在遠程位置寫入后讀取返回最新信息，但會隨著時間而更新。最終一致性放寬了寫入和事務完成的要求，因而降低了延遲。

最近幾種分布式數據庫在數據結構、共識組和時間同步的幫助下實現了強一致性。這方面的例子包括Google Cloud Spanner和CockroachDB。

你的數據庫預算是多少?

雖然大多數數據庫都有免費的"社區"或"開發/測試"版本，但除了在線社區論壇外，它們可能缺乏支持。社區版和開源版也可能缺乏商業版本提供的一些性能優化。如果貴公司依賴數據庫，應在許可證和支持上投入成本。

如果你在云端運行數據庫，至少需要為云資源付費。如果是商業數據庫，你還需要數據庫許可證，這可能是來自供應商的長期許可證，也可能是通過云提供商購買的按需付費許可證。

附：CAP 定理

CAP定理(Brewer 等人于1998 年提出)聲稱，任何網絡共享數據系統最多具有以下三個理想屬性中的兩個：

C：一致性，相當于擁有一個最新的數據副本;

A：該數據的可用性，用于更新;

P：對網絡分區的容忍度。

數據庫的理想屬性取決于它所服務的應用的需求。如果該應用顯示目錄，那么數據庫的讀取速度和延遲很重要，文檔數據庫可能很理想，但關系數據庫和寬列數據庫也適用。如果該應用處理金融交易，那么數據庫的ACID屬性(原子性、一致性、隔離性和持久性)就很重要，關系數據庫可能很理想。

這則三分之二的公式被證明過于簡單化。在現代分布式數據庫架構中，節點故障和網絡分區由共享組使用Paxos或Raft算法來緩解。實際上，當一個節點退出集群后，只要它有仲裁機制，集群就會繼續工作。此外，分區在私有網絡內部很少見，比如在主要云提供商處的私有網絡：它們在數據中心之間使用冗余光纖，并不通過公共互聯網傳輸內部流量。 

這意味著，雖然從嚴格上來說沒有數據庫可以繞過CAP定理，但實際上好的云數據庫擁有超過五個九(99.999%)的可用性，這些數據庫可以繞過CAP定理，同時擁有一致性和可用性。

作者：Martin Heller現為《InfoWorld》網站的特約編輯兼評論員，此前擔任Web和Windows編程顧問。從1986年至2010年，Heller一直從事數據庫、軟件和網站的開發工作。近期，他出任Alpha Software的技術和教育副總裁，還是Tubifi的主席兼首席執行官。

原文網址：https://www.infoworld.com/article/3627792/how-to-choose-a-cloud-database.html