Sensei:分布式, 实时, 半结构化数据库

在未出现开源搜索引擎以前, Doug Cutting整了个Lucene, 随后Yonik Seeley写了一个Solr, 在2010年 Shay Banon发布了ElasticSearch, 大概在两年前, 我们迎来了Sensei, 最近他们发布了1.0版本, 下面通过@sematext对LinkedIn的搜索架构师John Wang的一个采访. 来大致了解一下Sensei.

Sensei是什么?
开源, 灵活, 实时, 分布式数据库, 原生支持搜索, 能操作非结构化文本和结构化数据. 它主要用户处理海量复杂半结构化查询和经常变化的数据结构. 它广泛用于支持LinkedIn.com的搜索功能.

为什么没有用solr?
1.数据更新量大
2.分布式. 目前solr的分布式在master上还存在单点问题(SPOF), 而Solr Cloud还没出来
3.复杂的facet支持.

Sensei的独到之处有哪些?
支持海量更新
支持半结构化查询

Sensei最大的缺点以及计划何时解决?
1. Sensei的文档必须有一个long类型的唯一标示符. 这个主要是处于性能的考虑. 目前没考虑解决.
2. 数字类型不支持负数, 该功能即将实现.
3. 静态schema. 稍后支持动态schema.

接下来即将实现的关键功能有哪些?
1.相关的工具
2.内建对时间和地理信息类型字段支持
3.parent node类型文档支持
4.支持属性类型facet(名字对)
5.在线均衡重置
6.在线索引重建
7.参数化二级存储
8.动态schema
9.支持聚合函数, 比如AVG, MIN, MAX

Norbert在Sensei中的作用?
一个集群管理器, 负责Broker和Sensei node之间的RPC调用. Broker是内置在Sensei节点的Servlet. Norbert用于Sensei Node之间的消息传输. 同时它内置了Zookeeper来进行集群管理. 下一步将对其进行抽象, 允许以plugin的方式集成其他集群功能.

对BQL介绍一下?
BQL – Browse Query Language. 作为SQL变种支持Sensei查询. 它将成为Sensei的标准查询.

Sensei相关的性能测试数据?
测试数据参见:http://Senseidb.com/performance.html
相关测试代码参见:https://github.com/kwei/search-perf

Sensei是否有单点问题(SPOF)?
没有.

什么情况下会导致数据丢失?
除非所有副本节点都丢失数据
Sensei要求添加的所有数据都是有序而且带版本的, 从而实现数据回放恢复.

如果集群中的一个节点挂了会怎样?
有ZooKeeper呢.

如果达到集群容量上限会如何处理? 自动扩展还是手工重置负载均衡?
取决于数据的Sharding方式.
新加入的节点需要在Sensei.properties配置文件中指定处理哪些分片的数据, 比如:
Sensei.node.partitions=1,3,8

如果sharding策略不需要迁移数据, 比如根据时间和连续UID sharding, 那么扩展集群将非常方便
如果sharding策略需要迁移数据. 比如采用取模的方式sharding, 这时集群就需要重置负载均衡. 下一步将实现在线重置负载均衡. 而现在需要对所有数据重建索引.

作为最终一致性的Sensei, 如何保证多次查询结果一致?
通过一个路由参数, Sensei采用一致性hash路由参数, 保证每次查询都定位到同一个节点.

如何升级? 是否需要停机整个集群? 是否向后兼容?
部分升级. 不需要停机整个集群. 向后兼容.

Sensei是否需要shema?
需要, 下一步支持动态shema.

其他搜索功能的支持情况?
通过相关工具支持Function query
计划支持SpatialSearch和Parent-Child数据
不计划支持Join.

如何访问Sensei?
提供两个接口: REST/JSON和BQL
提供Java和Python客户端.

Sensei的运维工具做的怎样?
自带有一个web应用来管理集群.
提供了JMX支持,
还支持修改配置来调整输出, 比如日志输出.

原文地址:http://blog.sematext.com/2012/01/26/Sensei-distributed-realtime-semi-structured-database/