最近经常和朋友谈起数据库的通用性，提到有一类数据库是通用数据库，有一类数据库是非通用数据库到底通用数据库这个概念怎么定义呢?实际上关系型数据库从出生的那一天起，就是希望让数据库应用变得更加简单，因此其目的就是成为一个通用的管理数据的IT基础设施。

关系型数据库中有一类就是为了特定的目的或者场景设计的，比如SQLLite，其目的就是让SQL应用能够在嵌入式环境中运行。而有一些数据库产品当时是为某个特定的业务场景而开发的，在设计之初并未考虑对通用场景的设计。还有一些数据库虽然是为通用场景设计的，但是在其发展过程中并不完善，对于某些类别的应用场景支持不佳。因此笼统地谈通用数据库这个概念，其实并不能够很准确地把问题说清楚，反而让人更加糊涂了。

比较有意思的样本是InterSystems Caché 数据库系统。目前而言，Caché已经被认为是一种通用数据库产品，但是从其历史发展而言，其在很长的历史时期里都是一种专用数据库。InterSystems 成立于 1979 年，旨在将 MUMPS 分层数据库商业化。MUMPS(“马萨诸塞州总医院实用工具多编程系统”)是一种命令式高级编程语言，具有集成的事务处理键值数据库。它最初是在马萨诸塞州总医院开发的，用于管理患者病历和医院实验室信息系统。此后，MUMPS 技术已扩展为美国健康信息系统和电子健康记录的主要数据库。基于 MUMPS 的信息系统，例如 Epic Systems 的信息系统，为美国超过 78% 的患者提供健康信息服务。MUMPS 技术的一个独特之处在于其集成的数据库语言，允许对永久磁盘存储进行直接、高速的读写访问。

作为一种对象数据库， Caché 支持SQL接口，这让 Caché 数据库有了更为广泛的应用场景。目前在美国的医疗行业外，银行、证券交易、政府、军工等领域也有大量的应用。美国退伍军人事务部使用的 VistA 系统。Sungard 的银行 资产管理系统AddVantage电信供应商 BT Group的 Vodacom 系统中，都使用了 Caché。基于Caché InterSystems 公司推出了下一代数据库系统IRIS。

从Caché的例子可以看出，任何一个数据库产品的最终目标都是成为通用数据库产品，不过都有其发展过程。很多数据库最初都是在某个应用场景或者某个用户处发展起来的，前几天听老盖讲数据库历史的时候，说到数据库发展的历史中，美国的核计划和登月计划都起到了十分关键的作用。作为一个商品，数据库为某件事或者某个用户而生是十分正常的。比如OceanBase早期就是为了解决阿里和淘宝中十分棘手的问题的。到了1.0以后才开始转向通用商用数据库系统。

因为国产数据库的发展都还处在某些发展阶段，因此其通用场景支持或多或少存在一些问题，某些数据库可能更加严重而已。大多数分布式数据库的早期版本中，其事务锁、MVCC、分片策略机制等都存在很多缺陷，比如但是被很多应用厂商诟病的乐观锁。事实上，乐观锁目前为止还是解决超高并发系统性能问题的关键技术，在某些场景下，乐观锁具有极高的优越性。不过对于传统的信息管理系统而言，乐观锁对开发者不太友好，开发者已经习惯了Oracle这样的行锁、事务锁。另外在MVCC上，在事务隔离级别上，不同的数据库产品都会有较大的差别;每个事务能够包含的变更行数也是容易让人忽略的，虽然大多数数据库可以通过参数来调整，不过超过默认值后的性能衰减也是值得你去关注的。

我觉得用是否通用数据库这一点来简单地划分国产数据库的阵营是不太合理的，因为没有一个国产关系型数据库厂商会说自己不是通用型数据库厂商。但是数据库对应用的限制是确实存在的。如果你的应用场景十分具有挑战性，那么在选择数据库产品的时候，一定要用你的场景去对数据库产品做一个测试。并不是要用超高的并发去测试，很多非“通用型数据库”就是为了高并发场景设计的。你可以选择一些大批量数据处理、大批量数据输出、超大型事务、较长的事务、最复杂的多表关联查询、并发读最高的简单查询等多个角度去测试数据库，设置及格线。评判标准并非越高越好。对于及格线、未来预期设定两三个评价等级就可以了。只要通过了等级线，大家在这项上的得分就是相同的。这样的测试结果，可能更符合你选择的预期。

原文标题：《通用数据库的概念》