Hacker News Reader

Comment by nostrademons | Hacker News Reader

If you're doing an autocomplete widget, you probably want to store all of your data in RAM rather than in any DB. Autocomplete queries fire on every keystroke from every user, so if you hit the DB at all, you've probably killed your server.

View on HN

Well, I guess the DB already has caching logic to keep things in memory. Or otherwise, it is not such a good DB system.

Most have some sort of caching logic but you can't rely on it to do what you want. Always benchmark, and never assume that just because you're paying for something or that it's the industry standard, it does what you want. I've seen a number of devs completely surprised by the throughput & latency numbers they get from their databases because they assume everything is going to be cached in RAM and the database is really hitting disk for some obscure reason on every query.

Usually this is due to dev ignorance of the five-minute rule and/or a failure to properly account for size of data.

That being said, it really depends on the problem at hand and the overall workload of the database.

This is all really hypothetical. Show me a DB that can do tries first.

You're the one insisting that this technique has to involve a database. It really doesn't!

http://lucene.apache.org/solr/

Postgres with SP-GiST, for example

The database is doing row caching, though, and isn't going to be caching lower levels of the trie in close proximity to the higher ones. It's not the same logic in the general case. At a prior gig with a very heavily used typeahead, we loaded the entire thing into a memory cache inside our typeahead service, because even relying on memcache was too slow.

Reply on news.ycombinator.com