瑞斯云： 手把手教你如何进行业务系统数据库技术选型

随着云计算、大数据、物联网时代的到来，越来越多的网民涌入互联网，越来越多的应用系统需要支撑海量数据存储，还需要随着业务需求满足高并发、高可靠、高扩展性等要求，传统的关系型数据库已经不能完全满足需求了，因此NoSQL应运而生。

那么SQL是什么?、NoSQL又是什么?业务系统如何数据库技术选型呢?

NoSQL!= NO SQL，而是NotOnlySQL,作为关系型数据库的补充而出现。关系型数据库即采用了关系模型来组织的数据库，简单来说，就是二维表格模型，包含关系(表名)、元组(二维表中的一行)、属性(二维表中的一列)、域(属性的取值范围)、关键字(唯一能标识元组的属性)、关系模式(表结构，对关系的描述)等概念。以一个用户信息表来说，用户信息表就是整个关系，元组就是姓名、性别、年龄、电话、地域组成的一行记录，属性则是单独的地域列、年龄列等，域就是地域是中国全省市等，关键字就是用户ID、能唯一标识这个用户，关系模式就是这整个表，包含姓名、性别、年龄、电话、地域属性。

对于关系型数据库来说，一直非常流行的原因有如下四个：

1.强事务一致性，数据库的ACID(原子性、一致性、隔离性、持久性)保障了所有记录的数据全是准确的，对于早期互联网来说，大家都不完全信任看不到摸不着的东西，所以这个特点非常重要;

2.容易理解，二维表的结构非常贴合现实世界。

3.使用方便，通用的sql语言使得操作关系型数据库非常方便;

4.容易维护，在设计的时候采用了实体完整性、参照完整性等理念，减少了数据冗余和数据不一致。常用的关系型数据库有Mysql、Oracle等。

然而随着互联网海量数据的增加，关系型数据库也产生了瓶颈，具体表现如下：

1.无法应对高并发的读写请求，关系型数据库是以行结构来存储的，比如我们想获取某个地域的用户名单，需要按行读取，再获取其中的用户名字这一属性，对于磁盘的IO消耗非常大;

2.无法弹性伸缩，关系型数据库无法像webserver那样简单的通过增加更多的硬件和服务节点来扩展性能，对于数据库海量剧增的今天、服务需要24小时提供的企业来说，这非常难受;

3.不再需要事务强一致性、读写实时性，早期这是关系型数据库的优点，而随着互联网业务覆盖范围的广泛，用户可以接受一定的延迟、一定的错误。

因此NoSQL关系型数据库出现了，作为关系型数据库的补充，再根据互联网时代的需求不同，可以分为：

支持高性能并发读写的Key-Value数据库，如Redis;

支持海量数据访问的文档数据库，如MongoDB、CouchDB;

支持大数据存储和分析的列式数据库，如HBase;

支持全文搜索的搜索引擎数据库，如ElasticSearch。

数据库的使用根据具体的业务场景而确定，毫无疑问，涉及交易场景，关系型数据库是必不可失的，因为我们要求数据必须一致，不能允许任何的差错出现。在大部分互联网企业中，一般是SQL与NoSQL配合使用。现以某高速发展的电商网站来聊聊如何技术选型?

从业务类型来看，电商具备用户量&订单量高速增长、网站延迟低、对部分数据准确性要求高的特点，因此需要数据库能支持高读写的并发量、低延迟高吞吐、安全稳定、高可用的特点。从数据类型来看，包含用户个人信息数据、商品信息数据、交易数据三类，对于交易数据需要保证不能出错，而其它类数据则要求能存储不出错。从数据驱动运营的角度来看，未来会利用用户在平台产生的所有数据进行数据分析、智能推荐、二次营销等。综上所述，我们选择的数据库是MySQL与MongoDB。

选择MySQL毫无疑问是为了保证业务核心数据如用户信息、交易数据等不能出错，这是关系型数据库的最大优势。选择MongoDB则是因为其高可用、文档模型的特点。关于高可用，首先MongoDB的架构是primary、secondary模式，一个主节点接受server的读写，两个从节点同步primary主节点的数据，当主节点发生故障时，从节点进行选举，产生新的主节点，从而保障了业务的高可用。

其次MongoDB支持数据分片，当业务量急速扩展时，原先部署数据库的五台服务器就不够了，现在需要增加服务器节点数，对于Mysql来说，采用分库分表就可以解决问题，对于MongoDB则是通过将一个集合上的数据按片键分到不同的分片上，减少同一个数据文件上的数据量，再通过配置文件将数据引向不同的分片即可。

最后MongoDB支持文档模型，可以根据业务数据类型的变化来去增加或删减字段，而不需要按照确定的表结构去增加删除。比如在Mysql中，当一个用户填写了家里的收货地址、公司收货地址、朋友收货地址等多个地址时，需要建立联系人表、地址表将其关联，而在MongoDB中只需要一个集合就可以搞定了。

在数据库选型我们都需要考虑数据量、并发量、实时性、一致性、读写分布、数据类型、安全性、运维成本都指标，常见的系统数据库选型如下所示：

现在假设你在主导或参与一个系统的开发，相信你已经非常清楚如何选型数据库、如何应对后续出现的问题了吧?知其然知其所以然～