江苏龙网

  1. 主页 > 生活百科 > >

我们一起聊聊数据库与容器

数据库

昨天谈到关于serverless database的问题，我的观点是公有云上使用serverless database我是持正面态度的，但是对于一般企业来说，不太建议在私有云搞serverless database,除非是在测试与开发环境中，对于数据一致性要求没那么高的场景中使用 。昨天有朋友问我如何看待数据库上容器云的问题，数据库容器云实际上也是一种serverless database，我个人的观点，其使用场景也是有一定的限制的 。在后面我将会谈谈我对serverless database应用场景的一些个人看法 。
除了应用场景的限制外，团队的技术能力也是决定组织是否使用serverless database的很重要的因素 。可能你会看到某些互联网企业在这方面用得很溜，你也想去学他们，不过如果你自己的技术能力不足，简单的模仿很可能会编程东施效颦 。如果你的核心业务依赖于数据库容器云，而当容器云出现故障的时候，你无法解决这些故障，那么后果如何，是可以想象的见的 。
在讨论这些问题之前，我们首先要来弄清楚你把数据库迁移到容器云而不选择云主机的原因 。如果你仅仅是因为觉得容器比VM具有更小的开销（OVERLOAD），那么我建议你要再慎重考虑一下 。适当节约IT资源是很合理的，不过目前的数据库服务器资源与数据库所承载的企业关键数据相比，并不算昂贵 。如果你是为了百分之几的资源消耗差异而选择将数据库运行在容器里，那么就真的可以放弃这个想法了 。
将数据库放在容器云里运行，其终极目的都是serverless database，让数据库这种IT基础设施变得很简单，这才是数据库上容器云的最合理的需求 。2年多前，我写过一篇关于数据库上容器云的文章，其中对VM还是容器的选择用一张图示做了分析 。这张图是我在medium上看到的，是谷歌云解决方案架构师本杰明.古德画的 。觉得挺有道理，就抄了下来 。

我们一起聊聊数据库与容器

文章插图
图片
第一个选项要回答你的数据库是不是k8s友好的 。由于容器较物理机、虚拟机等环境是更容易出现故障的基础设施，因此故障自动转移事件的发生可能性比传统托管或完全托管的数据库高 。数据库中包含分片、故障转移选择、自动副本复制功能的数据库都是属于k8s友好的数据库，比如ElasticSearch，Cassandra或MongoDB等 。而MySQL、Pg、Oracle等数据库则是非k8s友好的数据库 。
对于非k8s友好的数据库，如果具有较好的k8s上的运行支撑，比如借助于一些Operator来实现数据自动复制/备份，故障自动转移等特性，并且组织能够提供足够的运维支撑，那么也是可以转回使用k8s这条线的 。然后我们要回答下面的一个选项，就是数据库的工作负载是不是适合k8s，如果这个数据库是一个负载不高，并且随着应用上线后，负载增加不是很大（如果有较大的负载，可以通过横向扩展，而不是增加在一个独立的数据库上），那么这个工作负载就是k8s友好的，可以使用k8s 。反之，如果这个数据库工作负载很大，或者存在十分高的高峰，或者随着上线时间推移，数据量增长很快，负载会越来越大，而且无法很好的横向扩展，那么这个工作负载是非K8S友好的 。
然后进入第三个选项环节，你的工作负载能支撑多大的并发量，如果你可以完全控制并发量，让k8s能够承受合理的工作负载，那么你就放心的在k8s上跑你的数据库吧，否则还是让数据库跑在一个完全受控的环境下 。
从上面的分析可以看出，判断数据库是否能上容器云，主要要考虑两方面的因素，一个是你的应用负载是否是可控的，数据库的规模与负载是否完全受控，不会因为业务发展和数据量的增长而导致数据库规模和负载不可控从而引发性能问题，这一点是数据库在容器中运行的最基本的条件 。
【我们一起聊聊数据库与容器】第二个因素是数据库本身是否是容器友好的，其架构本身就不怕容器这种不够稳定的基础设施出现问题，如果你的数据库本身必须依赖于稳定的IT基础设施，那么你的数据库上容器云的前提是你的技术足够好，能够提供能力强大的operator，从而让数据库能够在容器云中免维护运行 。
上面的问题只是回答了能不能在容器云中运行数据库而已，而要不要让的数据库在容器云中跑是另外一个问题了 。我觉得在让自己的数据库上容器云之前有几个问题需要再思考一下 。如果你觉得上容器云的最主要的目的是为了节约计算资源，那么我建议你立马放弃这个想法 。对于绝大多数企业的几百个或者千把个数据库来说，上容器云节约的成本，还不够搞出一套靠谱的operator来 。


推荐阅读


上一篇：关于数据库选型中的几个问题谈谈我的观点

下一篇：为什么从 MVC 到 DDD，架构的本质是什么？