七周七数据库

作为一名长期曾经深耕后端开发、熟悉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】的关系

干货实际不多，重在扩充视野，不太建议一步步去实践其中的任务，等到你真需要使用某个类型的数据库时再去系统学习收益会更高一些