易燃物匯聚 YouTube 有聲書與書評
七週七數據庫 封面

七週七數據庫

Eric Redmond Jim R.Wilson

4385人在讀
26.6萬字總字數
¥35.4定價

有聲書與視頻解讀 YouTube視頻解讀 9

內容簡介

  如今,我們要面對和使用的數據正在變得越來越龐大和複雜。如果說數據是新的石油。那麼數據庫就是油田、煉油廠、鑽井和油泵。作爲一名現代的軟件開發者,我們需要了解數據管理的新領域,既包括RDBMS,也包括NoSQL。   《七週七數據庫》遵循《七週七語言》的寫作風格和體例,帶領你學習和了解當令最熱門的開源數據庫。在簡單的介紹之後,《七週七數據庫》分章介紹了7種數據庫。這些數據庫分別屬於5種不同的數據庫風格,但每種數據庫都有自己保存數據和看待世界的方式。它們依次是PostgreSQL、Riak、Apache HBase、MongoDB、Apache CouchDB、Neo4J和Redis。《七週七數據庫》將深入每一種數據庫,介紹它們的優勢和不足,以及如何選取一種最符合你的應用需求的數據庫。   《七週七數據庫》適合數據庫架構師、數據庫管理員,以及想要了解和學習各種NoSQL數據庫技術的程序員閱讀。《七週七數據庫》將幫助讀者瞭解、選擇和應用這些數據庫,從而更好地發揮日益增長的大數據的能力。

讀者書評

★★★★★

作爲一名長期曾經深耕後端開發、熟悉Oracle的程序員(做過一年DBA),我對數據庫的認知曾長期侷限於關係型數據庫的“表-行-列”框架。重讀《七週七數據庫》,最大的收穫並非掌握某款數據庫的操作細節,而是跳出技術慣性,理解“不同場景匹配不同數據庫”的核心邏輯——這正是此書對有經驗後端開發者最核心的價值。 書中最讓我共鳴的,是它沒有迴避“數據庫選型的權衡”。作爲Oracle使用者,我們習慣了它在事務一致性、複雜查詢上的強大,但也常爲高併發下的性能瓶頸、海量數據存儲的成本而困擾。而書中對7種數據庫的拆解,恰好對應了這些痛點的解決方案:比如用Redis解決Oracle緩存層不足的問題,用MongoDB簡化非結構化數據的存儲邏輯,用Neo4j處理Oracle中需多表關聯的複雜關係查詢(如社交網絡的好友推薦)。這種“問題-方案”的對應關係,讓我能快速將新數據庫與實際工作場景掛鉤,而非停留在理論層面。 當然,從開發者視角看,本書也有侷限性。一方面,書中部分數據庫(如Apache CouchDB)的市場熱度已不如當年,且缺乏對雲原生數據庫(如AWS Aurora、阿里雲PolarDB)的覆蓋,這需要結合當前技術趨勢補充學習;另一方面,書中對數據庫底層原理(如分佈式一致性算法、存儲引擎優化)的講解較淺,更適合“廣度認知”而非“深度攻堅”。 瑕不掩瑜,這本書的意義在於“打破認知邊界”。它讓我們意識到,傳統數據庫並非“萬能解藥”,在高併發、大數據、多模態數據的場景下,合理搭配NoSQL數據庫,才能構建更高效、更靈活的後端架構。如果你正爲業務中的數據庫瓶頸發愁,或想系統瞭解數據庫生態的多樣性,這本書會是很好的“啓蒙手冊”。

★★★★★

