
Thoughts on Algolia vs. Solr and Elasticsearch - softwaredoug
http://opensourceconnections.com/blog/2016/06/01/thoughts-on-algolia/
======
latenightcoding
I remember a previous employer asked me to talk to one of the authors because
I have NLP and search engine design experience (I forgot which author). I
remember he kept saying they don't do big data and that most NLP stuff other
search engines use are irrelevant because their product works with the type of
search they do. I asked a couple of complex questions which they disregarded
as not important for their product.

This was probably 3 years ago or less so the product might have changed, but
what I got out of that chat was that Algolia is for websites that want to add
a search functionality with a nice UI without much hassle.

But if you are doing something complex it's does not compare to Solr or
Elasticsearch

Again this was a while ago.

~~~
ch4s3
My experience has been that if search isn't critical to the core of your
business, you should use Algolia. What I mean is that good search is hard and
expensive to build, and if your product will not suffer from good enough
search then it will be an order of magnitude cheaper. I use it to search over
a list of 25k ish items that can be ordered broken into 4 categories. The
users are domain experts and know what they're searching for. Algolia took me
45 minutes to set up and it returns results almost as fast as I can type, it
was a no brainer.

However, if I had users that needed to lean on search to find things they
didn't know about I would want to look into something that could infer meaning
from the text input.

------
softwaredoug
(Author here) Case in point where Elasticsearch shines is one of yesterday's
hacker news articles

[http://sujitpal.blogspot.com/2016/05/elasticsearch-based-
ima...](http://sujitpal.blogspot.com/2016/05/elasticsearch-based-image-search-
using.html?m=1)

Here Elasticsearch is used as a framework where "search" really means some
kind of distributed feature similarity. But even text search where your
incorporating a lot of data science, external signals, or semantic awareness
can fall more into the category of distributed feature similarity.

Algolias strength is in a simpler path to straightforward and easily
understood search. I'm not sure it's the path to amazing and deeply customized
search (or search-driven features). Algolia gets far more right out of the box
at a configuration level many need when they can't put a team around building
an amazing Solr/ES experience.

My hope is Solr/ES can learn a thing or two in the ease of use dept with
relevance!

~~~
softwaredoug
If you like this article don't forget to listen to us chat with Algolia CTO on
our podcast Search Disco

