• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Nosql理论
 

Nosql理论

on

  • 1,597 views

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

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

Statistics

Views

Total Views
1,597
Views on SlideShare
1,597
Embed Views
0

Actions

Likes
2
Downloads
45
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Nosql理论 Nosql理论 Presentation Transcript

    • Hello , NOSQL 2011-4-12
    • About me 常优 www.auu.name weibo.com/changyou52 网络电视事业部
      • CAP 理论
      • 什么是 NOSQL?
      • 为什么使用 NOSQL?
      • 从 MYSQL 到 NOSQL
      • 从 AICD 到 BASE
      • 4. 代替 mysql ?
      分享
    • CAP 理论 一致性 可用性 分区容忍性 consistency 一致性 availability 可用性 tolerance of network partition 分区容错性 一个分布式系统不可能满足一致性、可用性、分区容错性这三个需求;最多只能同时满足两个。 C A P
      • Next Generation Databases mostly addressing some of the points :
      • being non-relational
      • distributed
      • open-source
      • horizontal scalable
      What is NOSQL ?
    • Why NOSQL ?
      • 时髦?
      • 系统瓶颈带来的革命
      • 从 MYSQL 开始
    • MYSQL 应用层 读 写
      • 优化表结构
      • 优化 sql 语句
      • 优化索引
      • 优化 query cache
      • 优化存储引擎
      2. memcached 3. replication 4 . sharding 1. mysql
    • Mysql memcache 读 写 读缓存失败 应用层 删除 / 更新
      • 好处:
      • 简单易用
      • 不用调整数据库相关架构
      • 坏处:
      • 应用层的代码量增加
      • 维护时的系统复杂度增加
      2. memcached 3. replication 4 . sharding 1. mysql 方式 I > 作为 cache 工具
    • Mysql memcached 读 写 删除 / 更新 / 写 读缓存失败 应用层
      • 通过 UDF 调用 memcached API 实现数据的写入,更新,删除
      2. memcached 3. replication 4 . sharding 1. mysql 方式 II > 和 mysql 整合,作为一个整体对外提供服务
    • 2. memcached 3. replication 4 . sharding 1. mysql
      • 基于 libevent
      • LRU 算法保证了 “热门数据”的缓存
      • 仅当无空间才会进行数据清除
      • 新浪开源: Memcached DB=BerkeleyDB+ Memcached (持久化)
    • 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
    • 32 0 ~ 2 node node node node 32 0 ~ 2 node node node node node
      • 一致性哈希算法:
      • 在 增加 / 减少 服务器时降低数据移动规模,让尽可能多的数据保留在原有服务器上
      2. memcached 3. replication 4 . sharding 1. mysql
    • 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
    • 应用层 Master slave slave slave repl 写 读
      • 主 - 从
      • 通过读写分离解决部分写压力
      2. memcached 3. replication 4 . sharding 1. mysql 从库故障解决 主库故障解决
    • 应用层 Master A slave slave slave 写 读 Master B repl repl 2. memcached 3. replication 4 . sharding 1. mysql
      • 双主 - 从
      • 提高系统容错性
    • 2. memcached 3. replication 4 . sharding 1. mysql
      • Relication 的问题:
      • 延迟
      • 大数据量下的扩展性 ( 从库读锁阻塞写请求 )
      • 垂直切分 ( 适合耦合度低,业务逻辑清晰的场景 )
      应用层 user message group events 垂直切分 DB 2. memcached 3. replication 4 . sharding 1. mysql
    • Id%3 Id%3 Id%3 DB 水平切分 应用层 2. memcached 3. replication 4 . sharding 1. mysql
      • 水平切分 (需要找到各表能够相关联的字段,根据某算法进行切分 )
    • 2. memcached 3. replication 4 . sharding 1. mysql
      • 使用中间层来屏蔽应用程序的复杂性
      Amoeba Mysql proxy
      • 扩展性差强人意
      • 跨表 JOIN 效率低下
      • 应用层越来越复杂
      • 在线 DDL 如同噩梦
      瓶颈依旧存在!
    • 再看看 CAP
      • 实现一个满足最终一致性 (Eventually Consistency) 和 AP 的系统是可行的
      • 对所有的数据访问,总返回一个结果 
      • 如果期间没有报文丢失,那么返回一个满足 consistency 要求的结果  
      • 现实中的一个例子是 Cassandra 系统
      • 朝 A 、 P 的方向设计,然后通过其它手段保证一致性
    • BASE ACID
      • Atomicity [ 原子性 ]
      • Consistency [ 一致性 ]
      • Isolation [ 隔离性 ]
      • Durability [ 持久性 ]
      • Basically Available [ 基本可用 ]
      • Soft state [ 软状态 ]
      • Eventually consistent [ 最终一致 ]
      ACID & BASE 在单机里 ACID 是数据的属性,而在分布式环境中, BASE 就是数据的属性
    • NOSQL 2. memcached 3. replication 4 . sharding 1. mysql ACIC BASE
      • 最终一致性代替强一致性,提升系统可用性,扩展性
    • 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}
    • 代替 MYSQL ?
      • NOSQL 应用场景少
      • Mysql 依然可以搭建可扩展架构
      • 性能只是架构的一部分
      • KISS 原则 keep it sample stupid
      • 没有最好的架构,只有最合适的架构
      • NOSQL = Not Only SQL
    • NOSQL 选择
      • 各种异常是否会丢失数据?
      • 何种一致性策略?
      • 系统的可控性?
      • 社区支持度?
    • Thanks