3 ms·

With that little information from the OP the answer is probably: Use ES or if it's a small side project use your DB's included full text search if it's good eno

by dewey 8y ago

With that little information from the OP the answer is probably: Use ES or if it's a small side project use your DB's included full text search if it's good enough.

brightball 8y ago
You can go far using purely Postgres full text search. I ported a site from Solr to PG full text because of strange syncing issues and it was just as fast. Afterwards I never really saw the point of any of the search systems other than elastic search because the streaming capabilities that it gives you.
- mistrial9 8y ago
  agree, and add your own caching. Lots of pop in the web world comes from layers of well-built caching.
  - sethrin 8y ago
    This is probably true in many more ways than I am aware of. Do you have any other good examples or resources to suggest?
danielecook 8y ago
When is a full text search within a DB not good enough? Is ES usually used along side a typical RDS or is it a replacement?
- dewey 8y ago
  I don't have a lot of experience with PG full text search in production or a bigger scale. I'd just suspected that it doesn't perform that well if you need a lot of filters, range queries etc? Maybe someone with more experience can chime in. At work we just materialize the data from PG into ES and take advantage of the powerful ES queries and redundancy. Scaling up by just adding nodes is easier.
  - dominotw 8y ago
    How do you verify that all the data moved into ES from pg and what got lost in transit.
    - dewey 8y ago
      For our use case we don't really need a strict verification. Everything that should go to ES is put in a queue (using DB triggers) and then sent off to ES. If something should cause errors we'd see that by observing the error rate on ES ingest I assume.
- rjkennedy98 8y ago
  Depends on the use case. We use it alongside Cassandra and MySQL, but we also deal with tens of billions of records. If you just have a webblog, you could just use elastic.

by dewey 8y ago

With that little information from the OP the answer is probably: Use ES or if it's a small side project use your DB's included full text search if it's good enough.

brightball 8y ago

You can go far using purely Postgres full text search. I ported a site from Solr to PG full text because of strange syncing issues and it was just as fast. Afterwards I never really saw the point of any of the search systems other than elastic search because the streaming capabilities that it gives you.

mistrial9 8y ago
agree, and add your own caching. Lots of pop in the web world comes from layers of well-built caching.
- sethrin 8y ago
  This is probably true in many more ways than I am aware of. Do you have any other good examples or resources to suggest?

danielecook 8y ago

When is a full text search within a DB not good enough? Is ES usually used along side a typical RDS or is it a replacement?

dewey 8y ago
I don't have a lot of experience with PG full text search in production or a bigger scale. I'd just suspected that it doesn't perform that well if you need a lot of filters, range queries etc? Maybe someone with more experience can chime in. At work we just materialize the data from PG into ES and take advantage of the powerful ES queries and redundancy. Scaling up by just adding nodes is easier.
- dominotw 8y ago
  How do you verify that all the data moved into ES from pg and what got lost in transit.
  - dewey 8y ago
    For our use case we don't really need a strict verification. Everything that should go to ES is put in a queue (using DB triggers) and then sent off to ES. If something should cause errors we'd see that by observing the error rate on ES ingest I assume.
rjkennedy98 8y ago
Depends on the use case. We use it alongside Cassandra and MySQL, but we also deal with tens of billions of records. If you just have a webblog, you could just use elastic.