Dreaming Infrastructure
    我的架构学习笔记

              邝宇恒
 http://randomtaste.appspot.com
About me

 Mail&GTalk: kuangyuheng@gmail.com
 Twitter: kyhpudding
 中山大学, 03CS本
 06年实习进入百度, 搜藏, 空间, 基础平台部
 刚刚加入腾讯广州研发中心
 本交...
Infrastructure
Infrastructure
                 可以用开源软件马上搭一个
Infrastructure
                 可以全部``云''掉
那我还讲啥?
Infrastructure's fun!

  选择一个基础架构
  组合, 利用, 优化: 这不仅是一堆开源软件
  或者一坨云
  有时候, 你得自己动手......
Just for fun :-)
Infrastructure components
                             For distributed web services
  机群部署运维
    自动部署与各种各样的监控
    服务定位和均衡
...
Outline

  讨论范围
    互联网应用, 更精确地: web 应用
    基于普通 PC Server 环境, 分布式系统
    以存储系统为讨论中心
  关于权衡
  基础架构设计理念
    Google, LiveJour...
It's all about trade-offs
容量可扩展             可用性

          可靠性
高吞吐

  It's all about trade-offs
一致性
                       易开发
   多快好省!         低延迟
CAP
Consistency, Availability, Partition
搞清你在做什么

我的行业
  稳定至上的银行业? 精益求精的搜索行业? 多快好省抢占
  地盘的SNS?
我的业务模式, 信息模型
  实时在线服务 vs. 线下分析, 读写比例?
  关系-存储-浏览, twitter/lifestream...
搞清我的位置
设计理念: Google 篇
设计理念: Google 篇
设计理念: Google 篇
设计理念: Google 篇
设计理念: Google 篇

BigTable
   Replication across IDC,
   eventually consistency
   服务端编程能力
设计理念: LiveJournal 篇
          LiveJournal: Behind The Scenes, Scaling Storytime
                                 Brad Fitz...
设计理念: LiveJournal 篇

 LAMM(emcache)P(erl)!
 高速成长, 从单机到数百台, scaling!
设计理念: LiveJournal 篇

 LAMM(emcache)P(erl)!
 高速成长, 从单机到数百台, scaling!
 数据库
   Scaling read: replication, master/slave
   Sca...
设计理念: LiveJournal 篇

 LAMM(emcache)P(erl)!
 高速成长, 从单机到数百台, scaling!
 数据库
   Scaling read: replication, master/slave
   Sca...
设计理念: LiveJournal 篇

 LAMM(emcache)P(erl)!
 高速成长, 从单机到数百台, scaling!
 数据库
   Scaling read: replication, master/slave
   Sca...
设计理念: 延伸, 经典模式

 RDBMS处理逻辑数据
    分离大段文本内容, 珍惜宝贵
    的DB资源
    Scaling: replication,
    sharding
 Key-Value存储存大数据
    简单, ...
设计理念: Yahoo! 篇

 众多的业务, 众多的需求
  门户, 搜索, 广告, 邮箱, 社区.....
  小数据, 大数据, 在线服务, 离线分析......
 众多的基础构建
  MySQL&Oracle
  UDB, YMDB, ...
设计理念: Yahoo! 篇
            Source: Key challenges in cloud computing
                          ...and the Yahoo! approach
...
设计理念: Yahoo! 篇

 在线服务
   依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移
   UDB: Dynamo like, YMDB: Media files
   Sherpa/PNUTS: 托管的可扩展,...
设计理念: Yahoo! 篇

 在线服务
   依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移
   UDB: Dynamo like, YMDB: Media files
   Sherpa/PNUTS: 托管的可扩展,...
小结: 设计里

 Google
    一层层构建的统一基础架构.
    真正的统一平台: 强大的平台极大降低创新门槛.
 LiveJournal
    快速扩展, 随需应变的典范.
    运用开源和自制软件的结合.
 Yahoo!
 ...
细节: GFS

 Key-Value存储
    Index, Log
    线下应用: 大块低并发写
    高吞吐远比低延迟重要
 简单设计: Single Master
    Master容量决定文件数目: 瓶
    颈? it ...
细节: BigTable

 That effort took many years...
 一张排序的大表
    线上应用, 类DB功能
    线下分析, 结构化数据
 With GFS
    GFS保证数据一致可靠
    Log-s...
