cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rutherglen (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2982) Refactor secondary index api
Date Thu, 11 Aug 2011 03:15:35 GMT


Jason Rutherglen commented on CASSANDRA-2982:

For the Lucene secondary index, we need to report back the RAM consumed.  Then Cassandra can,
then when Memtable + Lucene RAM buffer exceeds the threshold we can and will flush both. 

Perhaps we can add an additional ram size method?

This brings up another probable issue, if Memtable flushes successfully and then Lucene is
not able to commit.

> Refactor secondary index api
> ----------------------------
>                 Key: CASSANDRA-2982
>                 URL:
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: T Jake Luciani
>            Assignee: T Jake Luciani
>             Fix For: 1.0
>         Attachments: 2982-v1.txt, 2982-v2.txt, CASSANDRA-2982-v3.patch
> Secondary indexes currently make some bad assumptions about the underlying indexes.
> 1. That they are always stored in other column families.
> 2. That there is a unique index per column
> In the case of CASSANDRA-2915 neither of these are true.  The new api should abstract
the search concepts and allow any search api to plug in.
> Once the code is refactored and basically pluggable we can remove the IndexType enum
and use class names similar to how we handle partitioners and comparators.
> Basic api is to add a SecondaryIndexManager that handles different index types per CF
and a SecondaryIndex base class that handles a particular type implementation.
> This requires major changes to ColumnFamilyStore and Table.IndexBuilder

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message