課堂

6.1 縮寫之戰：BASE vs. 酸 “在化學中，pH 測量水溶液的相對酸度。pH 範圍從 0（強酸性物質）到 14（強鹼性物質）；25°C 的純水的 pH 值為 7，呈中性。 數據工程師用這個比喻來比較數據庫的交易可靠性。” 可能的想法是：pH 值越高，即 數據庫越接近“鹼性”（“BASE”），交易越不可靠。 流行的關係型數據庫，如MySQL，就是在ACID的基礎上出現的。但是在過去的十年裡，所謂的 NoSQL 數據庫，在這個名稱下結合了幾種非常不同類型的數據庫，在沒有

7.1 為什麼需要 我們已經詳細討論了 ACID 的所有屬性、它們的用途和用例。如您所見，並非所有數據庫都提供 ACID 保證，為了更好的性能而犧牲它們。因此，很可能在您的項目中選擇了不提供 ACID 的數據庫，並且您可能需要在應用程序端實現一些必要的 ACID 功能。而且，如果您的系統被設計為微服務或某種其他類型的分佈式應用程序，那麼一個服務中的正常本地事務現在將變成分佈式事務——當然，將失去其 ACID 特性，即使數據庫每個單獨的微服務都是 ACID。 我不想為您提供關於

8.1 交易 ID 它被指定為 XID 或 TxID（如果有區別，請告訴我）。時間戳可以用作 TxID，如果我們想將所有操作恢復到某個時間點，它可以發揮作用。如果時間戳不夠精細，就會出現問題——然後事務可以獲得相同的 ID。 因此，最可靠的選擇是生成唯一的 UUID prod ID。在 Python 中這很容易： >>> import uuid

1.1 NoSQL 數據庫的工作原理 NoSQL 數據庫使用各種數據模型來訪問和操作數據。這些類型的數據庫針對需要低延遲和靈活數據模型的數據密集型應用程序進行了優化。所有這一切都是通過放寬對其他類型數據庫的典型嚴格數據一致性要求來實現的。 考慮一個簡單的書籍數據庫的模式建模示例。 在關係數據庫中，書籍條目通常被分成多個部分（或“規範化”）並存儲在單獨的表中，這些表的關係由主鍵和外鍵約束定義。在此示例中，Books表有ISBN、書名和“ISBN”和“Author”Author-

2.1 NoSQL一詞的出現 最近，“NoSQL”一詞變得非常流行和流行，各種軟件解決方案都在這個標誌下積極開發和推廣。NoSQL 已經成為海量數據、線性可伸縮性、集群、容錯、非關係性的代名詞。然而，很少有人清楚地了解NoSQL存儲是什麼，這個詞是怎麼出現的，它們有什麼共同的特點。讓我們嘗試填補這個空白。 這個詞最有趣的地方在於，儘管它在 90 年代末首次使用，但直到 2009 年年中才以現在使用的形式獲得了真正的意義。最初，這是一個開放的名稱- 由 Carlo Strozz

3.1. 弱酸性 長期以來，數據一致性一直是架構師和開發人員的聖牛。所有關係數據庫都提供了某種程度的隔離，要么通過更新鎖和阻塞讀取，要么通過撤消日誌。隨著海量信息和分佈式系統的出現，很明顯，一方面要為它們確保一組事務性操作，另一方面要獲得高可用性和快速響應時間是不可能的。 此外，即使更新一條記錄也不能保證任何其他用戶會立即看到系統中的更改，因為更改可能發生在例如主節點中，並且副本被異步複製到從節點，另一個用戶可以使用該從節點作品。在這種情況下，他將在一定時間後看到結果。這就是

4.1 說明 Apache Cassandra是一種分佈式數據庫管理系統，屬於 NoSQL 系統類別，旨在為以哈希形式呈現的龐大數據陣列創建高度可擴展且可靠的存儲。 最初，該項目是在 Facebook 內部開發的，並於 2009 年轉移到 Apache 軟件基金會的旗下，該組織繼續開發該項目。部署基於 Cassandra 的工業解決方案，為 Cisco、IBM、Cloudkick、Reddit、Digg、Rackspace、華為、Netflix、Apple、Instagram

5.1 數據分佈 讓我們考慮如何根據集群節點之間的鍵分佈數據。Cassandra 允許您設置數據分發策略。第一個這樣的策略根據 md5 鍵值分配數據 - 隨機分區程序。第二個考慮了密鑰本身的位表示 - 序號標記（字節順序分區程序）。 在大多數情況下，第一種策略具有更多優勢，因為您無需擔心服務器之間數據的均勻分佈等問題。第二種策略在極少數情況下使用，例如，如果需要間隔查詢（範圍掃描）。重要的是要注意，此策略的選擇是在創建集群之前做出的，事實上，如果不完全重新加載數據，就無法更改

1.1 什麼是分片？ 如果你堅持谷歌，原來所謂的分區和所謂的分片之間有一個相當模糊的界限。大家隨便叫什麼就叫什麼。有些人區分水平分區和分片。其他人說分片是某種水平分區。 我沒有找到一個單一的術語標準可以得到創始人的批准和 ISO 的認證。個人內心的信念大概是這樣的：平均劃分就是按照任意的方式“把基數切成塊”。 垂直分區- 按列。例如，有一個巨大的表，其中包含 60 列中的數十億條記錄。我們保留至少 60 個 20 億條記錄的巨型表，而不是保留一個這樣的巨型表——這不是列基，而

如何進行選擇，將一個表中的十億條記錄加入另一個表中的十億條記錄？

3.1 大數據一詞的出現歷史 大數據這個詞出現的時間相對較晚。谷歌趨勢顯示自 2011 年以來該短語的使用開始積極增長： 同時，現在只有懶人不使用這個詞。特別是，營銷人員經常不恰當地使用該術語。那麼大數據究竟是什麼？由於我決定係統地陳述和突出這個問題，因此有必要定義這個概念。 在我的實踐中，我遇到了不同的定義： 大數據是指超過 100GB 的數據（500GB、1TB，任何你喜歡的）。 大數據是無法在 Excel 中處理的數據。 大數據是無法在單台計算機上處理的數據。 甚至這些

4.1 Hadoop 概況 MapReduce 範式由 Google 於 2004 年在其文章MapReduce: Simplified Data Processing on Large Clusters中提出。由於提議的文章包含範例的描述，但缺少實現，雅虎的幾位程序員提議將他們的實現作為 nutch 網絡爬蟲工作的一部分。您可以在 Hadoop 的歷史：從 4 個節點到數據的未來一文中閱讀有關 Hadoop 歷史的更多信息。 最初，Hadoop 主要是一種用於存儲數據和運行