You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mikhail Khludnev (JIRA)" <ji...@apache.org> on 2017/11/05 18:16:01 UTC
[jira] [Updated] (LUCENE-7863) Don't repeat postings (and perhaps
positions) on ReverseWF, EdgeNGram, etc
[ https://issues.apache.org/jira/browse/LUCENE-7863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Khludnev updated LUCENE-7863:
-------------------------------------
Attachment: byterefshash-bench.txt
LUCENE-7863.patch
[^LUCENE-7863.patch] with more efficient ngram mapping with BytesRefHash. [^byterefshash-bench.txt] benchmark results on i5 and ssd.
h2. Summary
{code}
------------> Report sum by Prefix (index) and Round (2 about 2 out of 18)
Operation round work dir src flush cdc runCnt recsPerRun rec/s elapsedSec avgUsedMem avgTotalMem directory size, Mb
index 0 edge EnwikiEdgeContentSource 000.00 Lucene70Codec 1 5000001 619.77 8,067.48 1,397,385,984 1,512,570,880 23,783.00
index 1 deriv EnwikiEmptyEdgeContentSource 50.00 DeriveBodyRevCodec 1 5000001 571.40 8,750.42 2,095,467,008 6,383,730,688 7,687.00
------------> Report sum by Prefix (search) and Round (2 about 2 out of 18)
Operation round work dir src flush cdc runCnt recsPerRun rec/s elapsedSec avgUsedMem avgTotalMem directory size, Mb
search_50 0 edge EnwikiEdgeContentSource 000.00 Lucene70Codec 1 50 17.63 2.84 1,291,492,352 1,510,998,016 23,783.00
search_50 1 deriv EnwikiEmptyEdgeContentSource 50.00 DeriveBodyRevCodec 1 50 5.97 8.38 2,205,875,712 6,383,730,688 7,687.00
{code}
* indexing deriving terms is 8% slower than edge-ngramms
* heap consumption for indexing is 4 times greater (1.5 G vs 6.4)
* index size more than 3 times smaller. I expect bigger gain on regular indices.
* search throughput is 3 lower with derivative terms. But it's only few cold searches. There is a reason why searching wildcards on deriving terms is slower - it's random reads; however at some point absence of repeating postings should pays back and let it search faster eg when index isn't fully mapped.
> Don't repeat postings (and perhaps positions) on ReverseWF, EdgeNGram, etc
> ----------------------------------------------------------------------------
>
> Key: LUCENE-7863
> URL: https://issues.apache.org/jira/browse/LUCENE-7863
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
> Reporter: Mikhail Khludnev
> Attachments: LUCENE-7863.hazard, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, LUCENE-7863.patch, bench-byte-array-long.out, bench-byte-array2.out, benchmark-1m.out, byterefshash-bench.txt
>
>
> h2. Context
> \*suffix and \*infix\* searches on large indexes.
> h2. Problem
> Obviously applying {{ReversedWildcardFilter}} doubles an index size, and I'm shuddering to think about EdgeNGrams...
> h2. Proposal
> _DRY_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org