Should I use Elastic Search as my datastore instead of MySQL?
I'm about to rebuild my web application to use search in search instead of mysql for search, but I don't know exactly how to do this.
I watched a Laracon video on it since my app is built on Laravel 4.2 and I will use this wrapper for the request: https://github.com/elasticsearch/elasticsearch
However, am I still going to use a MySQL database to host the data and look for ES? Or is it better to have an ES home and query for data.
If I go the first route do I need to do CRUD operations on both sides to keep them updated?
Can ES handle the data load that MySQL can use? So hundreds of millions of lines?
I'm just really embarrassed to start this whole thing. I could use a little direction, it would be highly appreciated. I've never worked with search except MySQL.
source to share
I would recommend keeping MySQL as a recording system and doing all CRUD operations from your application against MySQL. Then start the ElasticSearch machine and periodically move data from MySQL to ElasticSearch (only the data that needs to be searched for).
Then if ElasticSearch goes down, you only lose the search functionality - your main datastore is still fine.
ElasticSearch can be configured as a cluster and can scale very large so it will handle row counts.
There are several things you can do to get data into Elastic:
-
Do an initial import (very slow, very large) and then just copy the diff with the process. You might consider something like Mule ESB for Data Movement ( http://www.mulesoft.org/ ).
-
When you write data from your application, you can write once in MySQL and also write the same data in Elastic. This provides real-time data in Elastic, but of course, if the second write in Elastic fails, then you won't be able to get the data.
source to share