4 ms·
Postgresql is quite good easy to integrate alternative to Elastic. It has built-in fulltext search: https://www.postgresql.org/docs/12/textsearch.html https://
by elephantum 7y ago
Postgresql is quite good easy to integrate alternative to Elastic.
It has built-in fulltext search: https://www.postgresql.org/docs/12/textsearch.html https://www.postgresql.org/docs/12/textsearch.html
- mfrye0 7y agoAgreed. We've been using this successfully for awhile now. I'm curious though at what point something like this or ES itself would make sense for primarily text search. Is speed the biggest thing, or is it more flexibility to tweak and get better search results?
- maxmcd 7y agoSearch is somewhat embarrassingly parallel right? So Postgres is great until you want to shard all of your queries. Which is (of course) possible, but then you're using attributes of a tool that aren't specifically tailored to your problem space? Postgres full text search is fast and easy, but it doesn't seem much more scaleable/reliable/resilient than a clustered search solution that is shaped to the problem at hand.
- fulmicoton 7y agoIs it fast though !?
- rpedela 7y agoPostgres is fine if your search problem is mostly a recall problem. If N is large enough or you have small N with enough overlapping keywords (long documents) then precision becomes important. That is when you need things like BM25, PageRank, machine learning, etc and Postgres just doesn't cut it anymore. Additionally spell check, high-quality autocomplete, multiple languages are better supported and much easier to implement in ES/Solr.
- deleted 7y ago[deleted]
- manigandham 7y agoPostgres FTS is very basic and requires separate methods and extensions to do things like fuzzy matching. It also doesn't support modern relevance and ranking algorithms.
- devy 7y agoMulti-faceted search that requires special indexing setup.