More Related Content Similar to 分布式索引系统调研 (20) 分布式索引系统调研2. 内容
• Google索引
• 淘宝
• Solr
• Katta
5. Caffeine 索引
• 咖啡因索引系统更新采用了全然不同的方式,Google针对小部
分网络进行分析,而非一次分析整个网络,而且一天24小时持
续更新其全球索引,因此只要Google一发现新的网页,就会直
接把它加进索引中,这代表使用者比以前更容易找到更新的资
讯。
• 咖啡因索引系统每秒可平行处理数十万的页面,这些页面若用
纸张堆起来有3哩高,同时咖啡因占据了Google资料库约1亿GB
的储存空间,而且以每天数十万GB的速度增加。
• 由于咖啡因改善了索引网络内容的速度,因此当一个新的博客
甚至论坛文章出现时,使用者将可比过去更快速地通过Google
找到相关内容的连结。
6. Percolator
• Percolator是Google使用的一款基于Bigtable的、支持事务的增量索引系统,以
客户端库的形式提供给用户。
• 搜索的网页引入索引,在爬取的文件的同时,Google的主系统能够同时进行
数据处理。
• DBMS-Procolator-MR
Percolator系统能对一个大数据集增量处理更新
• Percolator的设计原理其中之一在于提供一个能够随机访问的文件库,并单独
进行处理,以替代MapReduce的全局式处理方式
• 快照隔离——这是Percolator的设计核心,其目的在于提供cross-row、cross-
table、ACID兼容性等数据交换
• Percolator还提供了一个类似系统观测员“observers”的功能,意思是一旦用户
对指定的列进行更改,系统将进行自动调用,“目的在于协助开发人员保持服
务器计算状态的跟踪”。
7. Percolator
http://hi.baidu.com/quest2run/blog/item/6ae
d0af88e67d273024f56e3.html
1. Percolator worker 包含 注册定制的 observer 列表并 “扫描”/“监视”
Bigtable column 的更新,在更新时回调(通知)相应的observer
2. observer 向 Bigtable tablet server 发送读/写 Transaction RPC, Bigtable
tablet server 进而向 GFS chunk server 转发 该 读/写 RPC
3. 系统依赖 timestamp oracle service (与 Oracle 数据库无关,不知道 Google
工程为什么不取一个更有创意的名字?) 提供严格的递增时间戮达到事务
完整性 Transaction ACID (by snapshoot isolation)
4. 系统依赖 lock service 来达到高效地查找等待处理的更新/“脏”通告(dirty
notifications)
10. 淘宝OceanBase
• ChunkServer
– 保存基准数据的服务器,通常是多台,为了避免软件硬件故障导致的服
务中断,同一份基准数据通常保存了3份并存储在不同ChunkServer上
• UpdateServer
– 保存动态数据的服务器,一般是单台服务器。为了避免软件硬件故障导
致的服务中断,UpdateServer记录commit log并通常使用双机热备
• MergeServer
– 进行静态动态数据合并的服务器,常常与ChunkServer共用一台物理服务
器。MergeServer使得用户能够访问到完整的最新的数据
• RootServer
– 配置服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中
断,RootServer记录commit log并通常采用双机热备。由于RootServer负载
一般都很轻,所以它常常与UpdateServer共用物理机器
Copy on write
13. SOLR架构
Update
HTTP Request Servlet
Servlet
Admin Disjunction R
Interface Standard Customer XML XML
Max e
Request Request Response Update
Request p
Handler Handler Writer Interface
Handler l
i
Config Schema Caching
c
Update a
Analysis Solr Core Config
Handler t
i
o
n
Lucene
15. Solr优化
• 调优某个Solr服务器(Scale High)
– 通过缓存和内存管理优化某个单实例的Solr。将Solr部署到一
个拥有快速的CPU和硬件的专用服务器,通过调优,最大化
的将单个服务器的性能达到最高。
• 使用多Solr服务器(Scale Wide)
– 使用多Solr服务器。如果你的avgTimePerRequest参数在你可
接受的范围内(数据量一般在数百万),那么可以通过配置
将你的master上的索引完整地复制到slave机器上;如果你的
查询已经很慢,那么使用分片来讲你的单个查询的负载分发
到多个Solr服务器上。
• 使用复制(replication)和分片(sharding)(Scale Deep)
– 当你的数据量足够大,你需要同时使用复制和分片,那么每
个分片将对应一个master和若干slave,这将是一个最复杂的
架构。
18. SolrCloud
• 设计目标
– 高可得性和容错
– 集群的大小调整和重新平衡负载
• 根据热点使集群增长或者重新平衡负载,shards(碎片)应该能
够调整大小。将碎片分裂,并分配到新的服务器中。
– clients不应该知道cluster的布局
– 开发的API
• zookeeper的schema应该被良好地定义和开放,运行其他组件通过
zookeeper查看和改变集群
– 支持各级的自定义集群
• 用户管多少,solr管多少,可以根据需要自由划分
– 支持用户指定partition
• 例如可以根据地理区域,时间或者用户等等,能够显著提高性能
20. Katta & Zookeeper
ZookeeperClient ZookeeperServer
ClientCnxn QuorumPeer Factory
Waiting Read Response
Event IO
Queue
Outgoing
Send
Buffers
Socket NIO ServerCnxn
Submit Send
Thread Recv
Request IO
Request
Processor
Event Outgoing ping Zookeeper
Threat Queue Server
Submit Request
Get Data
Register
Event
ZK Client Server
Watcher