Elasticsearch vs. Qbox.io vs. Searchify

Elasticsearch is the engine that powers search on the site. From a high level perspective, it’s a Lucene wrapper that exposes Lucene’s features via a RESTful API. It handles the distribution of data and simplifies scaling, among other things.

Given that we are on AWS, we use an AWS cloud plugin for Elasticsearch that makes it easy to work in the cloud. It allows us to add nodes without much hassle. It will take care of figuring out if a new node has joined the cluster, and, if so, Elasticsearch will proceed to move data to that new node. It works the same way when a node goes down. It will remove that node based on the AWS cluster configuration.

Used ES through QBox.io as the search engine for the site.

Cloudify uses Elasticsearch both to store runtime information (it’s actually a little known fact that Elasticsearch can serve as a NoSQL database), as well as, in its more classic capacity to index system logs and events, making them available over API calls.

I really dont think elastic search belongs in the utilities category.

We use Elasticsearch to power our Relevance algorithms.

Read about it here.

The very first version of the search was just a Postgres database query. It wasn’t terribly efficient, and then at some point, we moved over to ElasticSearch, and then since then, Andrew just did a lot of work with it, so ElasticSearch is amazing, but out of the box, it doesn’t come configured with all the nice things that are there, but you spend a lot of time figuring out how to put it all together to add stemming, auto suggestions, all kinds of different things, like even spelling adjustments and tomato/tomatoes, that would return different results, so Andrew did a ton of work to make it really, really nice and build a very simple Ruby gem called SearchKick.

Used this for story search.

We use ElasticSearch to index and query items that need to be searched full-text (such as jobs and candidates). We mirror changes to our main datastore (PostgreSQL) onto ElasticSearch using SQLAlchemy's events, denormalizing as needed.

Main storage

Site search, faceted filtering and product matching algorithms

Internal Jezebel functionality, not directly exposed to the client. Part of the internal search scoring, main communication happens via binary port 9300.

내부 검색 엔진을 Solr 기반의 AWS CloudSearch 에서 Elasticsearch 로 옮기고 있는 중입니다. 관리의 편의성 등에서 좋은 점수를 줄 수 있습니다.

Log comprehension

Is a powerful searchable service, i use to save index text, a lot.

Two clusters, one to store logs, one to index data for our customers

• simple RESTfull API - perl로 인터페이스함

• 마스터노드 - 멤버쉽관리, 메타데이터
• 데이터노드
• 클라이언트노드 - 로드밸런싱

Fast query responses

Search queries, logs and application performance (data)

Log analysis store

Search backend for django haystack. Also second instance for graylog.

Search engine for our cluster

ElasticSearch powers our free text search.

We use Elasticsearch to provide the search function over our documentation website.

Mainly for logs. Some apps also rely on elasticsearch for storage.

Centralized search database for editorial content.

Search engine, NoSQL storage, queue, etc..

Fuzzy search of our dataset.

Storage solution for the Flask application

We use this for our string searches

Searchable Store

Caching backend for frontend site

Ferramenta que permite oferecer um serviço de busca inteligente para pesquisas incompleta ou aproximadas ( em analise )

Enables fast and efficient indexing and searching of complex and big amounts of data.

KPI datastorage

nginx 로그분석

Logging purpose only

Speaking about Read in CQRS, elastic is the one stop ! Scalable, resilient, powerful, HTTP API ...

Main data storage and the core component

All social data we track is stored in ElasticSearch to make it easily searchable and for advanced statistics. Our several ElasticSearch clusters hold several billion social messages.

We use ElasticSearch for

• Session Logs
• Analytics
• Leaderboards

We originally self managed the ElasticSearch clusters, but due to our small ops team size we opt to move things to managed AWS services where possible.

The managed servers, however, do not allow us to manage our own backups and a restore actually requires us to open a support ticket with them. We ended up setting up our own nightly backup since we do per day indexes for the logs/analytics.

Most of what people want to do with Wirkn is related to searching or filtering in some form or another. We normalize our data into ElasticSearch for fast, robust, search capabilities. Why not use PostgreSQL's great full-text search? Because ElasticSearch allows us to use Kibana as well.

Built backend search engine of elasticsearch e.g. http://www.saraiva.com.br/

Elasticsearch has good tooling and supports a large api that makes it ideal for denormalizing data. It has a simple to use aggregations api that tends to encompass most of what I need a BI tool to do, especially in the early going (when paired with Kibana). It's also handy when you just want to search some text.

회원, 비디오, 타임라인 검색

Elasticsearch is one of our favorite tools and was a smart replacement for Mongo when building out our more complex search functionality.

Fast text indexing.

We use Elasticsearch for our CBIR system.

로그 모니터링 목적으로 사용합니다

Our own ElasticSearch cluster is used to provide fast fulltext search through all your documents and digitalized paperwork.

You Know, for Search.

Self taught : acquired knowledge or skill on one's own initiative. Open Source Search & Analytics. -time search and analytics engine. Search engine based on Lucene. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents.

Search as a Service