NoSQL 開發人員指南

如果您一直在關注後端開發和大數據的趨勢，您可能已經注意到近年來NoSQL資料庫的熱門話題。有些人受到這種資料庫方法的啟發，而有些人則認為其中隱藏著某種技巧：其中的資料模型與通常的關聯式資料庫不一樣，應用程式介面不尋常，而且應用程式常常難以理解。 在這篇文章中，我將告訴您為什麼首先創建它們，這些 NoSQL 資料庫，它們解決了什麼問題以及為什麼突然需要這麼多不同的資料庫。如果您是 NoSQL 新手，您可能會對本文的最後部分特別感興趣，其中列出了我認為值得首先探索的 NoSQL 資料庫類型，以全面了解該領域。

為什麼我們突然需要一個新的資料庫？

你可能會疑惑地問：關係資料庫出了什麼問題？關鍵是他們多年來工作得很好，但現在出現了一個他們無法處理的問題。據預測，到 2018 年，人類每秒將產生 50,000 GB 的數據。這是一個巨大的數據量！它的儲存和處理提出了嚴峻的工程挑戰。更糟的是，這個數量還在不斷增加。事實證明，關係資料庫不太適合處理大量資料。它們被設計為在單一機器上運行，如果您想處理更多請求，那麼唯一的選擇就是購買具有更多 RAM 和更強大處理器的電腦。不幸的是，一台機器可以處理的查詢數量是有限的，對於跨多台機器的分散式工作，我們需要不同的資料庫技術。當然，有些讀者看到這裡會笑，說在關聯式資料庫的情況下，有兩種廣泛使用的多機使用方法：複製和分片。確實如此，但這些方法不足以應付我們的任務。 讀取複製是一種將每個資料庫更新傳播到只能處理讀取請求的其他電腦的技術。在這種情況下，所有變更都由一台稱為主節點的伺服器執行，而其他伺服器（稱為唯讀副本）僅維護資料的副本。使用者可以從任何機器讀取數據，但只能透過主節點更改數據。這是一種方便且非常流行的方法，但它只能讓您處理更多的讀取請求，並不能以任何方式解決處理所需資料量的問題。 分片是另一種流行的方法，它使用關聯式資料庫的多個實例。它們中的每一個都處理一部分資料的寫入和讀取操作。如果資料庫儲存客戶的信息，例如採用分片的方式，一台機器可以處理以A開頭的客戶的所有請求，另一台機器可以儲存以B開頭的客戶的所有數據，以此類推。 儘管分片允許您記錄更多數據，但管理這樣的資料庫確實是一場噩夢：您必須跨機器對齊數據並根據需要在兩個方向上擴展叢集。雖然理論上看起來很簡單，但要做好卻相當具有挑戰性。

關係資料庫可以改進嗎？

我認為您已經開始相信關聯式資料庫並不是最適合現代世界產生的資料量。儘管如此，您可能仍然想知道為什麼還沒有人創建一個可以跨多台機器高效運行的「更好」的關係資料庫。看起來這個技術根本還沒開發出來，分散式關聯式資料庫很快就會出現。 唉，這不會發生。這在數學上是不可能的，而且對此無能為力。 要理解為什麼會這樣，您需要看看所謂的 CAP 定理（又稱布魯爾定理）。它於 1999 年被證明，它指出運行在多台機器上的分散式資料庫可以具有以下三個屬性： 一致性-任何讀取操作都會傳回最後一個相應寫入操作的結果。如果系統是一致的，寫入新資料後，就不可能讀取舊的、已經被覆蓋的資料。 可用性（Availability）－分散式系統可以隨時為傳入的請求提供服務並傳回無錯誤的回應。 分區容錯性－即使某些伺服器暫時無法相互通信，資料庫也會繼續回應讀寫請求。這種臨時故障稱為網路連線故障，可能由多種因素引起，從伺服器速度慢導致的實體網路問題到網路設備的物理損壞。所有這些屬性當然都很方便，我們真的希望有一個資料庫將它們結合起來。任何理智的開發人員都不會願意在沒有得到任何回報的情況下放棄可訪問性等功能。不幸的是，CAP 定理也指出，所有三個屬性不可能同時成立。 要認識到這一點可能並不容易，但這是可能的。首先，如果我們需要一個分散式資料庫，它必須是「容斷連接」的。這甚至沒有討論。斷開連線時常發生，儘管如此，我們的資料庫仍必須正常運作。現在我們來理解為什麼我們不能同時實現一致性和可用性。想像一下，我們有一個簡單的資料庫運行在兩台機器上：A 和 B。任何用戶都可以向其中一台機器寫入數據，然後將數據複製到另一台機器上。 現在想像一下，這些機器暫時無法相互通信，機器 B 無法向機器 A 發送資料或從機器 A 接收資料。如果在這段時間內機器B收到客戶端的讀取請求，它有兩種選擇：

