Elasticsearch vs. Algolia vs. Swiftype

We use Elasticsearch for our CBIR system.

Fast text indexing.

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

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

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.

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

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.

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.

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.

Main data storage and the core component

Logging purpose only

nginx 로그분석

KPI datastorage

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

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

Caching backend for frontend site

Indexes our data to provide advanced rule-based promotions and categories and also full-text search and faceted filtering on client front-end websites.

Searchable Store

We use this for our string searches

Storage solution for the Flask application

Fuzzy search of our dataset.

Search engine, NoSQL storage, queue, etc..

Centralized search database for editorial content.

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

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

ElasticSearch powers our free text search.

Search engine for our cluster

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

Log analysis store

Search queries, logs and application performance (data)

Fast query responses

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

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

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

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

Log comprehension

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

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

Site search, faceted filtering and product matching algorithms

Main storage

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.

Used this for story search.

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.

Read about it here.

We use Elasticsearch to power our Relevance algorithms.

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

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.

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

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.

This is the bedrock of kako.pk - it not only serves the JSON data, it doubles as a (very fast) web-server if you connect to the client JS widget libraries

We use algolia to power our product search / filtering (https://www.shoesofprey.com/shoes).

real time search

Algolia helps us search across disparate pieces of information in our staff portal, and allows customers to easily jump around the portal between devices, support conversations, and documentation.