数据库新语言那些事儿，开发潮流也跟着变了不少

（来源：InfoQ社区多位技术专家在2023年ArchSummit会议上的圆桌讨论记录整理）

说起来现在的数据库,那可真是五花八门，不像十几二十年前，大家一提到数据库，脑子里蹦出来的基本都是Oracle、MySQL、SQL Server这几个老面孔，那时候，甭管你是什么业务，基本上都是用SQL这种语言去跟数据库打交道，写来写去就是SELECT、INSERT、UPDATE、DELETE那几样，但现在情况完全不一样了，数据库的种类爆炸式增长，什么关系型的、文档型的、图数据库、时序数据库、向量数据库……每种数据库为了解决自己特定领域的问题，都在琢磨着搞一套更趁手的“语言”，这股风气反过来又影响了咱们开发人员写代码的思路和项目的架构，可以说，开发潮流也跟着变了不少。

（来源：MongoDB官方博客关于查询语言演变的系列文章）

最明显的一个变化就是,SQL不再是唯一的选择了，就拿现在特别火的文档数据库MongoDB来说吧，它用的查询语言就不是SQL，刚开始的时候，它的查询语法是直接跟JavaScript对象长得很像，用一堆大括号{}来包着各种条件，比如db.users.find({age: {$gt: 18}, city: "北京"})，这对于很多从JavaScript前端转过来的开发者来说，感觉特别亲切，上手很快，这种写法跟传统的SQL语句SELECT * FROM users WHERE age > 18 AND city = '北京'比起来，思维模式确实不一样，SQL更偏向于描述“我想要什么”，是一种声明式的语言；而MongoDB早期的查询方式，更像是在用代码构造一个查询条件对象，这种差异就让很多习惯了关系型思维的开发者需要一段时间来适应，但也让另一部分开发者觉得更加灵活和直观。

（来源：亚马逊云科技re:Invent 2022大会上关于多模型数据库的演讲）

光适应还不够,因为业务需求越来越复杂，比如现在很多应用既要处理像用户订单这样的结构化数据，又需要分析用户之间的社交关系，可能还需要存储和快速查询设备上传的时间序列数据，比如物联网传感器的读数，这时候，如果一个系统里塞进好几种不同类型的数据库，管理起来会非常头疼，数据库自己也开始“进化”，出现了一种叫“多模型数据库”的东西，这种数据库试图用一个后端核心来支持多种数据模型，这就对查询语言提出了更高的要求，比如微软的Azure Cosmos DB，它就尝试用一种核心的SQL语法（虽然和传统SQL有区别）作为基础，然后通过一些扩展来同时查询JSON文档、图数据等，这想法挺好，让会用SQL的人能更快上手，但实际用起来，要同时把不同数据模型的特性和优势都发挥出来，对查询语言的设计是极大的考验，开发者学习起来也得理解这些扩展背后的概念。

（来源：Neo4j图数据库白皮书及开发者社区调查）

再说说图数据库,它的兴起对查询语言的影响就更大了，图数据库是专门用来处理事物之间复杂关系的，比如社交网络中的好友关系、金融交易中的资金流向，你用传统的SQL来查“我朋友的朋友中，谁和我是同一天生日？”这种问题，可能需要写好几次JOIN连接，表一多，查询速度就慢下来了，写起来也绕，但图数据库有自己的查询语言，比如Neo4j用的Cypher语言，Cypher的写法非常形象，它用类似箭头-->的符号来表示关系，整个查询语句读起来就像在看一幅图的路径描述，比如MATCH (p:Person)-[:FRIEND_OF]->(friend)-[:FRIEND_OF]->(foaf) WHERE p.name = 'Alice' RETURN foaf.name，这种语言设计极大地降低了处理复杂关系的门槛，让开发者能更直观地表达自己的查询意图，这也带动了一波新的开发思路，就是当业务中关系非常复杂、深度很深的时候，大家会优先考虑使用图数据库和它的专用查询语言，而不是死磕SQL。

（来源：开源向量数据库项目Chroma和Weaviate的文档及教程）

最近一两年,因为人工智能，特别是大模型的火爆，向量数据库又成了新宠，它的核心任务是快速找出和某个目标最相似的一堆数据，这显然不是传统SQL的强项，向量数据库的查询语言核心就围绕“相似度搜索”来设计，它们通常会提供一些像query或者search这样的专用命令，核心参数就是一个代表含义的向量值，然后返回按照相似度排序的结果，你可能会写一个类似SELECT * FROM items ORDER BY embedding <-> '[0.1, 0.2, 0.3]' LIMIT 10的语句，这里的<->可能就代表计算两个向量距离的操作符，这种极度专注的查询语言，让做AI应用的开发者能够用非常简洁的指令完成核心任务，而不需要去理解背后复杂的索引算法。

（来源：资深技术博主“程序员DD”在其专栏文章中对现代应用开发的观察）

这么多新的数据库语言冒出来,带来的直接影响就是，现在的全栈开发者或者后端开发者，不能再像过去那样只抱着SQL这一本“圣经”不放了，根据项目的需要，你可能得同时了解好几套查询语法，这在做技术选型的时候就成了一个重要的考量因素：不仅要看数据库的性能、扩展性，还得评估一下团队学习和掌握这种新查询语言的成本高不高，社区的活跃度怎么样，在应用程序的架构设计上，以前可能一个ORM（对象关系映射）框架就能屏蔽掉大部分数据库差异，但现在面对差异如此巨大的各种查询语言，ORM框架有时也力不从心，这就导致了一种趋势：在需要极致性能或者充分利用某类数据库特性的场景下，开发者更倾向于直接使用原生的查询语言，而不是为了统一而增加一层可能带来性能损耗和功能限制的抽象。

数据库新语言的涌现,是数据库领域为了应对多样化数据挑战的自然结果，它们不再追求一种语言通吃天下，而是更注重在特定场景下的表达力和效率，这股潮流迫使开发者们必须保持持续学习的心态，拓宽自己的技术视野，根据实际的业务问题来挑选最合适的工具和语言，而不是试图用一个旧工具解决所有新问题，整个开发的潮流，也因此从追求“统一”更多地转向了拥抱“多样”和“专业”。