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

标签: sensei 分布 实时 | 发表时间:2012-02-04 22:24 | 作者:
出处:http://www.iteye.com
在未出现开源搜索引擎以前, 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/

已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [sensei 分布 实时] 推荐:

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

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

分布式实时搜索方案介绍-senseidb

- - 五四陈科学院-坚信科学,分享技术
以下内容由 [五四陈科学院]提供. zoie:由linkedin开源的建立在lucene之上提供实时索引的系统. 它利用两 个内存索引一个硬盘索引来实现实时搜索. bobo-browse:由linkedin开源的基于lucene的分类浏览搜索系统. zookeeper:一个分布式的,开放源码的分布式应用程序协调服务,常用来做配置服务.

实时分布式日志系统plumelog落地

- - 掘金 架构
这是我参与「掘金日新计划 · 4 月更文挑战」的第25天, 点击查看活动详情. 无代码入侵的分布式日志系统,基于log4j、log4j2、logback搜集日志,设置链路ID,方便查询关联日志. 基于elasticsearch作为查询引擎. 全程不占应用程序本地磁盘空间,免维护;对于项目透明,不影响项目本身运行.

开源分布式搜索平台ELK(Elasticsearch+Logstash+Kibana)+Redis+Syslog-ng实现日志实时搜索

- - C1G军火库
ElasticSearch是一个基于Lucene构建的开源,分布式,RESTful搜索引擎. 设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便. 支持通过HTTP使用JSON进行数据索引. logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台. 你可以用它来统一对应用程序日志进行收集管理,提供 Web 接口用于查询和统计.

分布式日志

- - Java - 编程语言 - ITeye博客
最近完成一个简单的日志管理系统,拿出来跟大家分享一下. 3、支持文件输出、habse输出、mongodb输出. 基于以上三点功能,我们下面详细说明. 说道支持这个功能,有个同事认为没有这个必要,他的观点是log4j的配置不需要经常变动,不需要支持这样的功能;本人的观点是“配置可以进行统一管理、而且正式机跟测试机的log4j的配置肯定会有一些差异的”,因此这个功能是必须的.

Facebook的实时Hadoop系统

- wangjia - Solrex Shuffling
Facebook 在今年六月 SIGMOD 2011 上发表了一篇名为“Apache Hadoop Goes Realtime at Facebook”的会议论文 (pdf),介绍了 Facebook 为了打造一个实时的 HBase 系统使用到的独门秘技. 由于该论文提到的应用场景与小弟负责的系统要解决的问题域有相似之处,因而抽时间仔细阅读了这篇论文.

Storm 实时性分析

- - CSDN博客架构设计推荐文章
都说Storm是一个实时流处理系统,但Storm的实时性体现在什么方面呢. 首先有一个前提:这里的实时性和我们通常所说的实时系统(芯片+汇编或C编写的实时处理软件)的实时性肯定是没法比的,也不是同一个概念. 这里的实时性应该是一个相对的实时性(相对于Hadoop之类 ). 总结一下,Storm的实时性可能主要体现在:.

storm准实时应用

- - CSDN博客推荐文章
1 应用背景: 需要实时统计用户的登陆数,在线人数,活跃时间,下载等指标的数据,或者清洗后移到hdfs上.         1) 客户端产生数据---.         2) kafka-生产者实时采集数据(保留7天)-----.         3) storm实时消费数据,处理数据.         4)把实时数据统计结果缓存到memcached 中.

实时传输协议(RTP)和实时控制协议(RTCP)

- - CSDN博客推荐文章
RTP是一种提供端对端传输服务的实时传输. 协议,用来支持在单目标广播和多目标广播网络服务中传输实时数据,而实时数据的传输则由RTCP. 使用RTP协议的应用程序运行在RTP之上,而执行RTP的程序运行在UDP的上层,目的是为了使用UDP的端口号 和检查和. 如图16-12所示,RTP可以看成是传输层的子层.

实时流计算、Spark Streaming、Kafka、Redis、Exactly-once、实时去重

- - lxw的大数据田地
本文想记录和表达的东西挺多的,一时想不到什么好的标题,所以就用上面的关键字作为标题了. 在实时流式计算中,最重要的是在任何情况下,消息不重复、不丢失,即Exactly-once. 本文以Kafka–>Spark Streaming–>Redis为例,一方面说明一下如何做到Exactly-once,另一方面说明一下我是如何计算实时去重指标的.