Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of a.schrijvers@1hippo.com
 designates 64.18.2.8 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOAO1Sh1qmKykB6UwmkKOsaHNOxEQqu3yXT34-sAOhhaHdFjeQ@mail.gmail.com>
References: 
 <CAB-0WTB6RybsbWNE+066ZREmQodtNgAAYu8MaVRwk1LS6xkrhw@mail.gmail.com>
	<CB9097E3.28380%mueller@adobe.com>
	<CABXgNGkLtqd6tsUbZn3dLnj7urMttP3VN1ftEkVPL6-BFV1LrQ@mail.gmail.com>
	<CAOAO1Sh1qmKykB6UwmkKOsaHNOxEQqu3yXT34-sAOhhaHdFjeQ@mail.gmail.com>
Date: Mon, 26 Mar 2012 09:20:12 +0200
Message-ID: 
 <CABXgNGkYBQwR00hXExdxjkSywH3qQT=XRgBiJu4+T3dWibWPiQ@mail.gmail.com>
Subject: Re: Re (OAK-36) Implement a query parser - what about indexing?
From: Ard Schrijvers <a.schrijvers@onehippo.com>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2012 at 6:57 PM, Justin Edelson
<justin@justinedelson.com> wrote:
> On Fri, Mar 23, 2012 at 5:40 AM, Ard Schrijvers
> <a.schrijvers@onehippo.com>wrote:
>
>>
>> Although I am on thin ice here, I think there are hardly any noSQL
>> stores out there that actually include full text indexes.
>
> Yes, but the goal of Oak explicitly says "The implementation should provi=
de
> more out-of-the-box functionality than typical NoSQL databases while
> achieving comparable levels of scalability and performance."

the 'more out-of-the-box functionality' does not imply a full-text
index is needed per se. For example hierarchy isn't part of most NoSQL
databases, that is already more functionality

I am just a bit skeptical about 'more x but the same y'. It seems to
me to be impossible to have a full text index and comparable levels of
scalability with NoSQL databases that do not concern about hierarchy
or full text indexes. Giving up some performance for a hierarchy makes
much sense, because it is true added value.

>
>
>> I think we
>> shouldn't try to address it in the repository, but rather provide some
>> tooling to easily setup a (external) full text index (like plain
>> Lucene, or use Solr/Elastic search) according someones exact needs
>> (like, which analyzer to use for which part of the content, which
>> properties should be stored, which properties should be analyzed in
>> which ways, which properties are meant for TrieRanges, =A0etc etc)
>>
> I agree that for many use cases a separate index is appropriate. That
> doesn't obviate the need/appropriateness for an internal full-text search
> index.

I would/do agree only if the full-text search index doesn't imply much
performance constraints, higher memory consumption, and scalability
issues. Imho, the price for full text indexes is way too high, while I
still doubt usability in the end.

Regards Ard

>
> Justin
>
>
>>
>> Regards Ard
>>
>> >
>> > [1]:
>> >
>> http://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jack=
rab
>> > bit%203
>> >
>> > Regards,
>> > Thomas
>> >
>>


--=20
Amsterdam - Oosteinde 11, 1017 WT Amsterdam
Boston - 1 Broadway, Cambridge, MA 02142

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com