网站架构演变-NoSQL引入

NoSQL

not only sql

架构演变

数据存储

商品基本信息：关系型数据库
商品描述、详情、评价信息（多文字类）：文档数据库 MongDB
商品图片：分布式文件系统
商品关键字：ISearch
商品波段性热点高频信息：Redis

UDSL：统一数据服务平台，由于数据存储涉及的技术繁杂，为统一用此平台，开发只需通过UDSL统一使用来处理不同数据存储

NoSQL VS rdbs

以一个电商客户、订单、支付、地址模型来对比关系型数据库和非关系型数据库

关系型数据库：客户表、地址表、订单表、订单明细表、支付明细表，各表之间通过1：1、1：N、N：N，主外键、范式等进行关联。

非关系型数据库：通过BSon可以描述为一个json字符串；

聚合模型

NoSQL用聚合模型，来着重解决两个难题：
高并发的场景不太建议有关联查询；
分布式事务支持不了太多的并发

聚合模型数据类型：
1.KV键值
2.Bson
3.列簇
4.图形

NoSQL分类

1.kv键值：
新浪：BerkeleyDB+redis
美团：redis+tair
阿里、百度：memcache+redis
2.文档型数据库(bson格式较多)：
CouchDB
MongoDB
3.列存储数据库：
Cassandra
HBase
分布式文件系统
4.图关系数据库：针对关系图谱，如社交、广告推荐等
Neo4J
InfoGrid

CAP+BASE

传统ACID：以下4个特性全能满足
原子性-Atomicity：事务里的操作，要么全做完，要么全不做；
一致性-Consistency：数据库要一直处于一致的状态；
独立性-Isoiation：并发的事务之间不会相互影响；
持久性-Durability：存储持久，重启不会丢失

CAP：一个分布式系统不可能同时很好的满足下面3个需求
强一致性-Consistency：
高可用性-Availability：
分区容错性-Partition tolerance：

CA：单点集群，可扩展性不太强大（RDBMS）
CP：（MongoDB、HBase、Redis）-本身不支持高可用，可通过其它方案实现
AP：一致性要求较低，实现最终一致性

由于当前的网络硬件肯定会出现延迟丢包问题，所以P是必须要实现的；
一般都使用AP+弱一致性（最终一致性）

BASE：让系统放松某一时刻数据的一致性的要求，来换取系统整体的伸缩性和性能上的改观。

分布式、集群

分布式：不同的多台服务器上部署不同的服务模块，他们内部通国通信，对外提供服务和内部协作
集群：不同的多台服务器上面部署相同的服务模块

Redis

对redis的理解：
1.kv
2.cache
3.persistence

横向扩展：通过增加节点
纵向扩展：通过增加服务器配置等