1. 取回本地數據，即使它不是最新的。在這種情況下，優先考慮可用性（至少會傳回一些數據，甚至是過時的數據）。
2. 返回錯誤。在這種情況下，一致性是首選：客戶端不會收到過時的數據，但也不會收到任何數據。

關聯式資料庫力求同時體現「一致性」和「可用性」的屬性，因此無法在分散式環境中運作。試圖在分散式系統中實現關聯式資料庫的所有功能要么不現實，要么根本不可行。另一方面，NoSQL 資料庫主要強調可擴展性和效能。它們通常缺乏連接和事務等「基本」功能，而且資料模型完全不同，甚至可能在某種程度上受到限制。所有這些使得儲存比以往更多的資料和處理更多的查詢成為可能。

NoSQL資料庫如何平衡一致性和可用性？

在您看來，如果您選擇 NoSQL 資料庫，您總是會收到一些過時的數據，或者在發生任何故障時收到錯誤。在實踐中，可用性和一致性絕不是唯一可用的選擇。有多種選項可供您選擇。關聯式資料庫沒有這些選項，但 NoSQL 允許您以類似的方式控制查詢執行。無論如何，它們允許您在 NoSQL 資料庫中執行寫入或讀取操作時設定兩個參數： W -執行寫入作業時叢集中必須有多少台機器確認儲存資料。寫入資料的機器數量越多，下次讀取操作時讀取最新資料就越容易，但所需時間也越長。 R – 您想從多少台機器讀取資料。在分散式系統中，將資料分發到叢集中的所有機器可能需要一些時間，因此某些伺服器將擁有最新的數據，而其他伺服器將滯後。讀取資料的機器越多，讀取到目前資料的機會就越大。讓我們來看一個實際的例子。如果您的叢集中有五台計算機，並且您決定僅向其中一台計算機寫入數據，然後從一台隨機選擇的計算機中讀取數據，則您有 80% 的機會讀取過時的數據。另一方面，這將使用最少的資源。因此，如果遺留資料適合您，那麼這並不是一個糟糕的選擇。在這種情況下，參數W和R等於1。 另一方面，如果將數據寫入 NoSQL 資料庫中的所有五台機器，則可以從任何機器讀取數據，並保證每次都能獲取最新數據。在大量計算機上執行相同的操作將花費更長的時間，但如果最新數據對您很重要，那麼您可以選擇此選項。在這種情況下，W = R = 5。資料庫一致性所需的最小讀寫次數是多少？這是一個簡單的公式：R + W ≥ N + 1，其中 N 是叢集中機器的數量。這意味著，對於五台伺服器，您可以選擇R = 2 和W = 4，或者R = 3 和W = 3，或者R = 4 和W = 2。在這種情況下，資料傳輸到哪台機器並不重要寫入後，讀取將始終從至少一台具有最新資料的機器上完成。 其他資料庫（例如 DynamoDB）具有不同的限制，並且僅允許一致寫入。每條資料都儲存在三台伺服器上，當有任何資料寫入時，就會寫入三台機器中的兩台。但在讀取資料時，您可以選擇以下兩個選項之一：

1. 嚴格一致讀取，從三台機器中的兩台讀取數據，並始終返回最後寫入的數據。
2. 最終一致讀取，其中隨機選擇一台機器來讀取資料。但是，這可能會暫時傳回過時的資料。

為什麼有這麼多 NoSQL 資料庫？

如果您關注軟體開發領域的最新新聞，您可能聽說過許多不同的 NoSQL 資料庫，例如 MongoDB、DynamoDB、Cassandra、Redis 等。您可能想知道：為什麼我們需要這麼多不同的 NoSQL 資料庫？原因很簡單：不同的 NoSQL 資料庫旨在解決不同的問題。這就是競爭資料庫數量如此之多的原因。NoSQL 資料庫分為四大類：

面向文件的資料庫

