在南京第一次写博客
一、数据库架构发展历程
单机MySQL的美好年代
在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网
页，动态交互类型的网站不多。
上述架构下，我们来看看数据存储的瓶颈是什么？
- 数据量的总大小 一个机器放不下时
- 数据的索引（B+ Tree）一个机器的内存放不下时
- 访问量(读写混合)一个实例不能承受
Memcached(缓存)+MySQL+垂直拆分
后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅
仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构
和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文
件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常
时尚的技术产品。
Memcached作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在
Memcached服务器上，又发展了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性
hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存失效的弊端
Mysql主从复制读写分离
由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重
负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的masterslave模式成为这个时候的网站标配了。
分表分库+水平拆分+mysql集群
在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，
而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使
用InnoDB引擎代替MyISAM。
同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面
试的热门问题也是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实
力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但性能也不能很好满足互联网的要求，只是在
高可靠性上提供了非常大的保证。
二、MySQL的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容
易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将
变得非常的小。关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技
术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
alter table add Colum
三、为什么要使用NOSQL NOT ONLY SQL
为什么使用NoSQL ?
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交
网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL
数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。
NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”， 泛指非关系型的数据库。随着互联网web2.0网站的兴
起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力
不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数
据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的
存储。
四、传统RDBMS VS NOSQL
RDBMS vs NoSQL
RDBMS SQL
高度组织化结构化数据
结构化查询语言（SQL）
数据和关系都存储在单独的表中。
数据操纵语言，数据定义语言
严格的一致性
基础事务
NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
-键 - 值对存储，列存储，文档存储，图形数据库
最终一致性，而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能，高可用性和可伸缩性
五、NOSQL数据库的类型
六、阿里巴巴中文站商品信息如何存放
看看阿里巴巴中文网站首页 以女装/女包包为例
商品基本信息
名称、价格，出厂日期，生产厂商等
关系型数据库：mysql/oracle目前淘宝在去O化(也即拿掉Oracle)，注意，淘宝内部用的Mysql是里面的大牛自己改
造过的
为什么去IOE
IBM小型机 廉价的PC机
oracle数据库 myql
EMC存储
集中式------>分布式
2008年，王坚加盟阿里巴巴成为集团首席架构师，即现在的首席技术官。这位前微软亚洲研究院常务副院长被马
云定位为：将帮助阿里巴巴集团建立世界级的技术团队，并负责集团技术架构以及基础技术平台搭建。
在加入阿里后，带着技术基因和学者风范的王坚就在阿里巴巴集团提出了被称为“去IOE”（在IT建设过程中，去除
IBM小型机、Oracle数据库及EMC存储设备）的想法，并开始把云计算的本质，植入阿里IT基因。
王坚这样概括“去IOE”运动和阿里云之间的关系：“去IOE”彻底改变了阿里集团IT架构的基础，是阿里拥抱云计算，
产出计算服务的基础。“去IOE”的本质是分布化，让随处可以买到的Commodity PC架构成为可能，使云计算能够落
地的首要条件。
推荐阅读：《阿里云这群疯子》
商品描述、详情、评价信息(多文字类)
多文字信息描述类，IO读写性能变差
文档数据库MongDB中
商品的图片
流媒体服务器
分布式的文件系统中
淘宝自己的TFS
Google的GFS
Hadoop的HDFS
商品的关键字
搜索引擎，淘宝内用
ISearch
扫地僧
商品的波段性的热点高频信息
内存数据库
Tair、Redis、Memcache
商品的交易、价格计算、积分累计
外部系统，外部第3方支付接口
支付宝
大型互联网应用(大数据、高并发、多样数据类型)的难点和解决方案
难点
数据类型多样性
数据源多样性和变化重构
数据源改造而数据服务平台不需要大面积重构
解决办法
阿里、淘宝干了什么？UDSL
是什么
什么样
映射
API
热点缓存
七、数据的水平拆分和垂直拆分
当我们使用读写分离、缓存后，数据库的压力还是很大的时候，这就需要使用到数据库拆分了。
数据库拆分简单来说，就是指通过某种特定的条件，按照某个维度，将我们存放在同一个数据库中的数据分散存放
到多个数据库（主机）上面以达到分散单库（主机）负载的效果。
切分模式： 垂直（纵向）拆分、水平拆分。
垂直拆分
一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据
库上面，这样也就将数据或者说压力分担到不同的库上面，如下图：
优点： - 拆分后业务清晰，拆分规则明确。
- 系统之间整合或扩展容易。
- 数据维护简单。
缺点： - 部分业务表无法join，只能通过接口方式解决，提高了系统复杂度。
- 受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
- 事务处理复杂。
水平拆分
垂直拆分后遇到单机瓶颈，可以使用水平拆分。相对于垂直拆分的区别是：垂直拆分是把不同的表拆到不同的数据
库中，而水平拆分是把同一个表拆到不同的数据库中。
相对于垂直拆分，水平拆分不是将表的数据做分类，而是按照某个字段的某种规则来分散到多个库之中，每个表中
包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行的切分，就是将表中 的某些行切分到
一个数据库，而另外的某些行又切分到其他的数据库中，主要有分表，分库两种模式，如图：
优点： - 不存在单库大数据，高并发的性能瓶颈。
- 对应用透明，应用端改造较少。
- 按照合理拆分规则拆分，join操作基本避免跨库。
- 提高了系统的稳定性跟负载能力。
缺点： - 拆分规则难以抽象。
- 分片事务一致性难以解决。
- 数据多次扩展难度跟维护量极大。
- 跨库join性能较差。
拆分的处理难点
两张方式共同缺点 - 引入分布式事务的问题。
- 跨节点Join 的问题。
- 跨节点合并排序分页问题。
针对数据源管理，目前主要有两种思路：
A. 客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，直接访问各个 数据库，在
模块内完成数据的整合。
优点：相对简单，无性能损耗。
缺点：不够通用，数据库连接的处理复杂，对业务不够透明，处理复杂。
B. 通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
优点：通用，对应用透明，改造少。
缺点：实现难度大，有二次转发性能损失。
拆分原则 - 尽量不拆分，架构是进化而来，不是一蹴而就。(SOA)
- 最大可能的找到最合适的切分维度。
- 由于数据库中间件对数据Join 实现的优劣难以把握，而且实现高性能难度极大，业务读取 尽量少使用多表Join -
尽量通过数据冗余，分组避免数据垮库多表join。 - 尽量避免分布式事务。
- 单表拆分到数据1000万以内。
切分方
范围、枚举、时间、取模、哈希、指定等
案例分析
场景一
建立一个历史his系统，将公司的一些历史个人游戏数据保存到这个his系统中，主要是写入，还有部分查询，读写
比约为1:4；由于是所有数据的历史存取，所以并发要求比较高；
分析：
历史数据
写多都少
越近日期查询越频繁？
什么业务数据？用户游戏数据
有没有大规模分析查询？
数据量多大？
保留多久？
机器资源有多少？
方案1：按照日期每月一个分片
带来的问题：1.数据热点问题（压力不均匀）
方案2：按照用户取模， --by Jerome 就这个比较合适了
带来的问题：后续扩容困难
方案3：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
场景二
建立一个商城订单系统，保存用户订单信息。
分析：
电商系统
一号店或京东类？淘宝或天猫？
实时性要求高
存在瞬时压力
基本不存在大规模分析
数据规模？
机器资源有多少？
维度？商品？用户？商户？
方案1：按照用户取模，
带来的问题：后续扩容困难
方案2：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
方案3：按省份地区或者商户取模
数据分配不一定均匀
场景3
上海公积金，养老金，社保系统
分析：
社保系统
实时性要求不高
不存在瞬时压力
大规模分析？
数据规模大
数据重要不可丢失
偏于查询？
方案1：按照用户取模，
带来的问题：后续扩容困难
方案2：按用户ID范围分片（1-1000万=分片1，xxx）
带来的问题：用户活跃度无法掌握，可能存在热点问题
方案3：按省份区县地区枚举
数据分配不一定均匀
322
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
