结尾一句很精彩：总之，我们应该采用无聊的技术去构建创新的产品，而不是倒过来。
所以，我来寻求一个“无聊”的数据库。
我不想去学习和运维一个“创新”的分布式数据库，甚至不想去给数据库分表，这样可以更多将精力放在产品和其它更有价值的技术上。
我现在使用数据库的方法有两种：
1. 开发机器上用 docker 跑了一个数据库实例，随系统启动。
2. 卖盗版书给我还打死不赔偿的马老板家提供的云数据库。
这两种，我都不需要费心再学习和运维。它们对我，就是一个连接字符串。
但这两种使用方法并不总是能满足我的需求，原因有下：
1.一些系统的需求，更多是分析，而非交易。
2.一些系统的数据量很大。这些数据，可能是用于交易，也可能用于分析。
3.一些项目，客户要求私有化部署，也就是部署在客户自家的机房里，这些机房可能是不连外网的。
是的，很多“创新”的分布式数据库软件可以满足上面三项需求。
但很多“创新”的产品往往很反人类，用户体检很糟。他们需要我：
1. 学习他们的安装、运维、使用方法，这是一个漫长的过程。
2. 然后按照学到的，去安装、运维、使用，这会伴随着我渡过整个项目生命周期，尤其在项目开始时和半夜。
3. 新的东西往往很多坑，但文档往往不会高亮出自己的缺点。我的老板也不喜欢我告诉客户，自己开发的产品有哪些缺陷。
所以，我需要的是这样子的数据库：
1. 能够满足分析和交易的需求。我并不介意这两种需求是两种数据库分别满足的。
2. 学习起来很简单。最好文档能够秒懂。
3. 集群，运维简单。最好在每台服务器上执行一条命令，就可以拉起整个集群。当需要新增存储空间时，只需要将服务器连接到集群；不用担心集群中的某个节点半夜会挂掉或恢复。我并不介意集群类型是分布式，还是中间件实现的主备 /分片。
4. 使用简单。最好对于使用者来说，就是一条普通的连接字符串。最多是创建表 /集合时，简单声明下分布式 /集群配置。
5. 对硬件要求不高，不然我的老板会不高兴。
6. 当然，还得支持部署到不连外网的机房。
总之，作为成年人，我需要的是既要又要还要的数据库。
