top | item 15698662

Elasticsearch 6.0.0 GA released

192 points| haakon | 8 years ago |elastic.co | reply

86 comments

order
[+] eric_b|8 years ago|reply
The new sequence IDs are the most interesting things in this release I think. Having an officially supported cross datacenter replication strategy would be real nice.

Lots of folks will be mad, but removing multiple mapping types is a nice change too. It was a feature that never really made sense. Index-per-type was always the better strategy, even going back to the 0.23 days.

As others in this thread will no doubt point out though - the ES folks are moving awfully fast. I still support 1.7.5 clusters that will take heroic efforts to update. I'd love to use the new features on those clusters, but there simply isn't a valid business case to take on the risk. This isn't like small NPM packages that you can update on a whim - some of these systems require terabytes of re-indexing to upgrade :/

[+] naiv|8 years ago|reply
Cross data center replication is really a much needed feature.

The way Elasticsearch is going though looks promising. With sorted indices, single mapping type and the other changes we might give it another try after switching to Algolia.

Is there a safe way now to query Elasticsearch directly without the need to go via proxy scripts on the server? This just adds so much overhead to the queries compared to Algolia.

[+] taf2|8 years ago|reply
I wish after 1.x they had maintained backwards compatibility with upgrades as they had kind of promised... there is just so much money in making it hard to upgrade ;)
[+] ergo14|8 years ago|reply
Thing is the parent/child functionality required using multiple types in single index. So migrating from that is painful.
[+] sidi|8 years ago|reply
My biggest gripe with the 6.0.0 GA is the removal of multiple mapping types per index. This creates a significant breaking change that will hurt the community tools adoption to 6.0. Their initial plan was to deprecate it and only remove it v7 onwards, which imho would've been a better balance.
[+] pudo|8 years ago|reply
The removal of mapping types really kicks the bottom out of the app we're making; it's some serious docker-style "break all the things" behaviour. Seriously losing trust on this one.

Are there any good alternatives to ES? Has Solr moved?

[+] bpicolo|8 years ago|reply
The biggest problem with that is really how soon 6 has come after 5.
[+] 33degrees|8 years ago|reply
They haven't changed their plan: mapping types per index are only unsupported for new indices, old ones that are migrated will continue to work, until 7.
[+] dozzie|8 years ago|reply
> My biggest gripe with the 6.0.0 GA is the removal of multiple mapping types per index.

ROTFL. And I opened the comments wondering what breaks this time.

Every time I hear about a new release, ElasticSearch gets worse and worse option for storing logs.

[+] Qerub|8 years ago|reply
I'm excited about the official Docker images now being available (again?) in an OSS flavor without X-Pack. Quote from https://www.elastic.co/guide/en/elasticsearch/reference/6.0/... :

> The images are available in three different configurations or "flavors". The basic flavor, which is the default, ships with X-Pack Basic features pre-installed and automatically activated with a free licence. The platinum flavor features all X-Pack functionally under a 30-day trial licence. The oss flavor does not include X-Pack, and contains only open-source Elasticsearch.

[+] praseodym|8 years ago|reply
The pre-installed X-Pack basic license sounds great as well: this at least allows one to use features like monitoring, dev tools and the upgrade assistant out of the box, without the 30-day trial kicking in as was the case for the 5.x Docker images.
[+] jdhawk|8 years ago|reply
I really wish they'd included the ElasticSearch SQL in 6.0, but I guess that feature still isn't fully baked.

Even if it didn't have the full power of the Elastic JSON Queries, for simple SELECT COUNT() ..GROUP BY, it would have been a nice addition...oh well, back to counting open and closed brackets...

[+] laichzeit0|8 years ago|reply
Yeah, interesting some companies have already created their own DSL that looks like SQL for ES, e.g. AppDynamics

https://docs.appdynamics.com/m/mobile.action#page/42584918

The data is mainly used for dashboards (which is Highcharts) so the aggregation functions map to something called a “series”, which is what you’d expect if you’ve ever used Highcharts. Anyway I think it’s quite cool how they did it.

[+] djhworld|8 years ago|reply
We're just in the process of looking into ElasticSearch for an analytics use case, most of the queries we will be doing are simple group by aggregations with count/sums etc

A SQL interface would help a lot, even better if it came with a JDBC driver

[+] yehosef|8 years ago|reply
check out dremio.com - It's superduper Apache Drill with elasticsearch support (ie SQL with real joins.)
[+] jordanab|8 years ago|reply
In a large internal project we still make heavy use of Groovy for scripting. All scripting languages besides the new Painless language were deprecated in version 5, and now in version 6 they are removed. This hampers us in our migration efforts from 5 to 6. Does anyone know if it is still possible to use Groovy through a separate (third party) plugin? I played around a bit with Painless, but can't say that I really like it. Documentation was/is kind of poor, and it seemed to me it somewhat assumed familiarity with Java and it's framework/APIs.
[+] laichzeit0|8 years ago|reply
They deprecated all scripting langs? Ok this is something new I learned in this thread. That is an extremely lame deprecation. Is ElasticSearch the new Apple? “let’s remove as much functionality as possible for the sake of being as minimal as possible”.

Groovy is a fantastic language. It really is a hidden gem. It is my language of choice for cross-platform work, especially in enterprise.

[+] sbr464|8 years ago|reply
Very much appreciate the improvements to handling docs with sparse fields!
[+] lclarkmichalek|8 years ago|reply
Does Lucene 7.0 have a better story around G1 GC? ES has always warned against it, would love to see if that had changed
[+] dakrone|8 years ago|reply
We revisit the G1GC recommendation every once it a while. In fact, I am doing benchmarks and testing for G1GC versus CMS with Elasticsearch 6.0.0 right now, so that we have a better idea of where we stand.

Disclaimer: I'm an Elasticsearch dev employed by Elastic.

[+] notimetorelax|8 years ago|reply
We run ES on G1GC, have been doing this for the last 3 years. With heaps of more than 20gb in size and a lot of churn CMS just doesn’t cut it. What helps is a high number of replicas to help with any potential corruptions, and that we never treat ES as a primary store.
[+] sschueller|8 years ago|reply
Off topic but how do you guys Unit Test Elastic Search queries? Do you start a full node and dump test data in it?

In case of SQL I can start an in memory sqllite and run my tests (Symfony PHP).

[+] gerbal|8 years ago|reply
We've had good results using docker-compose to run ES test suites. Run the app in one container and an ES instance in another.

Test data can be loaded from fixtures or captured/snapshotted using `docker commit` to create specific test images.

[+] chatman|8 years ago|reply
Not as exciting as Solr 7 release.
[+] liveoneggs|8 years ago|reply
I've been using solr since 1.3 and found trying to use elastic is pretty crazy annoying. I'd love to swap the ELK stack for a solar-based setup.