cassandra/interface
Jonathan Ellis 9db8da81b7 Add range query support, which requires using an OrderPreservingPartitioner. (Keys are returned in the order defined by the partitioner collation.) The fundamental approach (in table.getKeyRange) is simple: create a CollatedIterator that will return unique keys from different sources, each of which is already sorted. Then we just need Iterators for different key sources. For SSTables, this means adding seekTo and an Iterator interface to FileStruct. For Memtable, this means adding a DestructivePQIterator since unlike SSTable keys those are not inherently ordered already. This means that we only do M log N work sorting the memtable keys where M is the number of keys we actually read, and N is the total number of keys, where a naive sort-everything-first iterator would be N log N.
This does not yet implement range queries spanning multiple nodes.

patch by jbellis; reviewed by Jun Rao for CASSANDRA-71

git-svn-id: https://svn.apache.org/repos/asf/incubator/cassandra/trunk@769874 13f79535-47bb-0310-9956-ffa450edef68
2009-04-29 18:57:35 +00:00
..
gen-java/org/apache/cassandra/service Add range query support, which requires using an OrderPreservingPartitioner. (Keys are returned in the order defined by the partitioner collation.) The fundamental approach (in table.getKeyRange) is simple: create a CollatedIterator that will return unique keys from different sources, each of which is already sorted. Then we just need Iterators for different key sources. For SSTables, this means adding seekTo and an Iterator interface to FileStruct. For Memtable, this means adding a DestructivePQIterator since unlike SSTable keys those are not inherently ordered already. This means that we only do M log N work sorting the memtable keys where M is the number of keys we actually read, and N is the total number of keys, where a naive sort-everything-first iterator would be N log N. 2009-04-29 18:57:35 +00:00
cassandra.thrift Add range query support, which requires using an OrderPreservingPartitioner. (Keys are returned in the order defined by the partitioner collation.) The fundamental approach (in table.getKeyRange) is simple: create a CollatedIterator that will return unique keys from different sources, each of which is already sorted. Then we just need Iterators for different key sources. For SSTables, this means adding seekTo and an Iterator interface to FileStruct. For Memtable, this means adding a DestructivePQIterator since unlike SSTable keys those are not inherently ordered already. This means that we only do M log N work sorting the memtable keys where M is the number of keys we actually read, and N is the total number of keys, where a naive sort-everything-first iterator would be N log N. 2009-04-29 18:57:35 +00:00