Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Elasticsearch 6.0+ #306

Open
daniellienert opened this issue May 17, 2019 · 3 comments

Comments

@daniellienert
Copy link
Contributor

commented May 17, 2019

Its about time to support Elasticsearch versions > 6.0 as the currently supported version 5.6 is EOL since 2019-3-11 (https://www.elastic.co/support/eol).

As you may know, the main issue is the removal of the Type feature (https://www.elastic.co/guide/en/elasticsearch/reference/5.6/removal-of-types.html) which was used to separate the different node types.
There are two different approaches to solve this, using an explicit type field and one type per index.

The one-type-per-index option would make it possible to give an equal named property in two different node types different data types. Since ES 2.x thats not possible anymore. The disadvantage is, that this approach would end up in a lot of indexes / shards - especially when multiplied with separate indexes per language.

In big projects with a lot of NodeTypes and languages, this could easily reach ES recommended limits - see:

The explicit-type-field approach would keep the number of shards small and would have no disadvantages in terms of data types to the current situation. It is also way easier to implement.

So I would prefer the explicit type field approach.

@johannessteu

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

I think due to the architecture of neos there is no real option beside a custom type field at all.

@dfeyer

This comment has been minimized.

Copy link
Member

commented May 20, 2019

I think due to the architecture of neos there is no real option beside a custom type field at all.

I agree, we will explode the number of shard on big project, ... and those project really need Elastic, so better to not take any risk just for the shake of property name colisision.

@kitsunet

This comment has been minimized.

Copy link
Member

commented Aug 14, 2019

risk just for the shake of property name colisision
that problem exists today already so I guess we do not loose much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.