选择合适的数据存储方案

5,237 阅读3分钟

在服务端经常遇到数据存储问题,是采用MySQL?Redis?MongoDB?还是ElasticSearch?今天的话题是,我们怎么根据业务场景来选择适合的数据库产品。

MySQL

MySQL是一个关系型数据库管理系统,由瑞典MySQL AB 公司开发,目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一,在互联网产品中应用比较广泛。

一般情况下,MySQL数据库是我们选择的第一方案,我们有80% ~ 90%的场景都是基于MySQL数据库的。为什么呢?因为,我们需要关系型数据库进行管理,此外,我们的业务存在许多事务性的操作,需要保证事务的强一致性。同时,可能还存在一些复杂的SQL的问题。(个人建议互联网产品,尽量减少表关联操作,便于后期数据量增大的情况下,做分库分表)

Redis

内存的读取速度大概是硬盘的80倍。因此,为了提高服务端接口的访问速度,尽可能将读频率高的热点数据存放在Redis中,因为Redis数据存放在服务器内存。这个是非常典型的以空间换时间的策略,即使用更多的内存换取CPU资源,通过增加系统的内存消耗,来加快程序的运行速度。

使用Redis做缓存的时候,需要考虑数据不一致与脏读、缓存更新机制、缓存可用性、缓存穿透等问题。

此外,Redis也可以作为一个简单的消息队列来使用,即通过Redis的List进行控制消息的入队和出队操作。因为篇幅问题,下次另开一篇博文来讲解我之前的项目是如何基于Redis + MongoDB搭建一个简单的消息队列服务,但是对于复杂的业务场景,建议使用RabbitMQ等专门的消息中间件。

MongoDB

MongoDB是对传统关系型数据库的补充,MongoDB非常适合高伸缩性的场景,此外它是可扩展性的表结构。基于这点,我们可以将预期范围内,表结构可能会不断扩展的MySQL表结构,通过MongoDB来存储,这可以就可以保证表结构的扩展性。

记住,如果需要保证数据强一致性,就不能这么玩了。为什么?因为MongoDB不支持事务,所以没办法保证数据强一致性。

此外,MongoDB还适合存储大尺寸的数据,例如我之前讲解的GridFS存储方案,就是基于MongoDB的分布式文件存储系统。

Elasticsearch

在一般情况下,模糊查询,我们都是通过like的方式进行查询。但是,对于海量数据,这并不是一个好办法,因为like进行模糊匹配效率十分低下。怎么说?因为like对于‘%$value%’这样的方式,它是走全表查询,假设我有一张应用信息表存在千万级的数据量,这是很可怕的事情。

那么,这种情况下,我们需要考虑使用全文搜索的方式进行优化。全文搜索通过反向索引结构,因此它的查询速度是相当快的。Elasticsearch是全文搜索的一种方案,相同的产品还有solr等。

所以,我们可以使用Elasticsearch作为数据库全文搜索的功能补充,将要进行全文搜索或者复杂的业务缓存一份到ES上,达到提高查询速度的目的。

总结

最后,我们来做下总结

  • MySQL: 传统关系型数据库,事务性,复杂的SQL问题。
  • Redis:缓存、消息队列。
  • MongoDB:高伸缩性的场景,预期可扩展性的表结构。
  • Elasticsearch:全文搜索,提高模糊查询速度。
微信公众号