NOSQL-了解当下
概述
Evolution
- 单机版MySQL
在90年,更多是静态页面,而动态交互类型的网站不是那么多,一个网站的访问量不是很大,用单个数据库完全可以轻松应对.
架构图:
此架构数据存储的瓶颈是什么?
- 数据量大小,一个机器放不下时.
- 数据的索引(B+Tree),一个机器内存放不下时.
- 访问量(读写混合),一个实例不能承受.
- 出现这么多问题,那么我们就需要进化了
- Memcached(缓存)+MySQL+垂直拆分
后来,随着访问量的上升,几乎大部分使用MySQL架构的网站在数据库上开始出现了性能的问题,WEB程序不再仅仅专注功能上,同时也在最求性能,优化数据库的结构和索引.
开始比较流行的是通过文件缓存来缓解数据库压力,但是当访问量剧增的时候,多台WEB服务器通过文件缓存就不能共享了,大量的文件缓存同时也带来了高的IO压力.
在这个时候,Memcached就上场了. - MySQL主从读写分离
由于数据库的写压力增大,然而Memcached只能缓存读取的压力,大部分网站开始使用主从复制的技术来达到读写分离,减轻数据库压力,和读库的可扩展性,MySQL的master-slave模式成为了这个时候的网站标配了.
- 分表分库+水平拆分+MySQL集群
在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,此时MySQL主库的写压力开始出现瓶颈,然而数据量持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM.
同时,开始流行使用分表分库来缓解写压力和数据增长的扩张问题,这个时候,分表分库成了一个热门技术,同时,MySQL推出了表分区,MySQL Cluster集群,但性能也不能很好满足互联网要求,只是高可靠性上提供了非常大的保证.
- MySQL的扩展性瓶颈
MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库.关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。
what do we use?Now
Why use NOSQL?
今天我们可以通过第三方平台（如：Google,Facebook等）可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。
