文档章节

The Future of Compass & ElasticSearch

杨尚川
 杨尚川
发布于 2015/04/08 06:04
字数 1084
阅读 198
收藏 1
Posted by: Shay Banon on 07/07/2010
 

    Its been a long time since I blogged about Compass, and I guess its about time to discuss CompassElasticSearch, and how they relate to one another.

    I started Compass six years ago with a real belief that search is something that any application should have (and search here is not just full text search), and the aim was to have search integrated into a Java application as simple as possible.

    Compass has pioneered some really exciting features, including the ability to map your domain model to a search engine (OSEM), later also XML and JSON support, and integration with other ORM libraries (Hibernate, JPA, and so on) to try and make the integration of search as seamless as possible to your typical Java stack application (which has been copied quite nicely by others as well).

    During the lifecycle of Compass, I have also tried to address the scalability aspects of a search solution. By integrating with solutions such as GigaSpaces, Coherence, and Terracotta, the aim was to try and make a search based solution more scalable and usable by applications.

    About 8 months ago, I started to think about Compass 3.0. I knew that it required a major rewrite in how it uses Lucene (Lucene 2.9 came with several major changes internally, mainly in how it handles low level readers and search), and also in how to better create a scalable search solution, being able to scale from a single box to many easily and seamlessly. The changes did not end there, I also wanted to create a solution where adding more advance search features, such as facets and others, would be simple.

    The more I thought about it, the more I understood that this basically entitles a complete rewrite of Compass if its going to be done correctly. Also, I wanted to bring to the table the experience I had with search over the past years and how search should be done, which is hard with an existing codebase.

    This is an important point, especially when it comes to scalable search, which I would like to touch on. The way that I started with trying to solve scalable search using Compass is by creating a distributed Lucene Directory implementation. Of course, this does gets you a bit further down the scalability road, but its very evident for people knowing how Lucene works (or, for that matter, search engines) that this is not the preferred solution (I knew it as I was writing it). Even going up the stack and creating something similar to Lucandra won’t cut it… . The proper way to solve the scalability problem is by running a “local” index (a shard) on each node, and do map reduce when you execute a search, and routing when you index (this is a very simplistic explanation).

    So, I started out building elasticsearch. Its basically a solution built from the ground up to be distributed. I also wanted to create a search solution that can be used by any other programming language easily, which basically means JSON over HTTP, without sacrificing the ease of use within the Java programming language (or more specially, the JVM).

    To be honest, I am amazed at what has happened in just 8 months. ElasticSearch is up and running, providing all the core features I wanted it to have at the beginning. Its a scalable search solution, with a JSON over HTTP interface as well as really nice “native” Java API (it gets nicer in the upcoming 0.9 release).

    Sadly, I have been spending a lot of time on elasticsearch, and almost no time on Compass itself, especially around the forum. For that, I deeply apologize to the amazing Compass users that have been there over the years.

    So, what about the future of Compass? I see ElasticSearch as Compass 3.0. Thats how I would have wanted the next major version of Compass to look like. This is not to say that the current ElasticSearch version implements all of Compass features, but the basis is there. The two main features that are missing are OSEM, and ORM integration.

    As for OSEM, ElasticSearch can already index JSON (and JSON like structure, for example, in the form of a Map). What is left to be done is to create a mapping layer from the object model to this JSON like structure. ORM level integration should work in very similar to how Compass implements it today.

    In terms of Java (JVM) level integration, ElasticSearch can easily either start embedded or remote to the Java process, both in distributed mode or in a single node mode.

    So, what should someone do today? If you are going to start a new project, I would suggest you take ElasticSearch for a spin, I am sure you will like it. Existing Compass users should start to give serious thought as to how to migrate to ElasticSearch. Hopefully, once OSEM is implemented in ElasticSearch, the migration will be simpler.

    Regarding the current Compass 2.x version, its basically in maintenance mode. I will try and help in the forum as much as I can. Will gladly accept patches and apply them to trunk and maybe even release a minor version for it. If someone would like to get more involved with it (administer the forum, help with the patches, releases, commit permission, and so on), I would be happy for it.

    As far as I am concerned, the future is ElasticSearch. It is probably the most advanced open source distributed search solution you can find today, and its integration with Java (JVM) is a first class citizen. I hope that Compass user base will follow…

 

