Live data from Hacker News

How we replaced Elasticsearch and MongoDB with Rust and RocksDB

radar.com

41–50 of 104 posts

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#41
post #7

Slightly meta, but I find its a good sign that we're back to designing and blogging about in-house data storage systems/ Query engines again. There was an explosion of these in the 2010's which seemed to slow down/refocus on AI recently.

Is it good? What's left to innovate on in this space? I don't really want experimental data stores. Give me something rock solid.

[dead]

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#42

Bit thin on details and not looking like they’ll open source it, but if someone clicked the post because they’re looking for their “replace ES” thing: Both https://typesense.org/ and https://duckdb.org/ (with their spatial plugin) are excellent geo performance wise, the latter now seems really production ready, especially when the data doesn’t change that often. Both fully open source including clustered/sharded setu…

DuckDB does not have any kind of sharding or clustering? It doesn't even have a server (unless you count the HTTP Server Extension)?

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#45

It’s interesting as someone in the search space how many companies are aiming to “replace Elasticsearch”

In my experience, the care and feeding that goes into an Elastic Search cluster feels like it's often substantially higher than that involved in the primary data store, which has always struck me as a little odd (particularly in cases where the primary data store is an RDBMS). I'd be very happy to use simpler more bulletproof solutions with a subset of ES's features for different use cases.

I'm interested in this detail because a few years back I was involved in a major big data project at a health insurance company and I cooked up a solution that involved ElasticSearch that was workable only to be shot down--it was political, but they had to do it with Kafka, full stop. The problem was, at that time, Kafka wasn't very mature and it wasn't a good solution for the problem, regardless. So our ES version got shelved.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#46
post #16

Earlier quoted context omitted.

In my experience, the care and feeding that goes into an Elastic Search cluster feels like it's often substantially higher than that involved in the primary data store, which has always struck me as a little odd (particularly in cases where the primary data store is an RDBMS). I'd be very happy to use simpler more bulletproof solutions with a subset of ES's features for different use cases.

To add another data point: After working with ES for the past 10 years in production I have to say that ES is never giving us any headaches. We've had issues with ScyllaDB, Redis etc. but ES is just chugging along and just works. The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and ki…

The thing I like about ES: When the business comes around and adds new requirements out of nowhere, the answer is always: "Yup, we can do it!" Unlike other tools such as Cassandra that force a data design from the get go and make it expensive to change later on.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#47

Earlier quoted context omitted.

how many clusters, how many indexes and how many documents per index? do you use self hosted es or aws managed opensearch?

Lots of other options here if you don't like managing. You can use Elastic cloud, Bonsai.io, and others

A lot of places can't put their data just anywhere.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#48
Rocks is a fork of Level, and Level is well known for data corruption and other bugs. They are both "run at production scale", but at least back when I worked on stuff that used Level, nobody talked publicly about all the toil spent on cleaning up and repairing Level to keep the services based on it running.

Whenever you see an advertisement like this (these posts are ads for the companies publishing them), they will not be telling you the full truth of their new stack, like the downsides or how serious they can be (if they've even discovered them yet). It's the same for tech talks by people from "big name companies". They are selling you a narrative.

Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB

#49
post #7

Slightly meta, but I find its a good sign that we're back to designing and blogging about in-house data storage systems/ Query engines again. There was an explosion of these in the 2010's which seemed to slow down/refocus on AI recently.

It slowed down not because of AI, but because it turned out it was mostly pointless. Highly specialized stacks that could usually be matched in performance by tweaking an existing system or scaling a different way.

In-house storage/query systems that are not a product being sold by itself are NIH syndrome by a company with too much engineering resources.

Post reply on HN