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. 稍后支持.

接下來即將實現的關鍵功能有哪些?
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/