# Difference between db and elasticsearch **URL:** \ **Category:** Elasticsearch\ **Created:** [January 5, 2012, 1:00am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289 "2012-01-05T01:00:29Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![Mohit\_Anchlia](https://avatars.discourse-cdn.com/v4/letter/m/848f3c/32.png) [@Mohit\_Anchlia](https://discuss.elastic.co/u/Mohit_Anchlia)\ **Post date:** [January 5, 2012, 1:00am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/1 "2012-01-05T01:00:29Z")
Please throw some light on this because I am unable to think of reasons why elasticsearch shouldn't just be used as real time database. Since with DB you need to write and then for most part run queries on them. So if elasticsearch is scalable and distributed then why can't elasticsearch be used as db itself? I am trying to understand the disadvantages of thinking elasticsearch as database. ---
**Author:** ![otisg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/otisg/32/492_2.png) [@otisg](https://discuss.elastic.co/u/otisg)\ **Post date:** [January 5, 2012, 5:47am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/2 "2012-01-05T05:47:23Z")
Hi Mohit, You are not the first person to wonder about this. Check the ML archives. Yes, some people use ES and similar systems in place of technologies with "database" in their names. Otis On Jan 4, 8:00 pm, Mohit Anchlia [mohitanch...@gmail.com](mailto:mohitanch...@gmail.com) wrote: > Please throw some light on this because I am unable to think of > reasons why elasticsearch shouldn't just be used as real time > database. Since with DB you need to write and then for most part run > queries on them. So if elasticsearch is scalable and distributed then > why can't elasticsearch be used as db itself? I am trying to > understand the disadvantages of thinking elasticsearch as database. ---
**Author:** ![Douglas\_Muth](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/douglas_muth/32/29006_2.png) [@Douglas\_Muth](https://discuss.elastic.co/u/Douglas_Muth)\ **Post date:** [January 5, 2012, 3:12pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/3 "2012-01-05T15:12:16Z")
On Wed, Jan 4, 2012 at 8:00 PM, Mohit Anchlia [mohitanchlia@gmail.com](mailto:mohitanchlia@gmail.com) wrote: > Please throw some light on this because I am unable to think of > reasons why elasticsearch shouldn't just be used as real time > database. Since with DB you need to write and then for most part run > queries on them. So if elasticsearch is scalable and distributed then > why can't elasticsearch be used as db itself? I am trying to > understand the disadvantages of thinking elasticsearch as database. It's been my experience much easier to do some things in databases that you can't easily in ES, such GROUP BY and especially ORDER BY operations. If you're looking for a database that does sharding/replication, check out Cassandra. -- Doug ---
**Author:** ![nurikabe](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/nurikabe/32/2192_2.png) [@nurikabe](https://discuss.elastic.co/u/nurikabe)\ **Post date:** [January 5, 2012, 3:15pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/4 "2012-01-05T15:15:21Z")
We are experimenting with ES as a database of sorts for documents. I wouldn't want to use it for complex relational data, but it's great for documents and corresponding metadata. ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [January 5, 2012, 6:24pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/5 "2012-01-05T18:24:56Z")
It all depends on what your requirements are. Despite all the advances that Lucene has made (especially with the latest 3.5 release), Lucene (and therefore Elasticsearch) is still not realtime. Not everyone needs access to the latest commit, so Elasticsearch works great in those scenarios. Just like most other NoSQL systems, you lose many RDBMS benefits such as transactions and joining between tables (types/docs/whatever). The loss of atomic updates is a big hurdle for many. Working with documents however, can be very liberating after being stuck in the relation world for years. -- Ivan On Thu, Jan 5, 2012 at 7:15 AM, nurikabe [eaowens@gmail.com](mailto:eaowens@gmail.com) wrote: > We are experimenting with ES as a database of sorts for documents. I > wouldn't want to use it for complex relational data, but it's great for > documents and corresponding metadata. ---
**Author:** ![Stanislas\_Polu](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/stanislas_polu/32/2873_2.png) [@Stanislas\_Polu](https://discuss.elastic.co/u/Stanislas_Polu)\ **Post date:** [January 5, 2012, 6:54pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/6 "2012-01-05T18:54:04Z")
Can someone elaborate on the realtime limitations of Elasticsearch? My understanding was that it was pretty good at it. And that's been verified for me so far. Cheers -stan On Jan 5, 2012, at 7:24 PM, Ivan Brusic [ivan@brusic.com](mailto:ivan@brusic.com) wrote: > It all depends on what your requirements are. > > Despite all the advances that Lucene has made (especially with the > latest 3.5 release), Lucene (and therefore Elasticsearch) is still not > realtime. Not everyone needs access to the latest commit, so > Elasticsearch works great in those scenarios. > > Just like most other NoSQL systems, you lose many RDBMS benefits such > as transactions and joining between tables (types/docs/whatever). The > loss of atomic updates is a big hurdle for many. Working with > documents however, can be very liberating after being stuck in the > relation world for years. > > -- > Ivan > > On Thu, Jan 5, 2012 at 7:15 AM, nurikabe [eaowens@gmail.com](mailto:eaowens@gmail.com) wrote: > > > We are experimenting with ES as a database of sorts for documents. I > > wouldn't want to use it for complex relational data, but it's great for > > documents and corresponding metadata. ---
**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\ **Post date:** [January 5, 2012, 7:06pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/7 "2012-01-05T19:06:52Z")
There is a reason why Lucene is calling it "near real time" and not real time. 🙂 Lucene is good at it, but there are certain scenarios were a commit needs to be propagated immediately, which Lucene cannot handle. > **[Lucene's near-real-time search is fast!](https://blog.mikemccandless.com/2011/06/lucenes-near-real-time-search-is-fast.html)** > > Lucene's near-real-time (NRT) search feature, available since 2.9, enables an application to make index changes visible to a new searcher wi... -- Ivan On Thu, Jan 5, 2012 at 10:54 AM, Stanislas Polu [polu.stanislas@gmail.com](mailto:polu.stanislas@gmail.com) wrote: > Can someone elaborate on the realtime limitations of Elasticsearch? > > My understanding was that it was pretty good at it. And that's been verified for me so far. > > Cheers > > -stan > > On Jan 5, 2012, at 7:24 PM, Ivan Brusic [ivan@brusic.com](mailto:ivan@brusic.com) wrote: > > > It all depends on what your requirements are. > > > > Despite all the advances that Lucene has made (especially with the > > latest 3.5 release), Lucene (and therefore Elasticsearch) is still not > > realtime. Not everyone needs access to the latest commit, so > > Elasticsearch works great in those scenarios. > > > > Just like most other NoSQL systems, you lose many RDBMS benefits such > > as transactions and joining between tables (types/docs/whatever). The > > loss of atomic updates is a big hurdle for many. Working with > > documents however, can be very liberating after being stuck in the > > relation world for years. > > > > -- > > Ivan > > > > On Thu, Jan 5, 2012 at 7:15 AM, nurikabe [eaowens@gmail.com](mailto:eaowens@gmail.com) wrote: > > > > > We are experimenting with ES as a database of sorts for documents. I > > > wouldn't want to use it for complex relational data, but it's great for > > > documents and corresponding metadata. ---
**Author:** ![Karussell1](https://avatars.discourse-cdn.com/v4/letter/k/50afbb/32.png) [@Karussell1](https://discuss.elastic.co/u/Karussell1)\ **Post date:** [January 5, 2012, 9:43pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/8 "2012-01-05T21:43:34Z")
Here are some links (it all depends on your requirements): [http://stackoverflow.com/questions/6636508/elastic-search-as-a-database](http://stackoverflow.com/questions/6636508/elastic-search-as-a-database) > It's been my experience much easier to do some things in databases > that you can't easily in ES, such GROUP BY and especially ORDER BY > operations. What is the problem with ORDER BY and Elasticsearch? Peter. ---
**Author:** ![Douglas\_Muth](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/douglas_muth/32/29006_2.png) [@Douglas\_Muth](https://discuss.elastic.co/u/Douglas_Muth)\ **Post date:** [January 5, 2012, 9:53pm UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/9 "2012-01-05T21:53:19Z")
On Thu, Jan 5, 2012 at 4:43 PM, Karussell [tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com) wrote: > What is the problem with ORDER BY and Elasticsearch? Sorting by an integer? Not a problem. Sorting by something that's a single word? Not a problem. Sorting by a field that has multiple words? Problem. As I understand it, if you index the following string: "the quick fox jumps over the lazy cheetah", Elastic Search analyzes it and stores it like this: ["the", "quick", "fox", "jumps", "over", "the", "lazy", "cheetah"] Kinda hard to sort an array, no? 🙂 Now, there are some workarounds, such as not analyzing that field, or storing an "untouched" version of that field alongside of the analyzed version. However, the former method means you can't search on that field and the latter method means more disk space is used up. At least, I'm about 90% sure that this is how it works, as I just dealt with this issue for the first time uh, 2 days ago. If I'm horribly wrong, someone please correct me. 😛 -- Doug [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![Lukas\_Vlcek1](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/lukas_vlcek1/32/819_2.png) [@Lukas\_Vlcek1](https://discuss.elastic.co/u/Lukas_Vlcek1)\ **Post date:** [January 6, 2012, 12:28am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/10 "2012-01-06T00:28:23Z")
Hi, Did you check script based sorting? That means, analyze the field, but sort based on the original \_source value of that field. [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/api/search/sort.html) (check script based sorting) [Elasticsearch Platform — Find real-time answers at scale | Elastic](http://www.elasticsearch.org/guide/reference/modules/scripting.html) (check source field) Regards, Lukas On Thu, Jan 5, 2012 at 10:53 PM, Douglas Muth [doug.muth@gmail.com](mailto:doug.muth@gmail.com) wrote: > On Thu, Jan 5, 2012 at 4:43 PM, Karussell [tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com) > wrote: > > > What is the problem with ORDER BY and Elasticsearch? > > Sorting by an integer? Not a problem. Sorting by something that's a > single word? Not a problem. Sorting by a field that has multiple > words? Problem. > > As I understand it, if you index the following string: "the quick fox > jumps over the lazy cheetah", Elastic Search analyzes it and stores it > like this: > > ["the", "quick", "fox", "jumps", "over", "the", "lazy", "cheetah"] > > Kinda hard to sort an array, no? 🙂 > > Now, there are some workarounds, such as not analyzing that field, or > storing an "untouched" version of that field alongside of the analyzed > version. However, the former method means you can't search on that > field and the latter method means more disk space is used up. > > At least, I'm about 90% sure that this is how it works, as I just > dealt with this issue for the first time uh, 2 days ago. If I'm > horribly wrong, someone please correct me. 😛 > > -- Doug > [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![plaflamme](https://avatars.discourse-cdn.com/v4/letter/p/a88e57/32.png) [@plaflamme](https://discuss.elastic.co/u/plaflamme)\ **Post date:** [January 6, 2012, 12:38am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/11 "2012-01-06T00:38:08Z")
And how would you expect a database to sort rows with a column containing "the quick brown fox..."? Isn't this what "scoring" results is about? Using term frequencies and other goodies...? Philippe On Thu, Jan 5, 2012 at 16:53, Douglas Muth [doug.muth@gmail.com](mailto:doug.muth@gmail.com) wrote: > On Thu, Jan 5, 2012 at 4:43 PM, Karussell [tableyourtime@googlemail.com](mailto:tableyourtime@googlemail.com) > wrote: > > > What is the problem with ORDER BY and Elasticsearch? > > Sorting by an integer? Not a problem. Sorting by something that's a > single word? Not a problem. Sorting by a field that has multiple > words? Problem. > > As I understand it, if you index the following string: "the quick fox > jumps over the lazy cheetah", Elastic Search analyzes it and stores it > like this: > > ["the", "quick", "fox", "jumps", "over", "the", "lazy", "cheetah"] > > Kinda hard to sort an array, no? 🙂 > > Now, there are some workarounds, such as not analyzing that field, or > storing an "untouched" version of that field alongside of the analyzed > version. However, the former method means you can't search on that > field and the latter method means more disk space is used up. > > At least, I'm about 90% sure that this is how it works, as I just > dealt with this issue for the first time uh, 2 days ago. If I'm > horribly wrong, someone please correct me. 😛 > > -- Doug > [http://twitter.com/dmuth](http://twitter.com/dmuth) ---
**Author:** ![Douglas\_Muth](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/douglas_muth/32/29006_2.png) [@Douglas\_Muth](https://discuss.elastic.co/u/Douglas_Muth)\ **Post date:** [January 6, 2012, 12:44am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/12 "2012-01-06T00:44:28Z")
On Thu, Jan 5, 2012 at 7:38 PM, Philippe Laflamme [philippe.laflamme@obiba.org](mailto:philippe.laflamme@obiba.org) wrote: > And how would you expect a database to sort rows with a column containing > "the quick brown fox..."? Alphabetically, of course. The issue I ran into the other day was trying to sort results by the name of a venue, ignoring what the score was. Easily enough done in a traditional SQL database, but a little more difficult in Elastic Search. (Of course, this meant completely disregarding the scoring the results...) -- Doug ---
**Author:** ![medcl\_net](https://avatars.discourse-cdn.com/v4/letter/m/90ced4/32.png) [@medcl\_net](https://discuss.elastic.co/u/medcl_net)\ **Post date:** [January 10, 2012, 4:20am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/13 "2012-01-10T04:20:01Z")
anybody did a performance test with the script based sorting? i am wondering if sorting on a large dataset with script will be very slow -----Original Message----- From: Douglas Muth Sent: Friday, January 06, 2012 8:44 AM To: [elasticsearch@googlegroups.com](mailto:elasticsearch@googlegroups.com) Subject: Re: Difference between db and elasticsearch On Thu, Jan 5, 2012 at 7:38 PM, Philippe Laflamme [philippe.laflamme@obiba.org](mailto:philippe.laflamme@obiba.org) wrote: > And how would you expect a database to sort rows with a column containing > "the quick brown fox..."? Alphabetically, of course. The issue I ran into the other day was trying to sort results by the name of a venue, ignoring what the score was. Easily enough done in a traditional SQL database, but a little more difficult in Elastic Search. (Of course, this meant completely disregarding the scoring the results...) -- Doug ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [January 10, 2012, 9:01am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/14 "2012-01-10T09:01:47Z")
You can always mark the field as not analyzed in the mapping (or use multi field mapping for analyzed and not analyzed versions) and then sort based on it. On Fri, Jan 6, 2012 at 2:44 AM, Douglas Muth [doug.muth@gmail.com](mailto:doug.muth@gmail.com) wrote: > On Thu, Jan 5, 2012 at 7:38 PM, Philippe Laflamme > [philippe.laflamme@obiba.org](mailto:philippe.laflamme@obiba.org) wrote: > > > And how would you expect a database to sort rows with a column containing > > "the quick brown fox..."? > > Alphabetically, of course. > > The issue I ran into the other day was trying to sort results by the > name of a venue, ignoring what the score was. Easily enough done in a > traditional SQL database, but a little more difficult in Elastic > Search. (Of course, this meant completely disregarding the scoring > the results...) > > -- Doug ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 3:43am UTC](https://discuss.elastic.co/t/difference-between-db-and-elasticsearch/6289/15 "2017-07-06T03:43:14Z")