ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

HBase Secondary Indexes

I have spent some time to understand the complex solution for HBase secondary indexes suggested ☞ over here. As I pointed out in that post comment thread, I do see a few major drawbacks to this approach. Anyway, now that the code seem to have been made ☞ available, I expect more experienced HBase users will take a look at it and agree or disagree with its approach.

Meanwhile, I get the feeling that this ☞ other solution might be better as it is built on HBase API and not trying to trick HBase behavior.

Expert opinions?

Update: Bruno Dumon is pointing out in the comments below that the two solutions are in fact pretty similar and that “my indexing package basically goes more into detail on that aspect: generating appropriate index row keys, while ignoring how updates should be pushed to the index (I’m thinking of some scalable queue solution for this)”.