Yes. This is the direction I would prefer in my original post. The sample in my original post might be covered by SOLR and Lucene, but those won't be sufficient in general, plus the potential data replication and synchronization challenge.
The index can be maintained externally, or even a gateway to other searching services in run time. For Phoenix, an indexing implementation is a plug-in that returns row keys based on filtering criteria in SELECT. Here is one wild scenario: Assuming there is HBase table "PAGES" stores additional information (URL as primary key, last visit, comments, rating, etc.) on all possible pages on web. Instead of storing the page snapshot and developing an in-house full text search solution, we can develop a custom indexing that connecting to Google in realtime. So SQL in Phoenix like this "SELECT * FROM PAGES WHERE TEXT='blah blah key word' AND RATING > 5" would return pages with the key word and has a rating over 5. This is quite extreme case. More common case would be some kind of integration to other searching capabilities if Phoenix could allow custom indexing. -- View this message in context: http://apache-phoenix-user-list.1124778.n5.nabble.com/Custom-Indexing-Plug-in-for-Phoenix-tp3354p3360.html Sent from the Apache Phoenix User List mailing list archive at Nabble.com.
