Live data from Hacker News

How we replaced Elasticsearch and MongoDB with Rust and RocksDB

radar.com

101–104 of 104 posts

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

#101
post #100
post #98

Earlier quoted context omitted.

Sure they can handle the basic case of ANN. But ANN still doesn’t have good stories for lots of real-world problems. * filterable ANN, decomposes into prefiltering or postfiltering. * dynamic updates and versioning is still very difficult * slow building of graph indexes * adding other signals into the search, such as query time boosting for recent docs. I don’t disagree these systems can work but innovation is still…

* Filterable ANN certainly decomposes into pre- and post-filtering, and there is definitely a lot of interesting innovation occurring around filterable ANN. But large-scale search systems currently do a pretty good job with pre-filtering, falling back to brute force search in the case of restrictive filters. * You'd have to be a bit more exact re: dynamic updates/versioning for me to understand the challenges you're…

Might be missing my argument here - I stated that there are workable solutions to this like you have pointed out.

But ANN search is still a sledgehammer and building out hybrid solutions that help bridge the gap between this and traditional data stores still have room for innovation.

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

#102

Lol I "love" that the first benefit this company lists in their jobs page is "In-Office Culture". Do people actually believe that having to commute is a benefit ?

> Do people actually believe that having to commute is a benefit?

Everything is subjective here. I don't love commuting, but I'm remote now and there are days I kind of miss it. I got a lot more podcasting listening in when I did which I really do miss, and I enjoyed getting out of the house, on a schedule, and seeing my city and area.

As for BEING in the office, yes I also miss that. I miss the friendships with people from other parts of the org that I made; I miss the getting together at lunch and talking about both work and non-work stuff; I miss the pinball machines that one enthusiast set up.

THAT SAID, I abhor the _requirement_ to be in an office; it's a top down, heavy handed, hamfisted attempt at trying to force something that IMO can only come naturally, under the guise of "CuLtUrE!", and unless forced to I won't consider any job that requires it. (NB: This, too, is a tradeoff - if it's close to my house and I've got some latitude as to what time to make it there so I can have some freedom to avoid the heaviest of traffic, sure.)

This is just another example of the "open office" concept. When that came out everyone hated it except for the C-suite that didn't have to do it, under the mistaken idea that it forces "collaboration, which is good", when the reality was that the "good" part was emergent, holistic, and natural, and any forcing function kills it. But of course we also know that it was nothing but a cost-savings issue, and the "collaboration" argument was a gaslight retcon of the highest order. Open offices actually worked when PART of the office was open, allowing collaboration _as needed_ and driven by the teams/groups that wanted to do it, not by management. RTO is exactly the same.

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

#103
post #101
post #100

Earlier quoted context omitted.

* Filterable ANN certainly decomposes into pre- and post-filtering, and there is definitely a lot of interesting innovation occurring around filterable ANN. But large-scale search systems currently do a pretty good job with pre-filtering, falling back to brute force search in the case of restrictive filters. * You'd have to be a bit more exact re: dynamic updates/versioning for me to understand the challenges you're…

Might be missing my argument here - I stated that there are workable solutions to this like you have pointed out. But ANN search is still a sledgehammer and building out hybrid solutions that help bridge the gap between this and traditional data stores still have room for innovation.

Fair enough - agreed there's lots of interesting innovations here - but my point is that semantic search and its associated issues don't really differ that much from other types of search problems at scale, and I therefore don't think that the current crop of vector database products add a lot of value from a technical perspective (perhaps they do from an ease-of-use perspective; or they work great at small scale, etc. etc.)

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

#104
post #90

Earlier quoted context omitted.

I guess not having that would only breaking forward geocoding from an address?

My guess is that they're using FastText for semantic search, so it's more likely to break queries like "coffee near me" than address search, the latter likely being handled by tantivy. For context, I've also written a geocoder [0] based on tantivy. :) [0] https://github.com/ellenhp/airmail

Wow Airmail looks awesome. Have you ever benchmarked it on latency? I'm working on geocoding solutions for AI agents so quick tool calls is really important.
Post reply on HN