"永远不要低估好营销对坏产品的力量"。
这是我最喜欢的一句话，出自一篇论文《善有善报，恶有恶报》。这篇论文详细介绍了为什么 SQL 和关系数据库至今仍是事务型数据的最佳工具。
2024 年的这篇论文延续了 Stonebraker 2005 年的一篇颇具影响力的论文，该论文探讨了为什么 SQL 和关系数据库在 90 年代的所有数据管理创新中胜出。
归根结底，企业又回到了好的东西上。
NoSQL 的 20 年历程是什么样子的？
Stonebraker 在 2005 年的论文中谈到了历时 35 年的数据库研究，以及当前关于 XML 文档与关系数据库的争论，还有与 20 世纪 60 年代的争论惊人地相似。
您应该不记得 XML 数据库，因为它们没有存活下来。
2000 年代初和 2010 年代初期，所有的网络规模技术都发生了类似NoSQL的事情。
您一定听说过的下面这些著名的技术栈，它们都具有以下特点：
已经从 BigTech 代码库中删除（如 MapReduce）获得事务支持（如 Mongo）获得了 SQL 的风格（如 DynamoDB、Spanner、Mongo）主要用于分析工作负载（如 ClickHouse、DuckDB）被降级为缓存（如 Redis）作为 NoSQL 技术 (它一定会成为网络级的兄弟！) 的粉丝，我并不感到惊讶。你使用这些东西越多，你就会越意识到它只有一些狭窄的用例，你应该使用 Postgres 或 MySQL，甚至 Oracle (啊呸) 来处理核心生产数据。
SQL 提供的灵活性
许多软件工程师会刻意地回避 SQL，因为 SQL 是需要学习另一门语言，而且 SQL 和其余的程序代码之间存在一些阻抗和不匹配。
在您选择的编程语言中，在平面数据与对象之间进行转换也非常麻烦。
总之，它重复、繁琐，让人感觉很麻烦——我喜欢称其为“ Json 官僚主义”。
因此，我们就构建了 ORM 和各种框架来将这些“脏活”掩盖起来。您所做的领域越复杂，您会看到越多的工程师使用 ORM 版本如rawSql编写纯 SQL 查询，因为这样会变得更容易。
NoSQL 也发生了同样的事情。开始是“嘿，你再也不需要编写 SQL 了！你的数据库本身就能理解你的编程语言”。
而这正是问题所在。
NoSQL 数据库非常擅长以工程师预先预测的方式读取数据。需要新东西吗？编码时间。希望新路径也快速吗？很难！优化已融入您的数据结构中了。
Stonebraker 表示：“NoSQL系统正与关系数据库发生冲突” 。很大程度上是因为能够临时查询生产数据并让数据库引擎优化执行，这非常有用。
与 SQL 问题类似，这些系统用灵活性换取熟悉度，许多 Web 规模技术必须用 ACID 的合规性换取速度。
原子性、一致性、隔离性、持久性
数据库确保使用事务，这是一种确保您的正在进行的查询以原子方式保存（全部或全部不保存）、保持内部一致性（没有陈旧数据）、与其他事务隔离并具有持久性保证（一旦保存，就被保存）的标准构造。
早期的 Web 规模技术不得不放弃这些保证，转而采用最终一致性和其他技巧。事实证明，这非常难处理，并且是难以修复错误的常见来源。
事实上，越来越多的 NoSQL 系统正在增加事务支持。
数据是永恒的
当你和我四处奔波，把玩新技术时，推动这些产品的大型科技初创公司有充分的内部理由尝试并让其发挥作用。
数据具有极强的粘性。一旦拥有了可用的数据库，就再也不会改变它。迁移到新数据库简直是天方夜谭。没人有时间这么干。
但谷歌和它的朋友除外，他们有数千名工程师和数十亿美元投入此类项目。但是他们最终也放弃了 NoSQL，因为它的作用并没有起那么大。
Cassandra、HBase、Spanner 等现在都具有某种 SQL 和事务支持。但即使是他们也不得不将这种支持添加到现有的 NoSQL 堆栈中，因为数据具有粘性。无论你是否喜欢，都必须保留底层技术。
OLAP 与 OLTP
OLAP（联机分析处理）是过去 20 年数据库创新大放光彩的领域之一。
列式数据库系列在数据分析、数据科学和数据工程中得到广泛采用。这些数据库倾向于将您的生产 OLTP（在线事务处理）数据扁平化为基于列的高度非规范化的表格。
然后，列式数据导向可让您运行快速分析查询。当您快速浏览一列类型相同的数据时，矢量化/并行化计算会更容易。当所有内容都已整合在一起时，您无需再处理连接。
但列式数据库暂时还未证明其适合生产工作负载，它处理行时速度太慢。
关系数据库采用最佳特性
Stonebraker 还注意到一个奇妙的趋势：新技术不断创新，而现有的关系数据库则不断采用它们。
例如每个现代关系数据库都已支持 JSON 列，因此您可以将它们用作文档存储。在很多业务用例中，将丰富的数据保存在单个列中非常方便。
SQL 现在已经允许您编写基于 JSON 的深度查询。数据库甚至支持 JSON 索引和其它的性能优化。此外，我们还可以获得完整的 ACID 支持。
同样，随着人工智能工程的兴起，向量数据库也变得开始风靡一时，你猜怎么着：关系数据库开始支持向量。同样具有关系数据建模、ACID 遵从、SQL 查询等所有优点。
或者正如 Stonebraker 所说的：“这是一个功能，而不是数据库”。
SQL 和关系型数据库的最大问题
不论SQL 和关系数据库都存在“前五分钟问题”：您必须考虑自己要做什么，设置数据库，创建一些表格，然后开始工作。
一些软件工程师讨厌提前思考，而NoSQL 会带来不必要的虚假承诺。
等到您有大量用户，而您的数据却因为大量堆砌开始崩溃时，这已经太晚了。您只能一直使用 NoSQL，因为数据是粘性的。
所以，如果可以的话，请您始终选择 SQL。
干杯！
参考：
https://swizec.com/blog/why-sql-is-forever/