這些資料庫提供了儲存複雜巢狀文件的能力，而大多數關係型資料庫僅支援一維行。此功能在許多情況下都很有用，例如，當需要在系統中儲存具有多個位址的使用者資訊時。當使用面向文件的資料庫時，在這種情況下，您可以簡單地儲存包含地址數組的複雜對象，而在關係資料庫中，您必須建立兩個表：一個用於使用者信息，另一個用於地址。面向文件的資料庫彌補了物件模型和資料模型之間的差距。一些關係型資料庫，例如PostgreSQL，現在也支援以文件為導向的存儲，但大多數關係型資料庫仍然缺乏這種能力。

鍵/值資料庫

鍵/值資料庫通常實作最簡單的 NoSQL 模型。本質上，它們為您提供了一個分散式哈希表，允許您將資料寫入給定的鍵並使用它讀回。鍵/值資料庫具有高度可擴展性，且延遲顯著低於其他資料庫。

圖資料庫

許多主題領域，例如社交網絡或有關電影和演員的信息，都可以用圖表表示。儘管可以使用關聯式資料庫來表示圖，但這很困難且不方便。如果需要圖數據，最好使用專門的圖資料庫，它可以將圖的資訊儲存在分散式叢集中，從而可以在圖上有效率地實現演算法。

列式資料庫

列式資料庫和其他類型的資料庫之間的主要區別在於資料在磁碟上儲存的方式。關係資料庫為每個表建立一個文件，並按順序儲存所有行的值。列式資料庫為表格中的每一列建立一個檔案。這種結構可讓您聚合資料並更有效地執行某些查詢，但您必須確保資料符合此類資料庫的限制。

您應該選擇哪個資料庫？

選擇資料庫通常是一個令人沮喪的問題，而且有這麼多可用的選項，這似乎是一項艱鉅的任務。好消息是沒有必要只選一個。您可以使用另一種稱為微服務的現代模式：將應用程式分解為一組獨立的服務，而不是創建實現所有功能並可以存取所有系統資料的單一整體應用程式。每個服務解決自己的狹隘問題，並且只使用自己的資料庫，最適合解決這個問題。

你該如何學習這一切？

擁有如此多的資料庫，學習所有資料庫似乎是一項不可能的任務。好消息：您不必這樣做。NoSQL 資料庫只有幾種基本類型，如果您了解它們的工作原理，其他資料庫就會更容易理解。此外，某些 NoSQL 資料庫的使用頻率比其他資料庫高得多，因此最好將精力集中在最受歡迎的解決方案上。以下是我認為您應該查看的最常用 NoSQL 資料庫的清單：

1. MongoDB。可能是市場上最受歡迎的 NoSQL 資料庫。如果一家公司不使用關聯式資料庫作為其主要資料存儲，它可能會使用 MongoDB。這是一個靈活的文檔存儲，具有一套很好的工具。在其職業生涯早期，MongoDB因在某些情況下丟失資料而名聲不佳，但從那時起它的穩定性和可靠性有了很大的提高。如果您想了解更多信息，請查看此MongoDB 課程。


2. 動態資料庫。如果您使用 Amazon Web Services (AWS)，您最好了解更多有關 DynamoDB 的資訊。它是一個極其可靠、可擴展、低延遲的資料庫，具有豐富的功能集並與許多其他 AWS 服務整合。最好的部分是您不必自己部署它。只需點擊幾下滑鼠即可設定可處理數千個查詢的可擴充 DynamoDB 叢集。如果您對此感興趣，可以看看這個課程。


3. Neo4j。最常見的圖資料庫。這是一個可擴展且穩定的解決方案，適合想要使用圖形資料模型的人。如果您想了解更多信息，請從本課程開始。


4. 雷迪斯。雖然這裡描述的其他資料庫用於儲存核心應用程式數據，但 Redis 主要用於實現快取和儲存輔助數據。在許多情況下，上述資料庫之一與 Redis 一起使用。要了解更多信息，請查看本課程。

2018 年 NoSQL

NoSQL 資料庫是一個廣闊且快速發展的領域。它們允許您儲存和處理以前難以想像的資料量，但這是有代價的。這些資料庫沒有您熟悉的關係資料庫中的許多功能，並且很難設定自己來使用它們。但是，一旦您掌握了它們，您就可以建立可擴展的分散式資料庫，該資料庫可以處理數量驚人的讀寫請求，隨著生成的資料量越來越大，這一點變得極為重要。 原文： https: //simpleprogrammer.com/guide-nosql-software-developers/