[http://opensourceconnections.com/blog/2016/05/31/algolia-
sea...](http://opensourceconnections.com/blog/2016/05/31/algolia-search/)

It's like the liner notes for the blog article...

------
dansingerman
I've had great experiences with algolia. I've used it on numerous client
projects, and my own product [https://appapp.io](https://appapp.io) .

It is great as an out of the box search solution that will probably fit 90% of
cases. It is blindingly fast and my clients love it.

I expect there are some cases where elastic or solr will be a better fit; but
these are most definitely edge cases for very specific search requirements.
Algolia is a killer app for generic 'good' search.

------
ronack
In my experience, Algolia is OK for toy sites but not for anything even
moderately complex. Even on HN it's often a challenge to find the right
results. They seem to have gone with the philosophy that speed is more
important than relevance. Keyword matching is only one small aspect of a good
search experience.

~~~
dethi
For me Medium, Product Hunt, Digital Ocean or even Twitch are not "toy sites".

~~~
ronack
Haven't tried the others, but Product Hunt's search is also extremely poor.
Just today I searched for "mac voice control" (unquoted) and besides being
very sluggish because of all the refreshing it does while I type, it returned
_0 results_. What I was looking for was Lacona [1] which was just featured a
couple days ago and has a description containing two of the words from my
query (1/3 of the description!).

[1]
[https://www.producthunt.com/tech/lacona](https://www.producthunt.com/tech/lacona)

~~~
softwaredoug
This is actually a great example that shows where Algolia doesn't shine.

Algolia is great a known-item searches. Searches that are like looking up a
contact in your phone list. This is a common use case with search, but one of
only many.

Your use case is closer to grasping at straws because you don't know the
language to use. You can't quite remember the name for something. This is also
very common, and not handled well with purely string matching. Another example
is in this blog article[1] where I talk about searching for "manual lawn
mower" not realizing the right terminology is a "reel mower." Mapping
vernacular is a hard problem, and I feel like Solr/ES while harder are better
equipped for the problem.

(I also often find instant search distracting)

[1][http://opensourceconnections.com/blog/2014/06/10/what-is-
sea...](http://opensourceconnections.com/blog/2014/06/10/what-is-search-
relevancy/)

~~~
Lxr
> Algolia is great at known-item searches

I have not used Algolia much but that's not a particularly compelling selling
point, most search engines tend to get it right if you know exactly what to
query. The problem is this is, like, 1% of the difficulty of making a good
search engine.

------
bladecatcher
I recently had to build a product search functionality. I was able to pick up
nearly all important features of Elasticsearch in about 2 days and had live-
indexing and search up and running within 2 more days. Of course, this wasn't
production level scalable code. But it was fairly easy to hook a Logical
Decoding Output Plugin on Postgres, which would stream database mutations (in
form of JSON) to a Kafka cluster, from where the Elasticsearch layer will
ingest the data and index/update it appropriately.

~~~
alexnewman
what logical decoder?

~~~
bladecatcher
Postgres 9.4+ lets you use the write-ahead log and "replication slots" using
which you can create streams of database changes that can be replayed to a
client in the order they were made on the origin server [1]

EDIT: In case the question was which library did I use, I used BottledWater
and it's worked great for me so far [2]

[1]
[https://www.postgresql.org/docs/9.4/static/logicaldecoding-e...](https://www.postgresql.org/docs/9.4/static/logicaldecoding-
explanation.html)

[2] [https://github.com/confluentinc/bottledwater-
pg](https://github.com/confluentinc/bottledwater-pg)

------
krokoo
One of the least talked about search engines is NodeChef Cloud Search. Anybody
using any language could use it insofar as they have a mongodb driver. Anyone
who used it could comment on it? [https://nodechef.com/nodechef-search-and-
sql-analytics](https://nodechef.com/nodechef-search-and-sql-analytics)

~~~
daphinz
Whats your referral code?

------
sciurus
Of course, if you like what Doug has to say and are building your own search
functionality on top of Solr or Elasticsearch, you'll want to buy his book:

[https://www.manning.com/books/relevant-
search](https://www.manning.com/books/relevant-search)

------
mozumder
Why would one use Algolia over Postgres's built in text search features? Ex:
[http://rachbelaid.com/postgres-full-text-search-is-good-
enou...](http://rachbelaid.com/postgres-full-text-search-is-good-enough/)

I already have Postgres search queries running on the order of 1-3ms for large
queries, basically faster than Algolia, with seemingly the same feature sets.

I don't understand the value proposition over something like Postgres, for
sites that already have Postgres databases. (And I'm sure other databases
might offer similar built-in search capabilities, I just don't know those
other RDBMSs)

~~~
forgotpwtomain
> Why would one use Algolia over Postgres's built in text search features? Ex:
> [http://rachbelaid.com/postgres-full-text-search-is-good-
> enou...](http://rachbelaid.com/postgres-full-text-search-is-good-enou..).

Postgres built-in search features are really for large document searching --
we've tried using it for indexing e.g. an array of tags for auto-complete and
the search times were in the ~500ms+ range, as a matter of fact the non-
indexed regex search was only slightly slower. I thought the later was rather
surprising - but asking on the mailing-lists, I was told that this was
basically working as intended.

edit: I don't fully understand the value-proposition of Algolia either, most
of the trouble with going outside of your production database for search - is
the problem of keeping your data in sync and current with the production
database; compared to that setting up an Elasticsearch cluster really isn't
such a big deal, there are also half-way solutions, for example Amazon has an
Elasticsearch-service.

~~~
jlemoine
I would recommend to read this post to have an idea:
[https://blog.algolia.com/inside-the-algolia-engine-
part-3-qu...](https://blog.algolia.com/inside-the-algolia-engine-part-3-query-
processing/)

Textual relevance is a very complex domain and the Postgres's built in text
search features is a simple keyword matching engine compared to Algolia engine
that contains a lot of alternative matching. The mesure of textual relevance
is also very different of what you have in the Postgres text search.

At the end, this is not only about speed but mainly about relevance

