各位工匠们，大家聚在一起。让我们暂时放下手中的工具——那些精雕细琢的 ORM、精心设计的查询、优雅的分片集群——来谈谈艺术，而不是代码。更具体地说，我们来谈谈一个流传甚广的现代民间传说，一个让许多经验丰富的开发者陷入困境的诱惑：NoSQL 天生比 SQL 更快的迷思。
我也曾听过这首歌。那是一个扩张恐慌的时代，我精心构建的关系型数据库似乎在一种新的重负下呻吟。会议厅里传来诱人的低语：“把一切都去规范化吧”、“Schema 是枷锁”、“Join 是个脏话”。它承诺了一条阻力更小的道路，一种原始的、不受约束的速度。
于是，我踏上了旅程。我走出了 SQL 数据库结构化、柱状排列的大厅，进入了 NoSQL 狂野、无模式的平原。
第一笔：自由的幻觉 最初的感觉就像一种解放。将 JSON 文档放入存储中，就像挥舞着一种新的粘土——无形、可塑、即时。无需迁移，也无需像在飞行中重建地基那样使用 ALTER TABLE 语句。A db.collection.insert()，它就在那里。速度显而易见。对于简单的写入和键值查找，它无疑是快的。
我想，这才是杰作。这才是真正的表演。
但是，如果一个艺术家把空白画布上的自由误认为是一幅完成的画作，那他就根本不是艺术家。他只是涂鸦者。
粘土中的裂缝：隐藏复杂性的出现 第一个难题出现在一个简单的产品需求上：“显示该客户的所有订单，包括产品名称和类别。”
在我以前的 SQL 世界中，这很简单，就是JOIN在Customers、Orders、OrderItems和之间进行Products操作。优化器会精心设计一个优雅的执行计划，然后执行一系列索引查找，最后返回结果。这是一种已知的、可预测的舞蹈。
在我的新 NoSQL 世界中，我有一个选择，而且没有一个是“免费的”：
预连接文档：我之前把整个订单，包括所有明细项目，都嵌入到了客户文档中。一次读取就搞定！但现在，更新产品名称意味着要遍历所有引用过它的客户文档——这是一个灾难性的、需要耗费数秒的写入操作。我的“快速”写入操作导致更新速度慢得令人难以忍受。 多重查询之舞：我之前存储了引用。现在，我的应用程序代码必须执行：一次查询获取客户，一次查询获取他们的订单，然后N查询获取每个产品的详细信息。我之前“简单”的读取操作现在变成了一个冗长、潜在的网络调用瀑布。数据库“很快”，但整体服务却很慢。 物化视图：我可以构建一个单独的、读取优化的集合，精确复制此查询的数据。这确实有效，但现在我就像一个雕塑家，必须维护两尊完全相同的雕像，确保它们永远不会失去同步。我牺牲了运行时连接，换来了一致性的操作复杂性。 我并没有消除复杂性；我只是把它从数据库引擎转移到我自己的应用程序逻辑上。现在，我需要手动管理关系、一致性和索引策略，而这些是我几十年来 SQL 数据库一直在处理的。我的“快速”数据库需要一个更加复杂和脆弱的架构才能实现同样的结果。
大师的领悟：重要的不是速度，而是形状 这就是通往真理的旅程。争论的焦点不在于“快”与“慢”，而在于“适不适合”。
关系数据库精通一种特定的艺术形式：互联数据集。它的强大之处在于其数十年的 ACID 事务基础、严格且可预测的模式，以及强大的声明式语言 (SQL)，它只告诉它你想要什么，而不是如何获取。查询优化器才是真正的艺术家，它是一位专家，可以将你的查询重新整理成一个你手动编写的、令人叹为观止的高效执行计划。
它的速度就像一台完美设计的印刷机的速度——始终如一、可靠，并且能够出色地制作出复杂、相互关联的作品。
NoSQL 数据库是另一种艺术形式的大师：专业手术刀。它的力量来自于为了特定目的而牺牲通用性。
键值存储（Redis）：闪电般的速度。缓存和会话存储无可匹敌。 文档存储 (MongoDB)：单次深度挖掘的效率。当您的数据访问模式始终是“一次性获取整个对象及其所有嵌套部分”时，这非常完美。 列存储（Cassandra）：液压机的强大功能，专为实现巨大的分布式写入吞吐量和宽行聚合而设计。 图形数据库（Neo4j）：连接点、查找关系和路径的流动性，是关系数据库无法比拟的。 当你的问题符合 NoSQL 特定、狭窄的艺术风格时，它会更快。作为通用数据存储，它本身并不一定更快。
完成的画布：目的调色板 那么，在从 SQL 大教堂到 NoSQL 荒野再返回的旅程中我学到了什么？
我没有“回归”，而是不断进化。现在，我将我的数据格局视为一个调色板，每种数据库技术都呈现出不同的颜色，并具有独特的属性。
我的用户会话存储在 Redis 中——闪电草图。 我复杂的交易性财务数据驻留在 Postgres 中——主人的印钞机。 我的应用程序日志和事件流流入 Elasticsearch——强大的搜索引擎。 我的推荐引擎遍历 Neo4j 中的关系——连接之王。
神话已死，艺术在于选择。
不要再问“哪一个更快？”开始问高级开发人员的问题：“对于我的特定数据模型和访问模式，哪种工具提供了最优雅、最强大和可扩展的解决方案？”
有时，答案会是一个单一而强大的 SQL 数据库。通常，答案会是一个多语言持久化架构。但这绝不会是一个基于简单而过时的迷思而做出的选择。
像艺术家一样选择工具，而不是像粉丝一样。你的杰作取决于它。作者www.whatapp.biz
