Return-Path: X-Original-To: apmail-lucene-java-user-archive@www.apache.org Delivered-To: apmail-lucene-java-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5260110EEB for ; Fri, 2 Aug 2013 12:27:15 +0000 (UTC) Received: (qmail 68664 invoked by uid 500); 2 Aug 2013 12:27:12 -0000 Delivered-To: apmail-lucene-java-user-archive@lucene.apache.org Received: (qmail 68611 invoked by uid 500); 2 Aug 2013 12:27:12 -0000 Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: java-user@lucene.apache.org Delivered-To: mailing list java-user@lucene.apache.org Received: (qmail 68601 invoked by uid 99); 2 Aug 2013 12:27:11 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 12:27:11 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of serera@gmail.com designates 209.85.212.178 as permitted sender) Received: from [209.85.212.178] (HELO mail-wi0-f178.google.com) (209.85.212.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Aug 2013 12:27:04 +0000 Received: by mail-wi0-f178.google.com with SMTP id j17so488022wiw.5 for ; Fri, 02 Aug 2013 05:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=15m5P0K2P22fe++RNOgtgMDE89AIQS4G8dw60QHVnDE=; b=Qia1mN2Rkj+xEP0foEvper8/RRelbPjACTFMVo89FHBFYHuI1ZJahj7E3CMeVEpiqe n4axyrCZVJoUB42AI0+Il5xdgFRwpIgI554XiBR+BEfDjZYE/JLkAyeBZKOvPOErstCd 0er8k275euk29QvWPMELl+DHpU12mQr6ZWO7I3JDEe4XQd/mNjnb8aadFiJ4e71kMNeh eQ8NPi8So4mxEEcI/PsBp4Za0u8mWaDVOp9MGiLEOlsMNkjuHoNbby6BH80g642jcPsm ZhiKako1p43eUSLeTvj4KnMFoH4dD3WextGxK0liERRjzDGqfDn5dtCmCx/ic1aDloXq 8YbQ== X-Received: by 10.194.203.73 with SMTP id ko9mr4596717wjc.79.1375446404239; Fri, 02 Aug 2013 05:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.169.161 with HTTP; Fri, 2 Aug 2013 05:26:24 -0700 (PDT) In-Reply-To: References: From: Shai Erera Date: Fri, 2 Aug 2013 15:26:24 +0300 Message-ID: Subject: Re: IndexUpgrade - Any ways to speed up? To: "java-user@lucene.apache.org" Content-Type: multipart/alternative; boundary=047d7b5dbafc551bcf04e2f612a8 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b5dbafc551bcf04e2f612a8 Content-Type: text/plain; charset=ISO-8859-1 Unfortunately you cannot upgrade directly from 2.3.1 to 4.1. You can consider upgrading to 3.6.2 and stop there. Lucene 4.1 can read 3.x indexes, and when segments will are merged, they are upgraded automatically to the newest file format. However, if this single segment is too big, such that it won't be picked for merges, you will need to upgrade it anyway when one day you will upgrade to Lucene 5.0. So I'd say, if you're not stressed with time, upgrade to 4.1 now ... it's a one time process. Shai On Fri, Aug 2, 2013 at 3:22 PM, Ramprakash Ramamoorthy < youngestachiever@gmail.com> wrote: > Thank you Shai for the quick response. Have responded inline. > > > On Fri, Aug 2, 2013 at 5:37 PM, Shai Erera wrote: > > > Hi > > > > You cannot just update headers -- the file formats have changed. > Therefore > > you need to rewrite the index entirely, at least from 2.3.1 to 3.6.2 (for > > 4.1 to be able to read it). > > > Yeah, as of now, we call IndexUpgrader of 3.6.2 and then IndexUpgrader of > 4.0, and then the indices become readable by 4.1 > > > If your index is already optimized, then IndexUpgrader is your best > option. > > The reason it calls forceMerge(1) is that it needs to guarantee *every* > > segment in your index gets rewritten. > > > Understood. Looks like we will have to stick to what we have written as on > date. > > > > > BTW, you might want to upgrade to 4.4 already. > > > Yeah, we upgraded the code base when 4.1 was the most recent version, now > that we are looking forward to migrate the older indices to be compatible. > Thanks again. > > > > > Shai > > > > > > On Fri, Aug 2, 2013 at 2:49 PM, Ramprakash Ramamoorthy < > > youngestachiever@gmail.com> wrote: > > > > > Team, > > > > > > We are migrating from lucene version 2.3.1 to 4.1. We are > > migrating > > > the indices as well, and we do this in two steps 2.3.1 to 3.6.2 and > 3.6.2 > > > to 4. We just call IndexUpgrader.upgrade(), using the > > > IndexUpgraderMergePolicy. I see that, the upgrade() method actually > > calls a > > > forcemerge(1) over the indices. > > > > > > However, we have all our indices optimized and there are no > > deletes > > > as well. This forcemerge(1) seems a very costly operation and since our > > > index is already optimized, there is no space benefit as well. Is > there a > > > faster way to upgrade our indices (like reading the indices and > modifying > > > the headers, something of that sort)? We are not expecting any > compaction > > > during the process. > > > > > > Currently it takes 4 minutes for a GB of index to get migrated > > to > > > 4.1 from 2.3.1. Any pointers would be appreciated. Thanks in advance. > > > > > > > > > -- > > > With Thanks and Regards, > > > Ramprakash Ramamoorthy, > > > Chennai, India. > > > > > > > > > -- > With Thanks and Regards, > Ramprakash Ramamoorthy, > Chennai, India. > --047d7b5dbafc551bcf04e2f612a8--