Sql的发展历程 单机mysql的年代
在很早的年代，一个网站的访问量不会太大，单个数据库（Mysql）完全够用 瓶颈：
①数据量太大时一个机器放不下
②数据超过300万，需要建立索引，机器内存也放不下
③访问量比较大（读写混合），服务器承受不了，性能差
Memcached（缓存）+ MYSQL + 垂直拆分（读写分离）读操作比较多，为了减轻数据库的压力，我们可以使用缓存来保证效率 发展过程： 优化数据结构和索引——》文件缓存（IO）——》Memcached
分库分表 + 水平拆分 + mysql集群MyISAM：表锁，效率低，高并发下出现锁问题——》Innodb：行锁。 早些年通过分库分表来解决写的压力（Mysql集群）
现今Mysql等关系型数据库就不够用了，有的使用mysql存储博客、图片等大文件，造成了数据库表很大，效率就低了，如果有一种可以专门处理这类数据的数据库，Mysql的压力就小了（开始研究）,在大数据IO下，表结构几乎无法修改
目前一个基本的互联网项目 什么是NoSql？NoSql = Not Only Sql（不仅仅是sql），泛指非关系型数据库
（关系型数据库：表格（行和列））
随着Web2.0互联网的诞生，传统的关系型数据库很难对付web2.0时代，尤其是超大规模的高并发的社区，暴露出来很多难以克服的问题，NoSQL在当今大数据的情况下发展十分迅速，Redis是发展最快的
用户的个人信息，社交网络，地理位置，用户自己产生的数据等类型的存储不需要一个固定的格式，不需要多余的操作就可以横向拓展（Map<String,Object>）
为什么要用NoSql？用户的个人信息，社交网络，地理位置，用户自己产生的数据，用户的日志爆发增长，此时无法使用关系型数据库，这时我们就要用Nosql来处理以上的情况
NoSql的特点①方便扩展，数据之间没有关系，很好扩展
②大数据量高性能，Redis一秒写8万次，读取11万次，NoSql的缓存记录级的，是一种细粒度的缓存，性能高
③数据类型是多样型的，不需要事先设计数据库，随取随用，对于关系型数据库，如果是数据库量十分大的表，就很难设计了
传统RDBMS和NoSql传统的RDBMS：
结构化组织SQL数据和关系都存储在单独的表中操作增删改查，数据定义语言严格的一致性基础的事务操作。。。NoSql：
不仅仅是数据
没有固定的查询语言
键值对存储，列存储，文档存储，图形数据库
最终一致性
CAP定理和BASE（异地多活）
高性能，高可用，高可扩展
。。。。
3V+3高大数据时代的3V：主要是描述问题的
海量Volume多样Variety实时Velocity大数据时代的3高：主要是对程序的要求
高并发高可拓展高性能在公司中的实践：NoSql+RDBMS一起使用
阿里巴巴演进分析# 商品的基本信息 - 名称、价格、商家信息，关系型数据库就可以解决（MYSQL/Oracle） - 淘宝内部的MYSQL不是大家用的MYSQL # 商品的描述、评论（文字较多） - 文档型数据库，MongDB # 图片 - 分布式文件系统 FastDFS、淘宝的TFS、Google的GFS、Hadoop的HDFS、阿里云的OSS # 商品的关键字（搜索） - 搜索引擎，solr、elasticsearch、淘宝用的ISerach # 商品热门波段信息 - 内存数据库，Redis、Tair、Memache... # 商品的交易、外部的支付接口 - 三分应用
大型互联网应用问题：
数据类型太多数据源繁多。经常重构数据要改造，大面积改造解决：
NoSql的四大分类KV键值对：
新浪：Redis美团：Redis+Tair阿里、百度：Redis、mecache文档型数据库（bson格式和json一样）：
MongoDB（一般必须掌握） MongoDB是一个基于分布式文件存储的数据库，C++编写，主要用来处理大量文档MongoDB是一个介于关系型数据库和非关系型数据库中间的产品，MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的 ConthDB列存储数据库：
HBase分布式文件系统图关系型数据库：
不是用来放图形的，放的是关系，比如：朋友圈社交网络，广告推荐Neo4j、InfoGrid 四者对比：
 1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。 |