About Shay Banon

Shay is the founder of the Compass open source project, a unique solution enabling search capabilities into any application model. He started working on mission critical real time C/C++ systems, later moving to Java (and never looked back). Within the Java world, Shay has worked on a propriety implementation of a distributed rule engine(RETE) server, your typical Java based web projects, and messaging based projects within the financial industry. Currently, Shay is a System Architect at GigaSpaces, GigaSpaces provides a single platform for end-to-end scalability of high performance and stateful distributed applications. GigaSpaces’ unique approach enables developers to Write their business logic Once and then seamlessly Scale out the application linearly Anywhere.

 

 ElasticSearch相关资料

© 著作权归作者所有

共有 人打赏支持
杨尚川

杨尚川

粉丝 1095
博文 220
码字总数 1624053
作品 12
东城
架构师
私信 提问
APDPlat拓展搜索之集成ElasticSearch

APDPlat充分利用Compass的OSEM和ORM integration特性,提供了简单易用且功能强大的内置搜索特性。 APDPlat的内置搜索,在设计简洁优雅的同时,还具备了强大的实时搜索能力,用户只需用注解的...

杨尚川
2014/02/01
0
2
Compass 转向 ElasticSearch 了?

ElasticSearch和Compass 的作者是同一个? http://www.kimchy.org/the_future_of_compass/

清莹
2013/09/11
1K
1
把 ElasticSearch 当成是 NoSQL 数据库

Elasticsearch 可以被当成一个 "NoSQL"-数据库来使用么? NoSQL 意味着在不同的环境下存在不同的东西, 而erestingly 它并不是真的跟 SQL 有啥关系. 我们开始只会觉得 "可能"而已, 所以细细研究...

oschina
2014/02/13
13.1K
11
Elastic 今日在纽交所上市,股价最高暴涨122%。

10 月 6 日,Elastic 正式在纽约证券交易所上市,股票代码为"ESTC"。开盘之后股价直线拉升,最高点涨幅达122%,截止到收盘涨幅回落到94%,意味着上市第一天估值接近翻倍。 该公司最初位于阿姆...

纯洁的微笑
2018/10/08
0
0
让分词更懂你的搜索!海量分词-ES插件重磅发布!

近几年备受追捧的ElasticSearch(ES)凭借其稳定、可靠、快速的实时搜索,受到大家的好评,维基百科、SoundCloud 将 ES 作为其核心搜索组件。但是 ES 本身对中文分词和搜索比较局限。简单地说...

hlznzhx
2018/11/29
0
0

没有更多内容

加载失败,请刷新页面

加载更多

编码规范

4.、编码时的一些建议 1、尽量指定类、方法的final修饰符——虚拟机会想办法内联所有的final方法来减少方法执行时创建栈帧的数量,从而降低栈溢出的风险 2、尽量重用对象——重复new对象会增...

呵呵哒灬
53分钟前
2
0
第一个docker化的java应用

Docker 思想 集装箱 标准化:运输方式/存储方式/API 接口 隔离

BeanHo
54分钟前
1
0
数据库技术-Mysql主从复制与数据备份

数据库技术-Mysql 主从复制的原理: MySQL中数据复制的基础是二进制日志文件(binary log file)。一台MySQL数据库一旦启用二进制日志后,其作为master,它的数据库中所有操作都会以“事件”...

须臾之余
昨天
13
0
Git远程仓库——GitHub的使用(一)

Git远程仓库——GitHub的使用(一) 一 、 Git远程仓库 由于你的本地仓库和GitHub仓库之间的传输是通过SSH加密的,所以需要一下设置: 步骤一、 创建SSH key 在用户主目录下,看看有没有.ss...

lwenhao
昨天
4
0
SpringBoot 整合

springBoot 整合模板引擎 SpringBoot 整合Mybatis SpringBoot 整合redis SpringBoot 整合定时任务 SpringBoot 整合拦截器...

细节探索者
昨天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部