I have just started working on OrientDB, with OrientDB for search engine which tool we have to use Solr or ElasticSearch (driver compatibility). I also read somewhere that orientdb is giving Lucene Search itself if we define the index is different type. So if this is true then what about speed because Solr and **Elasticsearch ** serving data from primary memory.
Please suggest can OrientDB's internal functionality full fill search requirement so we use this instead of Solr or ElasticSearch.
I'm the maintainer of the full text and spatial indexes of OrientDB.
First of all, here's the link to the documentation, just to have an overview:
http://orientdb.com/docs/last/Full-Text-Index.html
What do we offer? We enable to define an index on one or more property of a Class (e.g. a Table) that uses Lucene as engine. This allow to perform queries where the full Lucene grammar could be used:
SELECT from Person WHERE Description LUCENE "progra* +senior -ruby"
You can configure analyzers and stopwords, but for sure we cannot provide the same set of features ES or SOLR are able to.
We are improving that component for the next 3.0: more like this, highlighting, query parser configuration at query time, custom analyzer configuration.
These will improve the user experience, allowing to explore the graph in a completely different way.
In my opinion, if your main target is search, ES or SOLR fit best: they are full of features about text!
On the other end, if you need a database to store data with strong relationships and would like to provide full text search done right (based on lucene) and even spatial search, OrientDB can help you.