2010/4/15 Shai Erera <ser...@gmail.com>: > The reason Earwin why online migration is faster is because when u > finally need to *fully* migrate your index, most chances are that most > of the segments are already on the newer format. Offline migration > will just keep the application idle for some amount of time until ALL > segments are migrated. > > During the lifecycle of the index, segments are merged anyway, so > migrating them on the fly virtually costs nothing. At the end, when u > upgrade to a Lucene version which doesn't support the previous index > format, you'll on the worse case need to migrate few large segments > which were never merged. I don't know how many of those there will be > as it really depends on the application, but I'd bet this process will > touch just a few segments. And hence, throughput wise it will be a lot > faster. > > We should create a migrate() API on IW which will touch just those > segments and not incur a full optimize. That API can also be used for > an offline migration tool, if we decide that's what we want.
We should not create such an API on IW, and we should build offline migration tool as a separate thing :) Because otherwise we have to keep all back-compat stuff within IW, SR and friends as it is. Look at current SegmentReader.Norm code - there's three freaking places they can be loaded from. I will also reiterate the issue of the API. Fat index changes are almost certainly accompanied by API changes. With online migration we have to emulate new APIs over old segments, which is really cumbersome. With offline migration we only need to be able to read said segments in one or another manner. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
