Scoped Search vs. Lucene
On one hand it seems strange to compere them because it’s a bit like comparing oranges to apples, they do different things. On the other hand they both seemed to be a possible solution for the search we plan to add. The reason is that they both provide the end user a rich search language with free-text and boolean expressions. The front-end might look similar but the back-end of the solutions is entirely different and so does the use cases that each solution fits best.
Unlike Elastic-Search the Scoped-Search is not an indexer nor a data store. It’s a light weight query parser, auto-completer and SQL query builder.
It enables feature rich search box in the GUI and a powerful API, on top of any RDBMS, no schema change is needed. Scoped Search on top of RDBMS can easily handle structured data, it returns updated data as soon as it’s stored in the database. No scoring, no ranking, just a simple “order by” clause in the SQL. It will scale as much as the underline database does.
Elastic-Search on the other hand will index your data, store it in a document format optimized for searching. It will scale-out well, both in terms of data set size and in terms of the number of queries.
If your data is better modeled as document (such as web pages, article in a news paper, email-messages, etc.) and you need handle a lot of search queries or you have a large number of documents to search, you probably better of with Lucene based solutions. If your application needs Partition Tolerance and Availability more then it needs Consistency choose Lucene.
If your front-end is written in ruby, your data is well structured and you care more about Consistency and Availability then Partition Tolerance, adding scoped_search on top of your relational database should probably be your choice.