本来早上想写点东西的，但是这几天感觉有点累，早上什么都不想做。午饭后我感觉好多了。如果你脑子里恰好有一些疑问，马上记下来，否则这灵光一现的灵感可能会消失得无影无踪。前两天有客户问我什么是云原生数据库。我和他聊了很久，他还是有点糊涂。最后他说，这个东西听起来确实不错，但是对于我们这样的企业来说，用处不大。的确，像他们这样的央企二级子公司，数据库系统一共也就二十套左右，几乎没有一套可以称得上是大系统。我给他介绍的云原生数据库的好处，确实对他们没有太大的吸引力。国外很多云原生数据库都是运行在公有云上的。如果我的客户在国外，购买云原生数据库服务应该是首选。但在中国，由于一些数据安全限制，公有云服务无法购买。国内所谓的云原生数据库，往往不是建立在公有云上，而是通过数据库服务盈利。只要能横向扩展并运行在云端，就可以称为云原生数据库。事实上，云原生数据库并没有一个特别合适的定义。我认为能够与云平台紧密结合，在云端像标准组件一样提供服务，并且具备与云平台一样的水平扩展能力的数据库产品，才可以称为云原生数据库。那么云原生数据库产品应该具备哪些能力呢？首先，它必须符合“云”的特点，具有很强的自助服务能力，即买即用，即申请即用。让数据库服务像云主机或云上的RDS一样方便的应用，应用完成后秒级或分钟级快速交付。其实，这并不难实现。普通的云上RDS也是这样实现的。数据库软件安装在裸机服务器上。必要时，创建数据库实例并绑定相应的资源。二是弹性可扩展性。云的特点是弹性伸缩，不受单机硬件资源的限制。说到弹性伸缩，人们往往会直接想到分布式数据库。按照这个标准，是不是只有分布式数据库才算是云原生数据库？实际上情况并非如此。弹性扩展的局限不仅仅局限于CPU、内存等资源，这些资源有单机的上限。在云端绝大多数的数据库应用中，很少有这方面的限制。存储IO能力和IO延迟对于很多应用来说其实更重要。这也是目前用户对云原生数据库产品比较诟病的地方。如果我想买1TB的存储容量，但是需要50000IOPS，那对不起，我不能卖给你，我们的IOPS是卖5000/TB的，你得买10TB的容量才能买500万的IOPS。云原生数据库产品应与云平台紧密结合，利用云平台的弹性扩展能力，为用户提供不同的配置选择。Amazon的AURORA可以通过读写分离提供CPU资源的水平扩展，通过云平台底层存储机制动态复制副本，扩展IO能力，满足不同类型的业务需求。所以说一个数据库产品是云原生的，数据库和云基础的关系绝对不是简单的叠加部署，需要做大量的优化和适配工作才能做好。三是高可用，利用云平台的高可用能力，增强数据库的可用性。数据库产品本身有高可用的解决方案，云平台也有，但两者不一定完全兼容。因此，云原生数据库必须在云上与云更好地融合，只有结合双方的优势才能形成最佳的解决方案。计划。第四个是跨数据中心的高可用性。无论是私有云还是公共云环境，云都不可能永远没有问题。所以，作为一个云原生的数据库产品，必须能够支持这种跨数据中心、跨云的高可用。五是弹性资源调度能力。上云的最终目的是不断降低企业的IT成本。在我们的企业中，经常会有某个系统对资源的需求量有巨大的峰值，但是应用的峰值往往只有月底和月初的几天。老天，可是为了不出问题，我们必须给它分配最大的资源。动态资源调度和动态扩缩容还没有成为大多数大型企业的刚需。不过，地主家也会缺钱。随着数据库的爆发式增长，动态收缩在未来也将成为刚需。与国外不同的是，我国大部分的企业级应用还是部署在私有云环境中，甚至还有一些像本文开头提到的企业。云基地的话就比较麻烦了。因此，如果云原生数据库厂商能够提供一个小型的云数据库基础，对用户来说是非常友好的。不需要像Oracle数据库云那样配置硬件，只需要提供一个小型的云基础，有一个通用的硬件环境。也有一些数据库厂商不是云平台厂商。如果他们要和某个云厂商合作，他们可能不会跟你谈。既然云不来，那就是你，数据库厂商可以自己上云。自己开发一个数据库云库作为一个完整的解决方案来服务客户也是一个很好的方式。这几天脑子还是有点乱，今天在想写到哪里去。总之，我的观点是，云原生数据库的需求是很强烈的，但是我们现在的产品，大部分都是叫云原生数据库的，其实不是的。数据库厂商不能只喊口号而不是喊口号，要把自己的产品真正做到云升的样子。