幕后英雄: Chubby

 高可用: 如何保证主备一致和正确
 自动切换?
  主备严格同步确认&心跳
  当备连不上主时, 变成主
 当他们之间只是网络断掉
  当某些client只能连上其中一台
  不一致的双 master
 当主备连不...
幕后英雄: Chubby

 增加到3台
   提交至少得到其他1台确认
   使任何操作都得到多数派确认
 slave连不上master, 发起选举
   投票结果取决于另一台slave与master
   的连通
   失败: 发起的sla...
幕后英雄: Chubby

 每个服务都得来这么一回?
 简单点: 锁文件
   Master对共享文件加锁, 保证只有一个
   master写
 如何切换: 租约: Lease
   30secs etc, master到期续约
   续约...
细节: 论文之后......

  GFS的问题
    master 单点故障: 从手工恢复到使用 chubby
    master 文件数量上限
       不同的应用模式: 小文件, 大文件量, 从打包到BigTable
      ...
细节: Dynamo
               Amazon's ``always writable'' data storage

 Key-Value存储
 Always writable
    事关核心价值: 一次失败的"加
   ...
细节: Dynamo
               Amazon's ``always writable'' data storage

 CAP: N vs. R+W
    可配置的R,W&N, 满足不同需求.
 Eventually co...
细节: Sherpa/PNUTS
         Yahoo!’s Hosted Data Serving Platform
细节: Sherpa/PNUTS

 Hosted: the cloud
 模型: 结构化数据表
   在线服务, 小对象, 低延迟, 高并发
   单条更新, 灵活查询. Sorted, hash皆支持
 一致性模型, per-record ...
小结: 细节

 分布式系统
   异步不可靠传输, 无一致时序是天然特性, 别想逃避.
   Time, Clocks, and Ordering of Events in a Distributed System
   Fallacies ...
Lessons Learned
DO NOT Design for scalability
DO NOT Design for scalability at first
DO NOT Design for scalability at first

  ``可扩展'' 是有代价的
    受限的查询能力
    CAP: 宽松的一致性模型让开发者迷惑
  不要在还没成长的时候担负成长的烦恼.
    为赋新辞强...
DO NOT Design for scalability at first

  ``可扩展'' 是有代价的
    受限的查询能力
    CAP: 宽松的一致性模型让开发者迷惑
  不要在还没成长的时候担负成长的烦恼.
    为赋新辞强...
DO NOT Design for scalability at first
纵向性能提升
                     提升单机性能

横向扩展? 机器成本......
  我们的特殊国情, 人力成本--, 机器+机位+带宽成本++
  对长尾头部应用下大力气做特殊优化绝对划得来
如果对占最多机器的核心应用...
纵向性能提升
                                     提升单机性能

硬件
     摩尔定律+机器运维成本: 换新的好机器是值的
     插满内存槽通常没错
数据库, 看书...
OS&基础软件
     ...
Design for fault, always
                        这年头什么都不可靠

  硬件不可靠
    单机再可靠, 当机器足够多, 你会老是见到机器挂的
    所以... 机器少的时候还好, 小心你的...
Design for fault, always
                               这年头什么都不可靠

  Erlang 的启示
    Making reliable distributed systems in...
Design for change
                      规模, 业务的迅速变化, 保持敏
                      捷
 基础架构也是演化来的
    没有完美的统一架构, 不要一次过满足三个愿望.
 ...
容量可扩展             可用性

            可靠性
Design for your developers
高吞吐d

  多:   能做的功能/应用/改进更多
  快:   应用开发快
  好:
一致性    能靠谱地...
硬件影响设计




         Source: Jeff Dean, Designs, Lessons and Advice
                 from Building Large Distributed Systems
硬件影响设计

06 vs. Now: 硬件导致设计思路改变.
关于CPU
   核数飞速增加, 但单核性能并没有非常大的提高
   糟糕的应用并行性, shared data struct and locks are
   even more...
信息组织影响设计

信息爆炸
  Thousands: 文件夹, 分类
  Millions: Tags, 简单检索
  Billions, web scale: 检索!
信息结构
  结构化和严格关系模型
  纯文本/媒体与无关系
  Web...
信息组织影响设计

信息爆炸
  Thousands: 文件夹, 分类 --- 树状结构.
  Millions: Tags, 简单检索 --- 简单网状结构和关系模型.
  Billions, web scale: 检索! PageRank ...