2025年讀完的第二十三本書,讀完這本書一共花了32個小時,一邊讀技術書,一邊思考和做筆記真的特別花時間。作者在這本書中除了介紹普通的關係型數據庫之外,還另外介紹了好幾種NoSQL(not only SQL),但是由於篇幅所限不可能完完全全把所有的數據庫(關係型,非關係型)都介紹上,特別是涉及到AI技術相關的向量數據庫在這本書中都沒有提及。 我認爲對於一本技術書籍而言,不可能做到面面俱到,如果一本書介紹和講解了很多中心主題,而沒有抓住最核心的主題內容和主題內容關係進行講解的話,就是相當於“雖然講了很多,但是什麼都沒有講”。但是這本書很清楚自己的定位,它的主題中心就是廣而不深地講解目前主流的SQL與NoSQL數據庫的特性與專用場景,通過簡單的CRUD進行切入,並同時通過輕量級的代碼與項目講解這類型數據庫的特性。 下面是讀書筆記: 1.PostgrepSQL數據庫是一個典型的來源數據庫,在我看來它跟商業型數據庫對比,在使用與運維上的成本更高,在底層的性能、針對性的場景優化與運維功能的便捷和相關的技術支持更加沒有可比性。但是這種“野路子”開源產品(GNU)也有非常多讓人眼前一亮的優點,例如對於數據庫的功能擴展與模塊的可擴展性,以及某些針對文本搜索功能的快速查詢支持(GIN/傳統倒排索引)。更加讓我震驚的是,PostgreSQL居然支持Cube,這種能存儲多維度的字段,已經都有向量數據庫(AI專用)的雛形。 2.Riak作爲一種NoSQL經典的分佈式的鍵-值(key-value)數據庫什麼都能存,它是一種非常靈活的NoSQL數據庫。其靈活度除了體現在數據存儲的方式,“數據表”與“數據桶”的數據組成形式,還有其底層分佈式架構的的靈活性,我認爲這都是一種非常棒的分佈式設計思路。意想不到的是,連這種NoSQL數據庫都借鑑了分佈式計算框架Mapreduce,這種通過平移計算而不是平移數據的分佈式計算思想,雖然在開發的時候受到實際條件的限制,但是對於提升分佈式計算效率與降低維護成本確實很有用。Riak的數據能分佈在多個計算節點,它使用的“一致性哈希”算法通過把每個節點映射到一個環的相同位置上,實現多個虛擬節點的平衡負載。Riak可以在每個桶或者每個請求的基礎上改變,通過這樣的方法規避CAP(Consistency、Availability、Partition Tolerance,即一致性、可用性和分區容錯性)施加於所有分佈式數據庫上的約束,真的是一種驚爲天人的靈活辦法。 3.CouchDB存儲由鍵-值對組成的JSON文檔,其中,值可取若干類型中的任意一種,包括嵌套任意深度的其他對象。CouchDB查找想要的文檔,主要途徑是增量式映射規約(incremental mapreduce)生成的索引視圖。CouchDB只支持追加的存儲模式,實際上使數據不會損壞,易於複製、備份與恢復。CouchDB沒有事務與鎖的概念。爲了修改已有記錄,必須先將它讀出,_id與_rev一起匹配才能修改,以此保證是拿到最新的文檔版本進行更新。CouchDB跟Riak有個區別是CouchDB能通過創建視圖實現Mapreduce,或者通過視圖實現集合分片(邏輯分片),跟Riak通過分佈策略把數據分片到各個節點不一樣,通過視圖,CouchDB能實現更低成本的開發方法實現集合中的數據關聯關係。CouchDB的複製是全部或者全無,也就是說,所有參與複製的服務器有着一樣內容,因此在數據分佈到數據中心的過程中沒有分片。增加CouchDB節點的主要理由,不是爲了將數據四處分散,而是儘可能增加讀寫操作的吞吐量。總結來看,CouchDB實現了CA(Consistency、Availability,即一致性、可用性)。 4.Hbase作爲誕生於Google的Big Table論文的一種高性能專有列式存儲的數據庫,通過預寫式日誌(write-ahead logging)和分佈式配置,能夠快速地從單個服務器故障中恢復。作爲一個能管理一個非常龐大的“稀疏表”,它所謂存儲數據的表實際上被稱爲桶(Bucket),理論上一個大表能存儲無限容量的行與列,因爲跟傳統數據庫不一樣的是它的列實際上是“列族”,也就是一個列上能夠存儲多個列。在物理的底層,它的桶(Bucket)把表,行和列族按照不同的文件目錄深度存儲物理數據,分佈式框架把數據存儲到不同的區域(Region)節點。底層架構分別有Hadoop分佈式文件系統(HDFS)和Zookeeper(一種無領導者的服務(headless service),幫助節點間的協調)。意想不到的是,Hbase表中的行級屬性還能使用“布隆過濾器”,雖然這種算法可能會產生誤報,但是它使用位數組存儲更少的內存數據,通過這種折中的辦法提高查詢效率。 5.MongoDB作爲NoSQL的文檔數據庫,允許數據以嵌套的狀態保存,而且重要的是,它能夠以任意方式查詢嵌套的數據,而且它是沒有模式(schema),沒有模式指的是MongoDB的表(實際上叫集合Collection),跟關係型數據庫的表(表的結構與字段被強制設定)更加靈活。往數據庫的集合裏面插入的都是以JSON爲格式的文檔,因爲不需要遵從某個模式,可以簡單地嵌套任何值。Mongo鼓勵反規範化的模式(沒有任何模式),因此對於文檔的字段沒有任何的模式限制,因此對於調整字段和添加字段幾乎沒有任何的成本開銷。對於MongoDB的底層架構,除了能配置成多節點複製分區(Replication Partition),還能配置成分片分區(Shading Partition)。但是MongoDB的集羣服務,永遠只能有一個主節點向外提供服務,其它節點是不能訪問的,因此集羣爲了穩定和可用通常配置成奇數節點,否則需要引入配置服務(MangoConfig)節點(Mangos),它成爲了客戶端與多個分片服務器之間的完美中介。MongoDB集羣實現了CP(Consisten和Partition Tolerance,即一致性和分區容錯性)。 6.Neo4j的重點是數據間的關係,而非數據集合間的共性。對於其他數據庫的索引,所用的查詢方式與沒有索引時無異,但Neo4j不是這樣,它的索引有不同的訪問路徑。原因在於,索引服務實際上是一個單獨的服務。正是因爲Neo4j作爲一種重度關注關係的圖數據庫,因此在處理一些關係計算的時候十分方便和形象,例如可以導入電影的相關信息到一張大型圖中,通過使用Kevin Bacon算法找到圖中的中心點,找到哪個演員距離其它演員的關係最近(也就能通過他,達成以最低成本找到其它演員的方案),也就是通過這個中心點能降低關係尋找度。Neo4j的HA是關於可用性與分區容忍性(AP)的。每個從節點只會返回它目前所包含的數據,而這些數據可能暫時與主節點失去同步。 7.Redis是一個鍵-值對存儲庫。Redis的哈希表不能嵌套(任何其他的複雜數據類型也不行,如列表)。換言之,哈希表只能存儲字符串值。Redis的鍵-值對(或數據結構)存儲是輕量級和緊湊的,具有多種用途。Redis特有的Bloom過濾器將轉換一個值爲一個非常稀疏的位序列,與所有值的位序列並集進行比較,從而成功發現不存在性,布隆過濾器中,如果數據庫檢查不存在二進制數組的話,則數據一定是沒有的,但是如果檢查在二進制數組,數據不一定是存在的,具體需要根據數組的大小和數據規模進行平衡。Redis快速、簡便,其持久性取決於你的選擇。雖然它不是一個獨立的數據庫,但Redis是所有多持久並存生態系統的完美補充,可以作爲一個永遠存在的幫手,用於轉換數據、緩存請求,或通過它的阻塞命令方式來管理消息。 最近讀了的這兩本高質量技術書籍,即使讀完再覆盤與回味其中的技術細節都讓人意猶未盡,但是這本書中還有一些詞不達意的翻譯問題,而且我認爲有些比較重要的技術細節都沒着重筆墨去介紹和分析,但瑕不掩瑜,不完美的書籍纔是完美的,這本書真的值得一讀。

