I’m glad to learn of this, but note that it’s from 2010.
Auto Complete with Redis (2010)
21–25 of 25 posts
Re: Auto Complete with Redis (2010)
#22Earlier quoted context omitted.
SQLite wins in one area that can be crucial -- simplicity. PostgreSQL is a fantastic and robust database, and it's FTS capabilities are almost certainly good-enough (especially if you consider SQLite's to be good-enough), but it is necessarily complex to support the amount of robustness it offers. SQLite offers a fraction of the robustness of Postgres, but that difference is not necessarily reflected in the correctne…
Make sure to also run a test with multiple threads concurrently interacting with SQLite. Due to SQLite's exclusive locking mechanism, this causes actual issues with concurrent writes and reads.
Incidentally, even that's not even an issue anymore, if you enable SQLite's write-ahead logging support:
Re: Auto Complete with Redis (2010)
#23Is this not a perfect use case for a trie? Can you make a trie in Redis?
I have not implemented a trie myself, but apparently the problem is they take up a lot of space: http://www.drdobbs.com/database/ternary-search-trees/1844105...
Re: Auto Complete with Redis (2010)
#24While i deeply love redis and have used this exact article in the past to build an autocomplete— I’d really not recommend it to anyone. Using something like elastic search provides much better and robust results. Yes it’s more work to setup but the maintenance and tweaking will be waaaay easier and more timely in the long run.
IDK, having survived many ... MANY ES outages, I’d take REDIS in a heartbeat if it gives me the functionality I need.
Re: Auto Complete with Redis (2010)
#25Earlier quoted context omitted.
IDK, having survived many ... MANY ES outages, I’d take REDIS in a heartbeat if it gives me the functionality I need.
it's amazing how every single person i know that used ES has had a freakton of bad experiences with ES. and it's still the only ok solution in this area.