Redis
MySQL发展历史
MySQL的单机时代
90年代这时候,一个网站的访问量不算太大,单个数据库就足够了。
而且更多的是静态网页,服务器没有太大的压力。
这种情况下,整个服务架构的瓶颈是:
1、数据量太大一个机器放不下
2、访问量(读写混合),一个服务器承受不了
Memcached(缓存) MySQL 垂直拆分(读写分离)
网站80%的情况都是读数据,每次都要查询数据库的话就十分麻烦,为了减轻数据库服务器的压力,用缓存来保证效率。
发展过程:优化数据结构和索引(数据本身)->文件缓存(IO)->Memcached
分库分表 水平拆分 MySQL集群
数据库的本质:读写(用缓存来解决读的问题),随着业务量的增长,写也会出现问题
Innodb:行锁
用分库分表来解决写的问题,例如将系统的不同模块订单,用户,支付使用单独的数据库,最后做成微服务。
如今
如今数据类型和数据量暴增,比如定位,音乐,热榜都是数据类型,MySQL等关系型数据库已经不够用了。
如果用MySQL存储博客,图片等数据,数据库表很大,效率比较低,要有一种专门的数据库来存储这些数据。NoSQL数据库就是专门存储这些数据的。
目前的一个互联网项目架构
NoSQL
Not only SQL
很多数据例如用户的个人信息,社交网络,地理位置等,这些数据类型的存储并不需要一个固定的格式,即非关系型,且不需要多余的操作就能横向扩展。例如Map<String,Object>
特点
1、方便扩展(数据之间没有关系,很好扩展),解耦
2、大数据高性能 (Redis 写8W/S 读11W/s,NoSQL的缓存是记录级别的,是一种细粒度的缓存,性能高)
3、数据类型多样(不需要设计数据库,随取随用)
4、传统RDBMS与NoSQL
代码语言:javascript复制传统的RDBMS
-结构化组织
-SQL
-数据和关系都存储在单独的表里 row column
-严格的一致性
-事物
...
代码语言:javascript复制NoSQL
-不仅仅是数据
-没有固定的查询语言
-键值对存储,列存储,文档存储,图形数据库(社交关系)
-最终一致性
-CAP定理和BASE(异地多活)
-高性能,高可用,高扩展
...
大数据时代的3V和3高
代码语言:javascript复制3v
-海量 volume
-多样 variety
-实时 velocity
代码语言:javascript复制3高
-高性能
-高可用
-高扩展(随时可以水平拆分,增加服务器)
我的博客即将同步至腾讯云 社区,邀请大家一同入驻:https://cloud.tencent.com/developer/support-plan?invite_code=350xhb7vkoe88