MySQL 还是 ES

周末继续闲扯

先问大家一个问题，在涉及到系统架构或者技术选型时，通常会面临很多选择，如果让你来做选型，你会选择什么方案，比如数据库你会选什么？ 

我这么问其实是设有陷阱的，但凡脱离了实际业务场景谈架构都是耍流氓。

开源数据库产品近10年来百花齐放，10年前还是关系型数据库的天下， 因为他们有天然优势，一通用，二保证了数据一致性，当然缺点也不少。

随着互联网的高速发展，业务也随之变得复杂，数据量呈指数级增长，所以近年来诞生了很多非关系型数据库，比如k-v类型的redis，文档数据库 mongodb， elasticsearch，等等。

最近我遇到一个问题就是某个业务数据量已经到了千万级别， 还在持续增长，因为数据库用的是 MySQL，在可以遇见的一段时间后，这个表将面临数据查询慢的性能瓶颈。

千万级数据量当然不是简单列加个索引就能解决问题的，毕竟重新建索引就是个非常缓慢的过程。

所以不得不做分表分库处理，虽然MySQL已经有很多成熟的分表分库的中间件，但好像针对python的并不多。 分表分库麻烦，是垂直分还是水平分，根据什么字段来分，都是要考虑的问题，要改动的业务逻辑代码也不少

这个时候MySQL在扩展性方面就并没有那些NoSQL灵活了，天然就是为分布式而生的mongodb，elasticsearch 就不会遇到这样的问题，真遇到了瓶颈只要怼机器就行。

所以，最近准备把这块业务迁移到elasticsearch。

虽然说 elasticsearch 是为了解决全文检索问题诞生的，但毫不影响它用来做数据存储，因为他本质上是一个分布式数据库。

用elasticsearch做数据存储，这样数据的扩展性问题也能得到很好解决，关键是使用非常灵活，不像操作MySQL一样，操作表结构麻烦的一逼，有时不得不停掉服务来升级，而 ElasticSearch 完全没这样的烦恼。

是不是一开始我就应该用ElasticSearch来做数据存储呢？ 这个就仁者见仁智者见智了。早期业务量没那么大，当然是怎么简单怎么来，当前的架构能支撑未来一到两年的发展就完全足够了。谁知道能不能活过两年呢？

好的架构都是演进过来的，不是闷头设计出来的。