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 would
-> 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:[email protected]]
Gesendet: Montag, 29. November 2010 11:26
An: [email protected]
Betreff: Re: Functionality to store indexes in database with jackrabbit 2.1.2
or upcoming releases.........
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...
Regards,
Alex
On 29.11.10 09:37, "Ard Schrijvers" <[email protected]> wrote:
>On Mon, Nov 29, 2010 at 9:21 AM, Thomas Mueller <[email protected]> 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
>>Jackrabbit:
>
>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.
>
>>
>>
>>http://wiki.apache.org/lucene-java/LuceneFAQ#Can_I_store_the_Lucene_index
>>_in_a_relational_database.3F
>>
>> 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
>><[email protected]<mailto:[email protected]>>
>> Reply-To:
>>"[email protected]<mailto:[email protected]>"
>><[email protected]<mailto:[email protected]>>
>> Date: Mon, 29 Nov 2010 05:06:31 +0000
>> To: "[email protected]<mailto:[email protected]>"
>><[email protected]<mailto:[email protected]>>
>> 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:[email protected]]<http://www.virtusa.com/>
>>[cid:[email protected]] <http://www.virtusa.com/blog/>
>>[cid:[email protected]] <https://twitter.com/VirtusaCorp>
>>[cid:[email protected]]
>><http://www.linkedin.com/companies/virtusa>
>>[cid:[email protected]]
>><http://www.facebook.com/VirtusaCorp>
>>[cid:[email protected]]
>><http://www.youtube.com/virtusacorporation>
>>[cid:[email protected]]
>><http://www.flickr.com/photos/virtusa>
>>
>>
>> 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.
>>
>>
>>-------------------------------------------------------------------------
>>--------------------
>>
>>
>
>
>
>--
>Hippo
>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 € [email protected]
>
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