全新挑战
Aggregate, Filter, Rank EVERYTHING in REAL-TIME
        推推拉拉的 News feed 只是挑战的开始


               跳出纯关系数据模型

      灵活可...
Thank you!

  Q&A
Upcoming SlideShare
Loading in …5
×

Dreaming Infrastructure

15,664 views

Published on

Published in: Technology, Education
10 Comments
92 Likes
Statistics
Notes
No Downloads
Views
Total views
15,664
On SlideShare
0
From Embeds
0
Number of Embeds
1,537
Actions
Shares
0
Downloads
873
Comments
10
Likes
92
Embeds 0
No embeds

No notes for slide

Dreaming Infrastructure

  1. 1. Dreaming Infrastructure 我的架构学习笔记 邝宇恒 http://randomtaste.appspot.com
  2. 2. About me Mail&GTalk: kuangyuheng@gmail.com Twitter: kyhpudding 中山大学, 03CS本 06年实习进入百度, 搜藏, 空间, 基础平台部 刚刚加入腾讯广州研发中心 本交流纯属个人心得, 不代表任何公司组织之意见
  3. 3. Infrastructure
  4. 4. Infrastructure 可以用开源软件马上搭一个
  5. 5. Infrastructure 可以全部``云''掉
  6. 6. 那我还讲啥?
  7. 7. Infrastructure's fun! 选择一个基础架构 组合, 利用, 优化: 这不仅是一堆开源软件 或者一坨云 有时候, 你得自己动手......
  8. 8. Just for fun :-)
  9. 9. Infrastructure components For distributed web services 机群部署运维 自动部署与各种各样的监控 服务定位和均衡 硬件虚拟化 Messaging Protocol Messaging infrastructure: reliable message queue etc. 应用容器, 框架 etc. 存储 适应业务需要的存储系统. 往往是最困难的. 还有更多 接入(均衡, CDN, 防攻击 etc.) 检索, 日志收集与分析, 机器学习......
  10. 10. Outline 讨论范围 互联网应用, 更精确地: web 应用 基于普通 PC Server 环境, 分布式系统 以存储系统为讨论中心 关于权衡 基础架构设计理念 Google, LiveJournal, Yahoo! 存储系统细节 GFS&BigTable, Dynamo, Sherpa/PNUTS 假定听众有基本了解, 直接讨论有趣的细节 Lessons learned 折腾和被折腾的心得
  11. 11. It's all about trade-offs
  12. 12. 容量可扩展 可用性 可靠性 高吞吐 It's all about trade-offs 一致性 易开发 多快好省! 低延迟
  13. 13. CAP Consistency, Availability, Partition
  14. 14. 搞清你在做什么 我的行业 稳定至上的银行业? 精益求精的搜索行业? 多快好省抢占 地盘的SNS? 我的业务模式, 信息模型 实时在线服务 vs. 线下分析, 读写比例? 关系-存储-浏览, twitter/lifestreaming, 检索- ranking, 挖掘-推荐, 他们的结合? 扁平的树状结构? 还是复杂的网状结构? 产品上的权衡 我的开发者的水平, 习惯 基础架构的用户就是应用开发者 我有多少钱, 多少时间
  15. 15. 搞清我的位置
  16. 16. 设计理念: Google 篇
  17. 17. 设计理念: Google 篇
  18. 18. 设计理念: Google 篇
  19. 19. 设计理念: Google 篇
  20. 20. 设计理念: Google 篇 BigTable Replication across IDC, eventually consistency 服务端编程能力
  21. 21. 设计理念: LiveJournal 篇 LiveJournal: Behind The Scenes, Scaling Storytime Brad Fitzpatrick, April 2007
  22. 22. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling!
  23. 23. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling! 数据库 Scaling read: replication, master/slave Scaling write: sharding JOIN? Big sorted table? sharding 不是包医百病 
  24. 24. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling! 数据库 Scaling read: replication, master/slave Scaling write: sharding JOIN? Big sorted table? sharding 不是包医百病 Cache, Cache, Cache! Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪 Everything run from memory in Web 2.0 --- twitter memcached!
  25. 25. 设计理念: LiveJournal 篇 LAMM(emcache)P(erl)! 高速成长, 从单机到数百台, scaling! 数据库 Scaling read: replication, master/slave Scaling write: sharding JOIN? Big sorted table? sharding 不是包医百病 Cache, Cache, Cache! Cache就是清凉油, 哪里不舒服了抹一下 --- 朱聪 Everything run from memory in Web 2.0 --- twitter memcached! 分布式 Key-Value 存储: MogileFS
  26. 26. 设计理念: 延伸, 经典模式 RDBMS处理逻辑数据 分离大段文本内容, 珍惜宝贵 的DB资源 Scaling: replication, sharding Key-Value存储存大数据 简单, 易扩展, 性能好 Cache everywhere 多层次, 全方位 Infrastructure MySQL&Memcache&KV cluster PHP host environment Sina App Engine!
  27. 27. 设计理念: Yahoo! 篇 众多的业务, 众多的需求 门户, 搜索, 广告, 邮箱, 社区..... 小数据, 大数据, 在线服务, 离线分析...... 众多的基础构建 MySQL&Oracle UDB, YMDB, PNUTS, Hadoop.... 拥抱开源 大量PHP使用, 定制开源软件, yapache etc. Hadoop! 走向云端 That's what we are talking about!
  28. 28. 设计理念: Yahoo! 篇 Source: Key challenges in cloud computing ...and the Yahoo! approach Raghu Ramakrishnan
  29. 29. 设计理念: Yahoo! 篇 在线服务 依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移 UDB: Dynamo like, YMDB: Media files Sherpa/PNUTS: 托管的可扩展, 关系式存储.
  30. 30. 设计理念: Yahoo! 篇 在线服务 依然有很多 MySQL, Oracle, 不可替代, 或没必要迁移 UDB: Dynamo like, YMDB: Media files Sherpa/PNUTS: 托管的可扩展, 关系式存储. 离线分析 Hadoop HDFS: GFS Pig: 跟Sawzall可不同 HBase? Everest Data warehousing 完全SQL支持 
  31. 31. 小结: 设计里 Google 一层层构建的统一基础架构. 真正的统一平台: 强大的平台极大降低创新门槛. LiveJournal 快速扩展, 随需应变的典范. 运用开源和自制软件的结合. Yahoo! 当你有很多完全不同的应用和老系统...... 不追求完全统一, 具体问题具体分析.
  32. 32. 细节: GFS Key-Value存储 Index, Log 线下应用: 大块低并发写 高吞吐远比低延迟重要 简单设计: Single Master Master容量决定文件数目: 瓶 颈? it depends 单点故障 --- chubby 强一致性 确保写三个replica再返回 部分replica失败下的不一致 --- 非幂等操作是恶魔. chunkserver挂掉超长延时 CAP: C+, P-
  33. 33. 细节: BigTable That effort took many years... 一张排序的大表 线上应用, 类DB功能 线下分析, 结构化数据 With GFS GFS保证数据一致可靠 Log-structured merge tree, 切 合GFS模型 可用性...... 一份数据只在一台机器服务, 挂了麻烦等10+秒...... GFS的超长写延时: 开两个 log... CAP: C&P==GFS, A--
  34. 34. 幕后英雄: Chubby 高可用: 如何保证主备一致和正确 自动切换? 主备严格同步确认&心跳 当备连不上主时, 变成主 当他们之间只是网络断掉 当某些client只能连上其中一台 不一致的双 master 当主备连不上的时候 唯一安全的方法就是不再接受提 交, 手工操作检查重起. 可用性比一台机还差! 使用专门心跳电缆和传输线 假定线路完全靠谱. 跨机房就别指望了.
  35. 35. 幕后英雄: Chubby 增加到3台 提交至少得到其他1台确认 使任何操作都得到多数派确认 slave连不上master, 发起选举 投票结果取决于另一台slave与master 的连通 失败: 发起的slave自认倒霉 成功: 原master的提交不再可能得到多 数票. master移交 2N+1台机器, 最多可容忍N台不一致 (挂掉)而保持全局一致. 更多节点具体如何投票确认? Paxos! Paxos made simple & Wikipedia
  36. 36. 幕后英雄: Chubby 每个服务都得来这么一回? 简单点: 锁文件 Master对共享文件加锁, 保证只有一个 master写 如何切换: 租约: Lease 30secs etc, master到期续约 续约不上(网络断, 被抢)让出master, 停 止服务 发现锁因未续约而失效, 分配另外的机器 作为master锁住 Chubby: 可靠的锁服务&小文件存储 Using Paxos... 不是细粒度的事务锁! Developers rarely consider availability
  37. 37. 细节: 论文之后...... GFS的问题 master 单点故障: 从手工恢复到使用 chubby master 文件数量上限 不同的应用模式: 小文件, 大文件量, 从打包到BigTable 分区: 使用多套 GFS 共同使用, 共享同一堆chunk server 延迟: 基本没救了 BigTable Replication, eventually consistency, 在线服务应用 coprocessors: 应用处理直接运行在服务端最接近数据源处 --- bandwidth AppEngine, DataStore on BigTable Datastore index: 使用户查询在顺序表模型上仅需一次range查 询 常见超慢读写, 就是因为这些设计? Spanner?
  38. 38. 细节: Dynamo Amazon's ``always writable'' data storage Key-Value存储 Always writable 事关核心价值: 一次失败的"加 入购物车", 直接损失一笔交易 Eventually consistency: C--, A++ 无中心, 持续扩展 Consistent Hash+Virtual node 各节点地位平等 More (Dynamo+BigTable)@facebook == Cassandra --- twitter wants it too!
  39. 39. 细节: Dynamo Amazon's ``always writable'' data storage CAP: N vs. R+W 可配置的R,W&N, 满足不同需求. Eventually consistency 想象如CVS等并发版本管理 commit指定修改所基于的版本 没有冲突的commit, 顺利replicate到 个节点 有冲突的commit, 各节点返回不同版 本, 由应用(提交者) merge. Preference list 优先写头 N' 台机器. 失败的话会写 下面的 => N' < N 结果: 有可能但稀有的冲突.
  40. 40. 细节: Sherpa/PNUTS Yahoo!’s Hosted Data Serving Platform
  41. 41. 细节: Sherpa/PNUTS Hosted: the cloud 模型: 结构化数据表 在线服务, 小对象, 低延迟, 高并发 单条更新, 灵活查询. Sorted, hash皆支持 一致性模型, per-record timeline 以行为单位做 master/slave, 保证单条记录的一致更新时序 不会出现Dynamo的分支版本和合并, 极大简化开发 灵活的一致性需求: Read-any, read-critical, read-latest, test- and-set-write Notification/Trigger, 与外部cache等对接. YMB: Yahoo! Message Broker 可靠异步消息队列, replication 提交到YMB即为提交成功. YMB保障数据可靠性: 通过重放YMB消息恢复实际storage.
  42. 42. 小结: 细节 分布式系统 异步不可靠传输, 无一致时序是天然特性, 别想逃避. Time, Clocks, and Ordering of Events in a Distributed System Fallacies of Distributed Computing Explained CAP 不同场景, 不同需求, 没有标准答案 Paxos&Chubby 真正实现一个 Quorum 算法 Chubby: 把复杂问题变成一个简单基础服务. Commit log 经典设计模式 将可靠消息队列作为系统的骨架. Log-structured merge tree 简单模型+简单实现
  43. 43. Lessons Learned
  44. 44. DO NOT Design for scalability
  45. 45. DO NOT Design for scalability at first
  46. 46. DO NOT Design for scalability at first ``可扩展'' 是有代价的 受限的查询能力 CAP: 宽松的一致性模型让开发者迷惑 不要在还没成长的时候担负成长的烦恼. 为赋新辞强说愁 在力所能及的情况下, 为可扩展做准备 以尽量不影响开发为前提 遵循常用扩展方法和可扩展设计原则
  47. 47. DO NOT Design for scalability at first ``可扩展'' 是有代价的 受限的查询能力 CAP: 宽松的一致性模型让开发者迷惑 不要在还没成长的时候担负成长的烦恼. 为赋新辞强说愁 在力所能及的情况下, 为可扩展做准备 以尽量不影响开发为前提 遵循常用扩展方法和可扩展设计原则 Google App Engine vs. Sina App Engine 对长尾头部应用, 谁都不靠谱: 需要特殊定制和优化 对小网站, 初创企业, 谁更靠谱?
  48. 48. DO NOT Design for scalability at first
  49. 49. 纵向性能提升 提升单机性能 横向扩展? 机器成本...... 我们的特殊国情, 人力成本--, 机器+机位+带宽成本++ 对长尾头部应用下大力气做特殊优化绝对划得来 如果对占最多机器的核心应用单机性能提升30% 就能省20-30%的机器...... 和机位! 那是好多钱......
  50. 50. 纵向性能提升 提升单机性能 硬件 摩尔定律+机器运维成本: 换新的好机器是值的 插满内存槽通常没错 数据库, 看书... OS&基础软件 文件系统选择, 硬件驱动, 配置... readahead, sendfile, epoll... 编译器, 编译选项, tcmalloc... IO 传统硬盘: 避免随机读写 / SSD: 避免随机写. 压缩: CPU 换 IO&带宽. 部署 你的每台机器的 CPU, 内存, IO 都跑满了吗? 混搭部署, PHP纯CPU, Cache纯内存
  51. 51. Design for fault, always 这年头什么都不可靠 硬件不可靠 单机再可靠, 当机器足够多, 你会老是见到机器挂的 所以... 机器少的时候还好, 小心你的硬盘...... 网络不可靠, 仔细设计超时和重试策略 人最不可靠 Bug... Getting real: 你得习惯烂软件质量 靠机制, 不要靠人
  52. 52. Design for fault, always 这年头什么都不可靠 Erlang 的启示 Making reliable distributed systems in the presence of software errors 组件隔离: 存储与应用, 应用之间...... Why PHP works? 也从函数式编程中学到很多. 健壮的基础架构 1. 普通应用组件无须容忍基础架构和其他组件的错误. 2. 如果他们出错, 则直接跟着 crash --- 没有重试? 3. 在这样的情况下, 能提供符合用户健壮性要求的应用. 不要让应用开发者把时间耗在思考各种死法上. 桌面软件错误 vs. Web
  53. 53. Design for change 规模, 业务的迅速变化, 保持敏 捷 基础架构也是演化来的 没有完美的统一架构, 不要一次过满足三个愿望. 后天的问题, 至少留到明天解决, 不要阻碍今天的生活. Right design at X may be very wrong at 10X or 100X 反之亦然! Google: 7 significant revision in last 10 years. 简单设计 典范: GFS 的 single master 史. 缩短开发周期, 降低项目复杂度, 船小好调头. 准备抛弃
  54. 54. 容量可扩展 可用性 可靠性 Design for your developers 高吞吐d 多: 能做的功能/应用/改进更多 快: 应用开发快 好: 一致性 能靠谱地跑起来, 实现产品核心价值 省: 省钱! 易开发 多快好省! 低延迟
  55. 55. 硬件影响设计 Source: Jeff Dean, Designs, Lessons and Advice from Building Large Distributed Systems
  56. 56. 硬件影响设计 06 vs. Now: 硬件导致设计思路改变. 关于CPU 核数飞速增加, 但单核性能并没有非常大的提高 糟糕的应用并行性, shared data struct and locks are even more evil than ever! 关于SSD: 规则改变者 SSD价格会迅速降低, 性能可靠性会继续提高. SSD与传统机械硬盘的不同特性 The 5 minutes rule 20 years later and how flash memory changes the rules Technologies for Data-Intensive Computing
  57. 57. 信息组织影响设计 信息爆炸 Thousands: 文件夹, 分类 Millions: Tags, 简单检索 Billions, web scale: 检索! 信息结构 结构化和严格关系模型 纯文本/媒体与无关系 Web: 半结构化, 复杂与不确定关系
  58. 58. 信息组织影响设计 信息爆炸 Thousands: 文件夹, 分类 --- 树状结构. Millions: Tags, 简单检索 --- 简单网状结构和关系模型. Billions, web scale: 检索! PageRank --- 这叫啥结构? 信息结构 结构化和严格关系模型 --- 数据库条目. 纯文本/媒体与无关系 --- Key/Value 存储, S3 Web: 半结构化, 复杂与不确定关系 --- Semantic Web, Linked data, 人际关系, news feed... Web 0.2, not Web 2.0! --- WWW 的能力远没有完全发挥 珠三角技术社区的新鲜事? 不是 ``好友/关键字的最新动态'' 模糊与个性化需求: 珠三角? 技术? 我的技术喜好? 圈子? 开放平台与聚合: 只能在 twitter 站上推的不叫Web! 实时!
  59. 59. 全新挑战 Aggregate, Filter, Rank EVERYTHING in REAL-TIME 推推拉拉的 News feed 只是挑战的开始 跳出纯关系数据模型 灵活可定制的实时检索是基础架构而非添头 计算分析平台成为必须, Map-Reduce 就够了? 经典模式和组件也许不再有效 但基础方法和技术依然
  60. 60. Thank you! Q&A

×