NoSQL(Not only SQL):不仅仅是SQL,泛指非关系型数据库,是对不同于传统的关系型数据库的数据库管理系统的统称。用于超大规模数据的存储,这些类型的数据存储不需要固定的模式,无需多余操作就可以横向扩展。
如今我们可以通过第三方平台(如:百度,QQ等)可以很容易的访问和抓取数据。用户的个人信息,社交网络,地理位置,用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘,那SQL数据库已经不适合这些应用了, NoSQL数据库的发展却能很好的处理这些大的数据。
关系数据库管理系统(Relational Database Management System):管理关系数据库,并将数据逻辑组织的系统。
1.原子性(Atomicity) 事务里的所有操作要么全部做完,要么都不做,事务成功的条件是事务里的所有操作都成功,只要有一个操作失败,整个事务就失败,需要回滚。 2.一致性(Consistency) 数据库要一直处于一致的状态,事务的运行不会改变数据库原本的一致性约束。 3.隔离性(Isolation) 并发的事务之间不会互相影响,如果一个事务要访问的数据正在被另外一个事务修改,只要另外一个事务未提交,它所访问的数据就不受未提交事务的影响。 4.持久性(Durability) 一旦事务提交后,它所做的修改将会永久的保存在数据库上,即使出现宕机也不会丢失。
CAP定理:又称为布鲁尔定理,指出对于一个分布式计算系统,不可能同时满足以下三点
1.一致性(Consistency) 在分布式系统中的所有数据备份,在同一时刻具有相同的数据。 2.可用性(Availability) 保证每个请求不管成功或者失败都有响应 3.分区容错性(Partition tolerance) 系统中任意信息的丢失或失败不会影响系统的继续运作
一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。
因此,根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三大类:
BASE(Basically Available, Soft-state, Eventually Consistent):是对 CAP 中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性
1.Basically Available(基本可用) 分布式系统在出现故障的时候,允许损失部分可用性,即保证核心功能或者当前最重要功能可用。对于用户来说,他们当前最关注的功能或者最常用的功能的可用性将会获得保证,但是其他功能会被削弱。 2.Soft-state(软状态) 允许系统数据存在中间状态,但不会影响到系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步时存在延时。 3.Eventually Consistency(最终一致性) 要求系统数据副本最终能够一致,而不需要实时保证数据副本一致。最终一致性是弱一致性的一种特殊情况。最终一致性有5个变种:因果一致性,读己之所写(例如发微博的时候,自己可以马上看到,但是粉丝要过几秒钟),会话一致性,单调读一致性,单调写一致性。
使用键值(key-value)对存储的数据库 可以通过key快速查询到value, 一般不需要考虑value的格式 应用场景:内容缓存(存储用户信息,参数,购物车) 典型代表:Redis
以列相关存储架构进行数据存储的数据库 方便存储结构化和半结构化数据,方便做数据压缩,对针对某一列或者某几列的查询有非常大的IO优势 应用场景:批量数据存储与即时查询 典型代表:HBase
是旨在将半结构化数据存储为文档的一种数据库 文档数据库通常以 JSON 或 XML 格式存储数据。读取一个JSON中不存在的字段也不会导致SQL那样的语法错误,可以解决关系型数据库表结构schema扩展不方便的问题 应用场景:由于文档数据库的no-schema特性,可以存储和读取任意数据 典型代表:MongoDB
图形数据库应用图形理论存储实体之间的关系信息 应用场景:关系型数据库用于存储“关系型”数据的效果并不好,其查询复杂、缓慢、超出预期,而图形数据库的独特设计恰恰弥补了这个缺陷,解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。 典型代表:Neo4j
除了以上四种,还有全文搜索引擎,通过索引来达到快速查询的目的,来解决关系型数据库全文搜索功能较弱的问题。典型代表是Elasticsearch
https://www.runoob.com/mongodb/nosql.html