Presentation held on 5.10.2014 on http://2014.webcampzg.org/talks/.
Although ElasticSearch (ES) primary purpose is to be used as index/search server, in its featureset ES overlaps with common NoSql database; better to say, document database.
Why this could be interesting and how this could be used effectively?
- ES - history, background, philosophy, featureset overview, focus on indexing/search features
- short presentation on how to get started - installation, indexing and search/retrieving
- Database should provide following functions: store, search, retrieve -> differences between relational, document and search databases
- it is not unusual to use ES additionally as an document database (store and retrieve)
- an use-case will be presented where ES can be used as a single database in the system (benefits and drawbacks)
- what if a relational database is introduced in previosly demonstrated system (benefits and drawbacks)
ES is a nice and in reality ready-to-use example that can change perspective of development of some type of software systems.
real time data, distributed, multi-tenancy, real time
analytics, high availability
restful api, document oriented, schema free, full text
search, per-operation persistence, conflict management
Database is …
an organized (or structured) collection of data
Database management system (DBMS) is …!
software system provides interface between users and database(s)
4 common groups of interactions:
1. Data definition
2. Update - CrUD
3. Retrieval - cRud
Elasticsearch is a database?
1. Data definition
2. Update - CrUD
3. Retrieval - cRud
- relational databases
company: id name employees founded
-- --------------- --------- ------------
1 'CoolComp Ltd.' 10 '2014-10-05'
services: id value
company_services: id id_comp id_serv
--- ------- --------
1 1 1
2 1 2
person: id name
1 'Petar Petrovich'
2 'Ivan Ivić'
comp_management: id id_comp id_pers role
--- ------- ------- -----
1 1 1 CEO
2 1 2 MEM
Elasticsearch is “schemaless”
But it provides defining schema - mappings
Very important when setting up for search:
• data types - string, integer, float, date/tst,
boolean, binary, array, object, nested, geo,
• search analysers, boosting, etc.
- compared to RDBMS
But we loose some things what RDBMS offers:
• data validation / integrity
• removing data redundancy - normalization
• “fine grained” structure definition
• standard and common usage (SQL)
We had this example before:!
# curl -XGET 'http://localhost:9200/maindex/
_search?q=management.name:petar' # no type!
equivalent SQL query:!
from comp_management cm
inner join peron p
where lower(p.name) like '%peter%');
Retrieval - ES-QDSL
based on my experience, I would rather use ES:
• for searches: full text, fuzzy, multi field, multi
document types, multi indexes/databases
• in programming - better to convert/deal with
JSON than with ORM/raw SQL results
• single web page applications
Retrieval - SQL
on the other hand, I would rather use SQL and
• when composing complex query - easier to
do with SQL
• for data exploring/researching
SQL is much more expressive DSL
Joining & denormalization
object hierarchy … must be denormalized.
increases retrieval performance (since no query joining is
uses more space
makes keeping things consistent and up-to-date more difficult
They’re excellent for write-once-read-many-workloads
ES has several ways to “join” objects/documents/types:
1. embedding objects
2. “nested” objects
3. parent / child relation between types
4. compose manual query
When fetching by id - very handy (1 & 2).
When quering - not so handy.
Updating - CrUD !
I would rather use Elasticsearch:
• when creating, updating and deleting single
Updating - CrUD!
on the other hand, RDBS I found handy:
• for flat entities/documents
• for mass objects manipulation
• transactions & integrity (ACID)
ES + … - hybrid solution
So why can you use ElasticSearch as a single point
of truth (SPOT)?
Elasticsearch … used in addition to another
A database system for constraints, correctness and
robustness, transactionally updatable,
master record which is then asynchronously
pushed/pulled to Elasticsearch
besides classic indexing - rivers provide alternative way for inserting
data into ES
service that fetches the data from an external source (one shot or
periodically) and puts the data into the cluster
Besides listed on official site:
Use-case - RDBMS & Elasticsearch
• Indexing & reindexing subdocuments is major
• upsert mode
• issues - not indexing, memory hungry, full
reindex when new field/subdoc
• building AST when building a query - quite
• satisfied with the final result!
Riak & Solr
September 16, 2014 - With 2.0, we have added distributed Solr to Riak Search. For every
instance of Riak, there is an instance of Solr. While this drastically improves full-text search, it also
improves Riak’s overall functionality. Riak Search now allows for Riak to act as a document store
(instead of key/value) if needed.
Despite being a part of Riak, Riak Search is a separate Erlang application. It monitors for changes
to data in Riak and propagates those changes to indexes managed by Solr.
Couchbase and Elasticsearch
integrates Couchbase Server and Elasticsearch,
by streaming data in real-time from Couchbase to Elasticsearch.
combined solution … with full-text search, indexing and querying and real-time
analytics … content store or aggregation of data from different data sources.
Couchbase Server provides easy scalability, low-latency document access,
indexing and querying of JSON documents and real-time analytics with
incremental map reduce.
MongoDB and Elasticsearch
“addition of Elasticsearch
represents only a first step
in its mission to enable
developers to choose the
database that's right for
“big weakness of
MongoDB is the free text
search, which MongoDB
tried to address in version
2.4 in some aspects.”
Elasticsearch use when …
you need very good, reliable, handy, web oriented
search index engine
you have intensive read and document oriented
“write” balance - depending on how much - ES as
a NoSQL only or as a hybrid solution
no silver bullet, “the right tool for the job”
learn & get familiar with different solutions and
choose optimal one
be objective & productive
General trend are heterogenous => lot of
integration tasks lately
learn new things & have fun!
Thank you for your patience!