News for hackers. Stuff that matters.
Re:Stateless – Your new state of find with Elasticsearch by jgb1984 on Friday October 07, 2022 @02:04AM (#33117937)
So they will be forcing my few dozen terabyte ES cluster that today runs fully on dedicated physical hardware to use extremely expensive cloud storage services instead? What an awful idea!

I hope the option to fully self-host on dedicated hardware remains viable, as I enjoy the high performance, low price and full control of my own systems.

Re:Stateless – Your new state of find with Elasticsearch by jillesvangurp on Friday October 07, 2022 @02:32AM (#33118085)
You can easily emulate object storage with e.g. s3 compatible APIs. And probably it will just support whatever file system, including nfs (currently not supported). So, that should not be a show stopper. And technically this could actually reduce your cost by a lot because you will be able to use some central network storage instead of having to have a lot of high end SSDs. You might still want to use those for caching of course. But getting rid of some of the data replication probably might actually help lower your cost.

As Elasticsearch is closed source, you can also choose to switch to Opensearch which will of course not get any of these changes. Though I would not be surprised to see this move mirrored on their side as it makes a lot of sense to do this. But it would end up being an independent implementation of the same concept.

As a long time Elasticsearch user, this stateless architecture makes a lot of sense to me. Especially for very large clusters. Basically, it vastly simplifies scaling and cluster operations. You can literally auto scale nodes both on the indexing and querying tiers. That's a big deal. You want it faster? Add more nodes. Likewise upgrades are a lot easier. Simply bring new nodes online and re-index to some new objects. Once it is done, take down the old ones. Also it simplifies testing. You can simply bring up a few test nodes and query your production data without having to worry about affecting production loads. Everything gets easier.

It will be interesting to see how they will bring this to market. This reads like they are starting the work on this, not like they are ready to deploy this. I guess this would be part of a future major release and they just had their previous one fairly recently.

[dead]
Re:Stateless – Your new state of find with Elasticsearch by Hamcha on Friday October 07, 2022 @06:39AM (#33119515)
Probably meant "Source available" since neither Elasticsearch code licenses are "Open source" (going by OSI approval).
Re:Stateless – Your new state of find with Elasticsearch by petabite on Monday October 10, 2022 @04:47AM (#33149218)
We're not really talking licenses here. The very definition of "open source", according to OSI, is: "Open source software is software with source code that anyone can inspect, modify, and enhance."

Elasticsearch meets the above definition.

The permissiveness of the modification and enhancement is a different topic.

Re:Stateless – Your new state of find with Elasticsearch by yazaddaruvala on Friday October 07, 2022 @05:49AM (#33119242)
> You can easily emulate object storage with e.g. s3 compatible APIs

This seems right in theory, but when you actually look at the details it stops being true.

Specifically, Lucene today is best served through memory mapping the files and using crazy amounts of RAM.

My guess, Elastic just no longer cares about latency sensitive users. Even going from ES 5 to ES 7 there was a performance reduction for queries using any multi-word synonyms. It’s likely this trend is set to continue with remote storage.

I still think it’s the correct trade off for ES. Most of their clients use them for latency-insensitive analytics/log type stuff.

Re:Stateless – Your new state of find with Elasticsearch by ignoramous on Friday October 07, 2022 @02:37AM (#33118111)
I believe it would be cheaper to run stateless (given the reduced overhead of devops)? It is an open secret that the most expensive commodity in a datacenter (servers) is also the most under utilised. Hence, folks like me prefer to pay per-query cost.

Elastic had to do this in face of competition from the likes of quickwit.io and snowflake search. AWS might have something similar up their sleeve, because I don't believe Athena/Trino can do super fast searches, yet.

Re:Stateless – Your new state of find with Elasticsearch by danw1979 on Friday October 07, 2022 @02:13AM (#33117993)
Fingers crossed they support any S3-compatible local object storage system (e.g. Ceph) then all you need to do is completely change your storage system and probably duplicate it’s capacity during migration.

If this is the future of ES I don’t see a happy path for non-cloud customers…

Re:Stateless – Your new state of find with Elasticsearch by _jezell_ on Friday October 07, 2022 @02:28AM (#33118065)
minio
Re:Stateless – Your new state of find with Elasticsearch by More-nitors on Friday October 07, 2022 @02:52AM (#33118200)
...which means another layer that eats up performance?
Re:Stateless – Your new state of find with Elasticsearch by robertlagrant on Friday October 07, 2022 @07:55AM (#33120027)
> Fingers crossed they support any S3-compatible local object storage system

Do you mean they "only support"?

Re:Stateless – Your new state of find with Elasticsearch by cavisne on Friday October 07, 2022 @11:45PM (#33129630)
What they are really doing is offloading the job of persisting data from ES.

So you wouldn't need to use S3 or some s3 emulator like other comments have suggested.

Give the ES cluster a disk it can write to that is guaranteed to be replicated (ie a RAID cluster) and thats it. The limits of object storage (no appending, no in place editing) tend to make those clusters cheaper so you could also run something like Ceph locally. It's probably going to do a better job of persisting data than ES also.