jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Seidel. Robert" <Robert.Sei...@aeb.de>
Subject AW: Functionality to store indexes in database with jackrabbit 2.1.2 or upcoming releases.........
Date Mon, 29 Nov 2010 11:47:14 GMT
I think, the use-case is the same, that we have::

Multi cluster environment - only one single Lucene index within the database for all nodes
	-> takes less disk space (if you have more than one node)
	-> make backups easier (you only have to backup the database, not the db and some folders
on three nodes)
	-> makes it easier to add nodes (you don't have to wait, until the index is built up)
	-> make the index more stable (because the database is transactional)

Regards, Robert

-----Ursprüngliche Nachricht-----
Von: Alexander Klimetschek [mailto:aklimets@adobe.com] 
Gesendet: Montag, 29. November 2010 11:26
An: users@jackrabbit.apache.org
Betreff: Re: Functionality to store indexes in database with jackrabbit 2.1.2 or upcoming

But what is the use-case for this? Why store a full-text index
implementation that is totally unrelated to the DB inside a database layer
that just makes it perform worse, use more disk-space, etc.? It's like
implementing a database index by storing it in another database...


On 29.11.10 09:37, "Ard Schrijvers" <a.schrijvers@onehippo.com> wrote:

>On Mon, Nov 29, 2010 at 9:21 AM, Thomas Mueller <mueller@adobe.com> wrote:
>> Hi,
>> Jackrabbit currently uses Lucene. According to the Lucene FAQ it should
>>be possible, but I'm not sure what changes (if any) would be required in
>Most likely only a database based LuceneDirectory would have to be
>created. Although the FAQ states that it is possible, I don't think it
>can ever perform. Once again, I believe in storing segments as a whole
>in a database to have a persisted lucene index, but, you cannot
>efficiently access these segments in a database. You then need to keep
>the index in memory.
>> I'm not aware of plans to support this feature. Patches are welcome of
>>course :-)
>First of all, we would have to do some housekeeping in the existing
>implementation. The entire 'multi-index' setup, meant for 'near real
>time searches' is unneeded anymore against newer lucene versions. Also
>the way properties are indexed should be replaced. Note that these
>changes will most likely already affect about 100 of the 200 query
>classes (where quite a lot can be removed as well). So, this is lots
>of work. After this, preferably, we can move to the 4.x Lucene
>versions. So, a patch is welcome, but don't think to light about it :)
>Regards Ard
>> Regards,
>> Thomas
>> From: Atul Kumar Tripathi
>> Reply-To: 
>> Date: Mon, 29 Nov 2010 05:06:31 +0000
>> To: "users@jackrabbit.apache.org<mailto:users@jackrabbit.apache.org>"
>> Subject: Functionality to store indexes in database with jackrabbit
>>2.1.2 or upcoming releases.........
>> Hi Guys,
>> Is this possible to store indexes in database using jackrabbit 2.1.2?
>> Are there any plans to provide functionality to store indexes in
>>database with upcoming Jackrabbit Releases?
>> Thanks in advance.
>> Thanks & Regards.
>> Atul Tripathi
>> Senior Engineer  |  Datacert/Technology.
>> Virtusa India Pvt. Ltd.
>> Chennai ATC
>> Phone:  +91 44 66127000 Ext:  3742 | Mobile:  +91 9940483180
>> [cid:image001.jpg@01CB8FB1.496525A0]<http://www.virtusa.com/>
>>[cid:image002.gif@01CB8FB1.496525A0] <http://www.virtusa.com/blog/>
>>[cid:image003.gif@01CB8FB1.496525A0] <https://twitter.com/VirtusaCorp>
>> Virtusa was recently ranked and featured in 2010 Deloitte Technology
>>Fast 500, 2010 Global Services 100, IAOP's 2010 Global Outsourcing 100
>>sub-list and 2010 FinTech 100 among others.
>> This message, including any attachments, contains confidential
>>information intended for a specific individual and purpose, and is
>>intended for the addressee only. Any unauthorized disclosure, use,
>>dissemination, copying, or distribution of this message or any of its
>>attachments or the information contained in this e-mail, or the taking
>>of any action based on it, is strictly prohibited. If you are not the
>>intended recipient, please notify the sender immediately by return
>>e-mail and delete this message.
>Europe  €  Amsterdam  Oosteinde 11  €  1017 WT Amsterdam  €  +31 (0)20
>522 4466
>USA  € San Francisco  185 H Street Suite B  €  Petaluma CA 94952-5100
>€  +1 (707) 773 4646
>Canada    €   Montréal  5369 Boulevard St-Laurent  €  Montréal QC H2T
>1S5  €  +1 (514) 316 8966
>www.onehippo.com  €  www.onehippo.org  €  info@onehippo.com


Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel

View raw message