Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à 分布式索引系统调研
Similaire à 分布式索引系统调研 (20)
分布式索引系统调研
- 1. 分布式索引系统调研 业界
- 2. 内容 • Google索引 • 淘宝 • Solr • Katta
- 3. GOOGLE索引
- 4. 基于MapReduce索引框架 • 基于MapReduce的搜索索引系统。从本质上而言，这个索 引是由序列的批处理操作组成的。它通过把对数据集的大 规模操作分发给网络上的每个节点进行运算，而每个节点 会周期性的把完成的工作和状态的更新报告回主计算。 – 缺点：缺乏实时性
- 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）
- 8. 淘宝
- 9. 淘宝OceanBase • OceanBase是一个支持海量数据的高性能数 据库系统 降低数据规模的方法： 1）GFS+MR/HDFS+MR （离线） 2）弱一致性、软事务 • OceanBase逻辑架构简图 http://rdc.taobao.com/blog/cs/?p=956
- 10. 淘宝OceanBase • ChunkServer – 保存基准数据的服务器，通常是多台，为了避免软件硬件故障导致的服 务中断，同一份基准数据通常保存了3份并存储在不同ChunkServer上 • UpdateServer – 保存动态数据的服务器，一般是单台服务器。为了避免软件硬件故障导 致的服务中断，UpdateServer记录commit log并通常使用双机热备 • MergeServer – 进行静态动态数据合并的服务器，常常与ChunkServer共用一台物理服务 器。MergeServer使得用户能够访问到完整的最新的数据 • RootServer – 配置服务器，一般是单台服务器。为了避免软件硬件故障导致的服务中 断，RootServer记录commit log并通常采用双机热备。由于RootServer负载 一般都很轻，所以它常常与UpdateServer共用物理机器 Copy on write
- 11. TAIR Tair是一个分布式的key/value结构数据的解决方案，系统默认 支持基于内存和文件的存储引擎，对应于通常我们所说的缓 存和持久化存储。 – Tair具有良好的架构，使得其在可扩展性、数据安全性方面都有较好 的表现: – 基于对照表的灵活、良好的可扩展性 – 轻量级的configserver – 抽象的存储引擎层，支持添加新的存储引擎 – 自动的复制和迁移，对用户透明 – 多机架和多数据中心的支持 – 插件容器
- 12. SOLR分布式索引
- 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
- 14. Solr
- 15. Solr优化 • 调优某个Solr服务器(Scale High) – 通过缓存和内存管理优化某个单实例的Solr。将Solr部署到一 个拥有快速的CPU和硬件的专用服务器，通过调优，最大化 的将单个服务器的性能达到最高。 • 使用多Solr服务器(Scale Wide) – 使用多Solr服务器。如果你的avgTimePerRequest参数在你可 接受的范围内（数据量一般在数百万），那么可以通过配置 将你的master上的索引完整地复制到slave机器上；如果你的 查询已经很慢，那么使用分片来讲你的单个查询的负载分发 到多个Solr服务器上。 • 使用复制(replication)和分片(sharding)(Scale Deep) – 当你的数据量足够大，你需要同时使用复制和分片，那么每 个分片将对应一个master和若干slave，这将是一个最复杂的 架构。
- 16. Solr
- 17. SolrCloud • 对solr的扩展，简化了Solr集群的部署和使 用。具有如下特点： – 对整个集群进行集中式地配置 – 自动的负载均衡和故障转移 – 集群的状态和布局存储在中心系统中 – 集成Zookeeper，对集群的配置进行协调和存储
- 18. SolrCloud • 设计目标 – 高可得性和容错 – 集群的大小调整和重新平衡负载 • 根据热点使集群增长或者重新平衡负载，shards（碎片）应该能 够调整大小。将碎片分裂，并分配到新的服务器中。 – clients不应该知道cluster的布局 – 开发的API • zookeeper的schema应该被良好地定义和开放，运行其他组件通过 zookeeper查看和改变集群 – 支持各级的自定义集群 • 用户管多少，solr管多少，可以根据需要自由划分 – 支持用户指定partition • 例如可以根据地理区域，时间或者用户等等，能够显著提高性能
- 19. Katta
- 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