[
https://issues.apache.org/jira/browse/CASSANDRA-11383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15216337#comment-15216337
]
Jordan West commented on CASSANDRA-11383:
-----------------------------------------
bq. Maybe that leaves one last question as to whether non-SPARSE (PREFIX) mode
is considered advisable/recommended for high cardinality column data, where
SPARSE mode is nominally a better choice. Maybe that is strictly a matter of
whether the prefix/LIKE feature is to be utilized - if so, than PREFIX mode is
required, but if not, SPARSE mode sounds like the better choice. But I don't
have a handle on the internal index structures to know if that's absolutely the
case - that a PREFIX index for SPARSE data would necessarily be larger and/or
slower than a SPARSE index for high cardinality data. I would hope so, but it
would be good to have that confirmed.
{{SPARSE}} is only for numeric data so LIKE queries do not apply. For data that
is sparse (every term/column value has less than 5 matching keys), such as
indexing the {{created_at}} field in time series data (where there is typically
few matching rows/events per {{created_at}} timestamp), it is best to use
{{SPARSE}}, always, and especially in cases where range queries are used.
{{SPARSE}} is primarily an optimization for range queries on this sort of data.
Its biggest effect is visible on large ranges (e.g. spanning multiple days of
time series data).
The decision process for whether or not to use {{SPARSE}} should be:
1. is the data a numeric type?
2. is it expected that there will be a large (millions or more) number of terms
(column values) in the index with each term having a small (5 or less) set of
matching tokens (partition keys)?
If the answer to both is Yes then use {{SPARSE}}.
>From the docs
>(https://github.com/xedin/cassandra/blob/trunk/doc/SASI.md#ondiskindexbuilder):
bq. The SPARSE mode differs from PREFIX in that for every 64 blocks of terms a
TokenTree is built merging all the TokenTrees for each term into a single one.
This copy of the data is used for efficient iteration of large ranges of e.g.
timestamps. The index "mode" is configurable per column at index creation time.
> Avoid index segment stitching in RAM which lead to OOM on big SSTable files
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-11383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11383
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: C* 3.4
> Reporter: DOAN DuyHai
> Assignee: Jordan West
> Labels: sasi
> Fix For: 3.5
>
> Attachments: CASSANDRA-11383.patch,
> SASI_Index_build_LCS_1G_Max_SSTable_Size_logs.tar.gz,
> new_system_log_CMS_8GB_OOM.log, system.log_sasi_build_oom
>
>
> 13 bare metal machines
> - 6 cores CPU (12 HT)
> - 64Gb RAM
> - 4 SSD in RAID0
> JVM settings:
> - G1 GC
> - Xms32G, Xmx32G
> Data set:
> - ≈ 100Gb/per node
> - 1.3 Tb cluster-wide
> - ≈ 20Gb for all SASI indices
> C* settings:
> - concurrent_compactors: 1
> - compaction_throughput_mb_per_sec: 256
> - memtable_heap_space_in_mb: 2048
> - memtable_offheap_space_in_mb: 2048
> I created 9 SASI indices
> - 8 indices with text field, NonTokenizingAnalyser, PREFIX mode,
> case-insensitive
> - 1 index with numeric field, SPARSE mode
> After a while, the nodes just gone OOM.
> I attach log files. You can see a lot of GC happening while index segments
> are flush to disk. At some point the node OOM ...
> /cc [~xedin]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
