传统数据库如Mysql、Oracle的出现解决了早期互联网对于数据存储、数据一致性的问题，但随着互联网、物联网的快速发展而导致对数据存储的要求不只是数据一致性，还有了更多特性需求。传统数据库有几个缺点：在大数据场景下读取IO较高、无法存储灵活的数据结构、表结构扩展不方便、全文搜索功能较弱（使用索引效率低）、不擅长出复杂关系型数据库，因此非关系型数据库NoSQL是极好的解决方案。作为关系型数据库的补充，再根据互联网时代的需求不同，NoSQL可以分为：支持高性能并发读写的Key-Value数据库，如Redis；支持海量数据访问的文档数据库，如MongoDB、CouchDB；支持大数据存储和分析的列式数据库，如HBase；支持全文搜索的搜索引擎数据库，如ElasticSearch。Key-Value数据库所谓KV数据库就是按照键值对进行存储的数据库，key是数据的标识，value是数据的值。Redis是典型的KV数据库，可以存储string、hash、list、set等数据结构。我们以微博清除历史粉丝为例，对于redis来说，只要使用RPOPkey从队列的右边出队一个元素就可以了。是不是很简单？但如果是关系数据库就比较复杂了，因为关系型数据库是行式存储，所以在建表时每条数据除了有数字编号之外，还有位置编号，用于判断数据是否第一条，其次通过sql语句找到了第一条数据之后，再次执行sql删除语句，最后更新从第二条开始的所有数据的位置编号。可以看到关系型数据库需要进行多次SQL操作，实现非常麻烦，效率低，性能低。Redis数据库的主要缺点是不支持完整的ACID事务，但其实大部分业务也不需要严格遵守ACID原则，比如刚刚的微博粉丝案例，少一个或多一个粉丝对于我们并没有什么影响。文档数据库所谓文档数据库就是可以存储和读取任意的数据，在使用之前不需要定义字段，读取某个不存在的字段也不会报错，目前大部分文档数据库存储的数据格式是JSON，可以支持比较复杂的数据结构，MongoDB是典型的文档数据库。比如一个商品信息管理系统，商品的信息有商品ID、生产日期、品牌、货号、口味、包装方式、净含量、产地、生产许可证编号、厂名、配料表、存储方法、保质期、食品添加剂。其中口味是一个列表（因为口味可以有多个），产地是一个结构（包含省市区具体地址），保质期包含包装方式、生产日期、存储时长等。如果使用文档数据库，一个JSON就可以完全描述。如果使用关系型数据库，则需要设计多张表并且关联起来，包含基本信息（有商品ID、价格、品牌三列）、地址（有省份、市区、乡镇、小区、门牌号四列）、配料表（有鸡蛋、面粉、食盐、添加剂等多列），表创建后再使用Join将所有的内容关联起来，最终形成一个商品信息提供给到用户。文档数据库有两个缺点。缺点之一是不支持事务操作，比如使用MongoDB来存储商品库存，用户付款、减库存属于一个事务操作，用关系型数据库就很简单，如果使用MongoDB来实现，就可能出现库存减了但是用户没有付款的情况。缺点之二是不支持join操作，比如我们想查询购买了陈克明面条中的女性用户，使用关系型数据库，将用户信息表和订单表通过用户ID来join操作就可以了，如果使用MongoDB，则需要查询订单表中买了陈克明面条的用户，再查询用户中的女性用户。列式数据库所谓列式数据库就是按照列来存储数据的数据库，传统的关系型数据库是按行来存储在磁盘，即行式数据库，典型的列式数据库是HBase。怎么理解行式和列式存储呢？以某个用户信息登记表来说，按行存储是二维表格中的每一行占据一块连续的存储空间，按列存储则是每一列占据一块连续的存储空间。所以列式存储数据库非常适合大数据分析场景。比如我们想分析某个区域的平均身高和体重，在mysql数据库中需要获取到每行的身高、体重数据，再来求平均，如果有个人，就需要请求磁盘空间次；在hbase数据库中我们只需要请求两次，获取身高和体重这一列的数据求平均即可。中期的时候是敏捷开发模型。因为互联网上涌入的网民开始增多，大家的
转载请注明：http://www.aierlanlan.com/cyrz/6623.html
