• Like
Nosql理论
Upcoming SlideShare
Loading in...5
×

Nosql理论

  • 1,578 views
Uploaded on

nosql理论基础,从mysql架构变化到CAP,BASE

nosql理论基础,从mysql架构变化到CAP,BASE

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,578
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
45
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Hello , NOSQL 2011-4-12
  • 2. About me 常优 www.auu.name weibo.com/changyou52 网络电视事业部
  • 3.
    • CAP 理论
    • 什么是 NOSQL?
    • 为什么使用 NOSQL?
    • 从 MYSQL 到 NOSQL
    • 从 AICD 到 BASE
    • 4. 代替 mysql ?
    分享
  • 4. CAP 理论 一致性 可用性 分区容忍性 consistency 一致性 availability 可用性 tolerance of network partition 分区容错性 一个分布式系统不可能满足一致性、可用性、分区容错性这三个需求;最多只能同时满足两个。 C A P
  • 5.
    • Next Generation Databases mostly addressing some of the points :
    • being non-relational
    • distributed
    • open-source
    • horizontal scalable
    What is NOSQL ?
  • 6. Why NOSQL ?
    • 时髦?
    • 系统瓶颈带来的革命
    • 从 MYSQL 开始
  • 7. MYSQL 应用层 读 写
    • 优化表结构
    • 优化 sql 语句
    • 优化索引
    • 优化 query cache
    • 优化存储引擎
    2. memcached 3. replication 4 . sharding 1. mysql
  • 8. Mysql memcache 读 写 读缓存失败 应用层 删除 / 更新
    • 好处:
    • 简单易用
    • 不用调整数据库相关架构
    • 坏处:
    • 应用层的代码量增加
    • 维护时的系统复杂度增加
    2. memcached 3. replication 4 . sharding 1. mysql 方式 I > 作为 cache 工具
  • 9. Mysql memcached 读 写 删除 / 更新 / 写 读缓存失败 应用层
    • 通过 UDF 调用 memcached API 实现数据的写入,更新,删除
    2. memcached 3. replication 4 . sharding 1. mysql 方式 II > 和 mysql 整合,作为一个整体对外提供服务
  • 10. 2. memcached 3. replication 4 . sharding 1. mysql
    • 基于 libevent
    • LRU 算法保证了 “热门数据”的缓存
    • 仅当无空间才会进行数据清除
    • 新浪开源: Memcached DB=BerkeleyDB+ Memcached (持久化)
  • 11. node K node
    • 哈希算法:
    • 应用层的负载均衡算法 ( 无法满足增加节点后的缓存命中率)
    K node K K node K K hash(K) % N   node K K node K K node K K K K hash(K) % N+1   MYSQL MYSQL 2. memcached 3. replication 4 . sharding 1. mysql
  • 12. 32 0 ~ 2 node node node node 32 0 ~ 2 node node node node node
    • 一致性哈希算法:
    • 在 增加 / 减少 服务器时降低数据移动规模,让尽可能多的数据保留在原有服务器上
    2. memcached 3. replication 4 . sharding 1. mysql
  • 13. 32 0 ~ 2 node node node node
    • 分布式一致性哈希算法:
    • 在大数据量的分布式环境中,将 数据迁移 的压力均匀分散到各个节点
    node node node node node node node node node node node node node node node Hash 算法 2. memcached 3. replication 4 . sharding 1. mysql
  • 14. 应用层 Master slave slave slave repl 写 读
    • 主 - 从
    • 通过读写分离解决部分写压力
    2. memcached 3. replication 4 . sharding 1. mysql 从库故障解决 主库故障解决
  • 15. 应用层 Master A slave slave slave 写 读 Master B repl repl 2. memcached 3. replication 4 . sharding 1. mysql
    • 双主 - 从
    • 提高系统容错性
  • 16. 2. memcached 3. replication 4 . sharding 1. mysql
    • Relication 的问题:
    • 延迟
    • 大数据量下的扩展性 ( 从库读锁阻塞写请求 )
  • 17.
    • 垂直切分 ( 适合耦合度低,业务逻辑清晰的场景 )
    应用层 user message group events 垂直切分 DB 2. memcached 3. replication 4 . sharding 1. mysql
  • 18. Id%3 Id%3 Id%3 DB 水平切分 应用层 2. memcached 3. replication 4 . sharding 1. mysql
    • 水平切分 (需要找到各表能够相关联的字段,根据某算法进行切分 )
  • 19. 2. memcached 3. replication 4 . sharding 1. mysql
    • 使用中间层来屏蔽应用程序的复杂性
    Amoeba Mysql proxy
  • 20.
    • 扩展性差强人意
    • 跨表 JOIN 效率低下
    • 应用层越来越复杂
    • 在线 DDL 如同噩梦
    瓶颈依旧存在!
  • 21. 再看看 CAP
    • 实现一个满足最终一致性 (Eventually Consistency) 和 AP 的系统是可行的
    • 对所有的数据访问,总返回一个结果 
    • 如果期间没有报文丢失,那么返回一个满足 consistency 要求的结果  
    • 现实中的一个例子是 Cassandra 系统
    • 朝 A 、 P 的方向设计,然后通过其它手段保证一致性
  • 22. BASE ACID
    • Atomicity [ 原子性 ]
    • Consistency [ 一致性 ]
    • Isolation [ 隔离性 ]
    • Durability [ 持久性 ]
    • Basically Available [ 基本可用 ]
    • Soft state [ 软状态 ]
    • Eventually consistent [ 最终一致 ]
    ACID & BASE 在单机里 ACID 是数据的属性,而在分布式环境中, BASE 就是数据的属性
  • 23. NOSQL 2. memcached 3. replication 4 . sharding 1. mysql ACIC BASE
    • 最终一致性代替强一致性,提升系统可用性,扩展性
  • 24. NOSQL 参考
    • Amazon Dynamo
    • Gossip
      • 每个节点都随机地与其他节点通信,经过一番杂乱无章的通信,最终所有节点的状态都会达成一致
      • Gossip 是一个带冗余的容错算法,更进一步, Gossip 是一个最终一致性算法 。
    #!/usr/bin/env python example.py import mincemeat data = [ "Humpty Dumpty sat on a wall", "Humpty Dumpty had a great fall", "All the King's horses and all the King's men", "Couldn't put Humpty together again", ] def mapfn(k, v): for w in v.split(): yield w, 1 def reducefn(k, vs): result = 0 for v in vs: result += v return result s = mincemeat.Server() # The data source can be any dictionary-like object s.datasource = dict(enumerate(data)) s.mapfn = mapfn s.reducefn = reducefn results = s.run_server(password="changeme") print results
    • Map / Reduce
      • Map :将大的计算量分片,以便并行计算
      • Reduce :将并行计算的结果进行组合,
      • 以便得到一个最终的输出
    MapReduce 的 python 实现: sh# python example.py 另起终端运行: sh# python mincemeat.py -p changeme localhost {‘a’: 2, ‘on’: 1, ‘great’: 1, ‘Humpty’: 3, ‘again’: 1, ‘wall’: 1, ‘Dumpty’: 2, ‘men’: 1, ‘had’: 1, ‘all’: 1, ‘together’: 1, “King’s”: 2, ‘horses’: 1, ‘All’: 1, “Couldn’t”: 1, ‘fall’: 1, ‘and’: 1, ‘the’: 2, ‘put’: 1, ’sat’: 1}
  • 25. 代替 MYSQL ?
    • NOSQL 应用场景少
    • Mysql 依然可以搭建可扩展架构
    • 性能只是架构的一部分
    • KISS 原则 keep it sample stupid
    • 没有最好的架构,只有最合适的架构
    • NOSQL = Not Only SQL
  • 26. NOSQL 选择
    • 各种异常是否会丢失数据?
    • 何种一致性策略?
    • 系统的可控性?
    • 社区支持度?
  • 27. Thanks