cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-2915) Lucene based Secondary Indexes
Date Mon, 18 Jul 2011 19:23:57 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-2915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067228#comment-13067228
] 

T Jake Luciani commented on CASSANDRA-2915:
-------------------------------------------

bq. We need to specify how configuration parameters are passed into the Lucene secondary index.
This needs to include things like the local Lucene file path, a class to transform Cassandra
CF rows into Lucene documents, etc.

The secondary indexes would go into the data directory defined in cassandra.yaml, currently
there is a dir per KeySpace, we can create a subdir like "indexes" were the lucene indexes
are stored.

As for transforms, I mentioned column validators. This is meta information about the contents
of columns, see http://www.datastax.com/dev/blog/whats-new-cassandra-07-secondary-indexes

This validation_class can be extended to let users map columns to lucene analyzer.

The document would be a row: fields would be columns (with analyzers specified in the column
meta-data validation_class) 



> Lucene based Secondary Indexes
> ------------------------------
>
>                 Key: CASSANDRA-2915
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2915
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: T Jake Luciani
>              Labels: secondary_index
>             Fix For: 1.0
>
>
> Secondary indexes (of type KEYS) suffer from a number of limitations in their current
form:
>    - Multiple IndexClauses only work when there is a subset of rows under the highest
clause
>    - One new column family is created per index this means 10 new CFs for 10 secondary
indexes
> This ticket will use the Lucene library to implement secondary indexes as one index per
CF, and utilize the Lucene query engine to handle multiple index clauses. Also, by using the
Lucene we get a highly optimized file format.
> There are a few parallels we can draw between Cassandra and Lucene.
> Lucene indexes segments in memory then flushes them to disk so we can sync our memtable
flushes to lucene flushes. Lucene also has optimize() which correlates to our compaction process,
so these can be sync'd as well.
> We will also need to correlate column validators to Lucene tokenizers, so the data can
be stored properly, the big win in once this is done we can perform complex queries within
a column like wildcard searches.
> The downside of this approach is we will need to read before write since documents in
Lucene are written as complete documents. For random workloads with lot's of indexed columns
this means we need to read the document from the index, update it and write it back.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message