From general-return-464-apmail-lucene-general-archive=lucene.apache.org@lucene.apache.org Fri May 11 19:05:00 2007 Return-Path: Delivered-To: apmail-lucene-general-archive@www.apache.org Received: (qmail 86919 invoked from network); 11 May 2007 19:05:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 May 2007 19:05:00 -0000 Received: (qmail 19968 invoked by uid 500); 11 May 2007 19:05:05 -0000 Delivered-To: apmail-lucene-general-archive@lucene.apache.org Received: (qmail 19955 invoked by uid 500); 11 May 2007 19:05:05 -0000 Mailing-List: contact general-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@lucene.apache.org Delivered-To: mailing list general@lucene.apache.org Received: (qmail 19944 invoked by uid 99); 11 May 2007 19:05:05 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2007 12:05:05 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jukka.zitting@gmail.com designates 209.85.132.243 as permitted sender) Received: from [209.85.132.243] (HELO an-out-0708.google.com) (209.85.132.243) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 May 2007 12:04:58 -0700 Received: by an-out-0708.google.com with SMTP id b8so253221ana for ; Fri, 11 May 2007 12:04:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I9F9s3SFdmV8fNIs+i1P4UwtdkzXNN+5/DZ053QBdbyRDIpQ+xx4B+bKdhP65T+1KfVHrOWl3Q/JF/kEFRRY25tCwBKm+gcnY8mMj9wnZ/E/t+UxLv7c7MPrfoinbgslRsgHBNl2PzxBGQWsuk+Sm7rnryE0Ln+V1TK0dIk7klo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uE6NGrhZsd95Y97j3oCPAhoKGLlyfHJjrZGbrvQUzuxS3vKhR5rpPESaWOJcX1Bz0UUF3Zqyg+CKaB5fOSAYih3VIQO4IKga4jUsKixm0N+dP+g8GvOfNK1biXkQNeNGxMWmv38CsJljJ8AUv5RP0W16H8HPuQy/rxuGRXXMKLU= Received: by 10.100.247.11 with SMTP id u11mr2452952anh.1178910274092; Fri, 11 May 2007 12:04:34 -0700 (PDT) Received: by 10.100.191.18 with HTTP; Fri, 11 May 2007 12:04:33 -0700 (PDT) Message-ID: <510143ac0705111204r62bda0b5v8b063033fba227b@mail.gmail.com> Date: Fri, 11 May 2007 22:04:33 +0300 From: "Jukka Zitting" To: general@lucene.apache.org Subject: Re: DB-XML/Lucene integration In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Virus-Checked: Checked by ClamAV on apache.org Hi, On 5/11/07, J. Delgado wrote: > I would like once again to open this can of worms, and perhaps think out of > the box, without classifying DB and Full-Text as simply different, as we > analyze concepts to further understand the real path for evolution of > Lucene/Sorl Another data point to consider are hierarchical content repositories like Jackrabbit and the myriad of custom "database + lucene" repositories out there. I had some interesting discussions during the last ApacheCon about the potentially converging storage and and feature requirements of various components along the DB/Full text index axis. At least from the Jackrabbit perspective it would be interesting to look at how to better integrate the Lucene search index with our native persistence model. I guess people from DB projects like Derby have similar interests. Looking further in the future it might even make sense to completely unify the storage model of these various projects. I.e. have set handling from Derby, hierarchies from Jackrabbit, and indexing from Lucene in a single extensible storage engine that could be used as a unified backend layer by various projects. I believe that many of the current storage data structures need to be redesigned in any case due to current trends in computing. The driving trends I see are increasingly cheap storage and the switch to more parallelism in computing. I believe that within the next 5-10 years we'll see many projects switching to append-only data structures that focus on massively parallel read operations with zero locking. I guess I'm sufficiently out of the box now... I'll crawl back in. :-) BR, Jukka Zitting