网上有一篇文章提到数据库不适合容器化的七大原因：
1、数据不安全
2、运行数据库的环境需求
3、网络问题
4、状态
5、数据库不适合使用主要的Docker功能
6、额外的隔离对数据库是不利的
7、云平台的不适用性
当然网上搜索“数据库适不适合Docker容器化部署”相关关键词，基本上也只有这一篇文章。
至于它说的到底对不对，一开始也非常疑惑，但经过一段时间以后，阿汤博客觉得“数据库适不适合Docker容器化部署”没有绝对的答案，完全看业务场景、量级和数据库的架构。下面谈谈阿汤博主个人的一点点看法和理解。
从数据安全性来看，目前在实际工作中，项目非生产环境中的MySQL、Redis、Eleasticsearch都实现了容器化，都运行良好，也并未出现过什么数据安全问题。前提当前是不能把数据存储到容器内部。
当初为什么要把数据库容器化部署？
在非容器化部署时，一台服务器上面要部署多个MySQL、Redis、Eleasticsearch实例，可以说非常困难，维护管理也非常痛苦。
容器化以后，同一个镜像，可以在一台服务器同时部署dev、test、uat三个数据库实例，只需要映射不同的端口即可，完全保证了环境一致性；而不用每台服务器去编译安装。
单机的情况，完全可以一个docker-compose文件，就管理了三个环境的实例。
从复杂度来说，有状态应用在容器化相对于无状态应用来说要略微复杂。
容器化以后，网络也是一个复杂的问题。
就拿比较热门的容器编排工具kubernetes来说，在部署无状态应用和有状态应用是就能体现出来无状态应用的优势，你要多考虑一个数据持久化。
数据持久化就设计到共享存储、PV、PVC管理以及如何水平扩容等等相关的一系列问题。
从性能方面来说，不管是什么docker网络插件、什么kubernetes网络插件、都会有多多少少的性能损耗。
如果使用共享存储，即使是阿里云的文件存储CPFS，也存在一定的网络传输IO延迟。
这也是为什么阿里云RDS，存储类型推荐购买本地SSD，而不是云盘。
阿汤博客认为这些损耗和延迟在你的业务没有达到一个量级或不要求极限并发I/O性能、读写时延极稳定的业务场景，是可以完全忽略的。
打个比方，我有一个10000节点的集群，每个节点实例因为容器化网络插件损耗，QPS低于非容器化100，如果没有这些损耗，集群QPS就要提高10000*100=100万。
如果你只是一个3节点的集群，这点损耗完全就可以忽略不计了，不如水平扩展一个节点、增加服务器配置提升来的性能来的明细。
很多人都在谈服务器性能优化、内核优化，个人认为业务量没有达到一个量级时，这些优化并不能带来太多收益和效果，不如增加一个节点来的明显。
从数据库集群管理方面来说，目前只有Eleasticsearch官方推出了ECK，用于编排和管理Eleasticsearch在kubernetes集群中的运行。
至于Redis，当不需要数据持久化时，在kubernetes集群中相对其他数据库编排、水平扩容还是容易一些。
至于MySQL，在kubernetes集群想要部署管理一套高可用MySQL集群，并实现水平扩容是一件非常困难复杂的事情。
所以生产环境MySQL集群我还是采用了商用产品。
目前，一些高性能DB如：腾讯云的TDSQL（金融分布式数据库）和阿里云的Oceanbase（分布式数据库系统）都直接运行中在物理机器上，并非使用便于管理的 Docker 上。
部分介绍：
OceanBase 数据库采用 Shared-Nothing 架构，各个节点之间完全对等，每个节点都有自己的 SQL 引擎、存储引擎，运行在普通 PC 服务器组成的集群之上，具备可扩展、高可用、高性能、低成本、云原生等核心特性。
TDSQL 可提供多种部署形态。在公有云，提供多租户和独享物理集群两种部署形态，仅需在管理控制台中单击几下，即可生产一套 TDSQL 数据库。同时可兼容 MySQL、MariaDB 协议，兼容 PostgreSQL 协议，高度兼容 Oracle 语法；可在一个物理集群中扩展支持集中式和分布式实例。
