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.
How we replaced Elasticsearch and MongoDB with Rust and RocksDB
41–50 of 104 posts
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#42Bit 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…
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#43Isn't RocksDB just the db engine for Kafka?
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#44I'm guessing it's closed source *aas only?
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#45It’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.
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#46Earlier 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…
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#47Earlier 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
Re: How we replaced Elasticsearch and MongoDB with Rust and RocksDB
#48Whenever 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
#49Slightly 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.
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.