★★★★★

全書講解了7個數據庫,分別是PostgreSQL、Riak、Hbase、MongDB、Couchdb、Neo4J、Redis,深入淺出,是學習數據庫比較好的一本書。內容的可讀性很強,可操作性也很不錯,對於初步學習和了解數據的組合方式而言是非常不錯的一本入門書籍,架構師實戰也是必備的選擇之一。 非常好,適合絕大部分架構師和數字產品經理來讀一讀。 強烈推薦。

★★★★★

行文流暢,突出重點,高度概括。通過擴展閱讀和在不同數據庫間對比思考,更深入的理解了CAP理論和各數據庫在實現上的具體取捨哲學,C和A並不是0或1的二值選擇,而可以是0到1中間的折中側重,另一方面是CAP的A與高可用HA的A的不同,丟掉A去追求HA通常也是不錯的選擇。圖數據庫打開了新的思維方式,看neo4j的官方文檔,簡單一句chyper語句就能實現較複雜的基於各種算法的協同過濾推薦系統,所以我們很有必要了解不同類型數據庫的核心優勢,在不同的場景選擇最優的組合來實現。

★★★☆☆

手冊水平 - 如果早點有 AI,這種書就沒人看,也沒人買了。

★★★☆☆

內容是不錯的 尤其是 postgres MongoDB 和 Redis幾章,的確講到了我不懂的東西。最後cap theory的例子也很實用。 但是這本書比較老了,已經有了第二版(但這裏是第一版)。此外,排版真是爛。代碼換行基本上都丟了,看的時候要充分發揮想象力

★★★★☆

不同數據庫的串聯分析,值得一看。 安裝什麼的可以跳過,代碼可以不用細看,感興趣的可以去各自官網深度探索。 數據庫沒有銀庫。

★★★★★

作爲七週七XX系列的一部,理論講解和概括的部分值得一讀和快速瞭解,示例代碼部分就相對沒那麼有趣了。

☆☆☆☆☆

可方便快速理清關係數據庫【sql】到非關係數據庫【nosql】的關係

★★★☆☆

乾貨實際不多,重在擴充視野,不太建議一步步去實踐其中的任務,等到你真需要使用某個類型的數據庫時再去系統學習收益會更高一些

書籍信息

作者Eric Redmond Jim R.Wilson
譯者王海鵬,田思源,王晨
出版社人民郵電出版社
出版時間2013-07-01
ISBN9787115312242
分類計算機-數據庫
格式EPUB
完結狀態連載中
章節數19