Yes this would be a great feature. I've made some modest progress[1], based on the examples in the erlang book, on native FTI. I'm very keen on it as my use case isn't handled by Lucene. I've used both bitcask[2] and couchdb for storage of the inverted indices but neither seem well suited for something this write heavy without lots of compaction.
With all due respect to Lucene, I'm not at all interested in a port of it. I think a native solution ought to try and move forward and leverage the features of couchdb. I also don't think there is any "official" position and/or roadmap, other than what's in JIRA. YMMV, Bob [1] http://dionne.posterous.com/relaxed-searching-in-couchdb [2] https://github.com/basho/bitcask On Mar 28, 2011, at 5:51 AM, Andrew Stuart (SuperCoders) wrote: > Although it may be a huge amount of work, it would still seem to be a > necessary feature for the core developers to build? > > It seems a fairly reasonable thing to expect a database could return records > that contain "java OR C#" in a "subject line" field, without resorting to > external software. It's not ideal to require installation additional > software to get basic functionality going. > > My primary question is - what is the "official" position on full text search > in CouchDB - is it coming, sooner, later or never? Is there an up to date > development roadmap for couchdb? Maybe its on there. > > as > > On 28/03/2011, at 8:24 PM, Robert Newson wrote: > > I have to dispute "There does not seem to be much understanding that > this could be a killer feature." > > Obviously full-text search is a killer feature, but it's trivially > available now via couchdb-lucene or elasticsearch. > > What people are asking for is native full-text search which, to me, is > essentially asking for an Erlang port of Lucene. We'd love this, but > it's a huge amount of work. Continually asking others to do > significant amounts of work is also wearying. > > To replace a Lucene-based solution and match its quality and breadth > is a huge chunk of work and is only necessary to satisfy people who, > for various reasons, don't want to use Java. > > To answer the original post, there are no publicly known plans to > build a native full-text indexing feature for CouchDB. > > B. > > On 28 March 2011 10:15, Olafur Arason <olaf...@olafura.com> wrote: >> There does not seem to be much understanding that this could be a killer >> feature. People are now relying on Lucene which monitors the _changes >> feed. >> >> Cloudant has done it's own implementation which I gather through the >> information they have published makes a view out of all your word, >> they recommend java view because you can then reuse the lexer from >> Lucene. Then I think they are reusing the reader of the view to make >> their query. They have a similar syntax as Lucene for the query interface. >> They are still working on this and I think they don't have that much >> incentive to opensource it right away. But they have in past both >> opensourced there technology like BigCouch so I think it's more a >> matter of when rather then if. >> >> I think this is a good solution for a fulltext search. But I don't think that >> the java view does not have direct access to the data so it could be >> slow. But cloudant does clustering on view generation so that helps. >> >> But there is also general problem with the current view system where >> search technology could be used. >> >> The view are really good at sorting but people are using them to >> do key matches which they are not designed for. They beginkey and >> endkey are for sorting ranges and are not good for matching which >> most resources online are pointing to. >> >> For example when you do: >> beginkey = ["key11", "key21"] >> endkey = ["key19", "key21"] >> >> You get ["key11","key22"], ["key11", "key23"] ... ["key12","key21"], >> ["key12","key22"]... >> which makes sense when looking up sorting ranges but not using it to >> match keys. But you can have a range match lookup but only on the >> last key and never on two keys. So this would work: >> >> beginkey = ["key21", "key11"] >> endkey = ["key21", "key19"] >> >> The current view interface could be augmented to accept queries >> and could make them much more powerful then they currently are >> and just using the keys for sorting and selecting which values you >> want shown which they are designed to do and do really well. >> >> This would be a killer feature and could use the new infrastructure >> from Cloudant search. >> >> And don't tell me the Elastic or Lucene interface could do anything >> close to this :) >> >> Regards, >> Olafur Arason >> >> On Mon, Mar 28, 2011 at 04:31, Andrew Stuart (SuperCoders) >> <andrew.stu...@supercoders.com.au> wrote: >>> It would be good to know if full text search is coming as a core feature and >>> if yes, approximately when - does anyone know? >>> >>> Even an approximate timeframe would be good. >>> >>> thanks >>> >> > -- > Message protected by MailGuard: e-mail anti-virus, anti-spam and content > filtering.http://www.mailguard.com.au/mg > Click here to report this message as spam: > https://login.mailguard.com.au/report/1BZveI1wri/4izG2DWUCf9OUvbAh9DkfT/0
