Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # user >> Designing table with auto increment key


Copy link to this message
-
Designing table with auto increment key
Hello,

Can you please tell me if this is the proper way of designing a table that's
got an auto increment key?  If there's a better way please let me know that
as well.

After reading the mail archives, I learned that the best way is to use the
'incrementColumnValue' method of HTable.

So hypothetically speaking let's say I have to create a "User -> Orders"
relationship.  Every time user creates an order we will assign a system
generated (auto increment) id as primary key for the order.

I am thinking I could do this:

1)  Create a table of Ids for various objects such as "Order".  It will have
just a single row with key "1" and column families for various objects.
 When it's time to add a new order for a user I can do something like this:

HTable tableIds = new HTable("IDs");
Get get = new Get(Bytes.toBytes("1"));
Result result = tableIds.get(get);
long newOrderId = tableIds.incrementColumnValue(result.getRow(), "orders",
"orderId", 1);

// In future I could use the same table for other objects as follows
// long newInvoiceId = tableIds.incrementColumnValue(result.getRow(),
"invoices", "invoiceId", 1);

2)  Once the newOrderId is retrieved I can add the info about order to
UserOrder table with a key of format:  userId + "*" + newOrderId.  The
"info" family of this table will have columns such as "orderAmount" ,
"orderDate" etc.
As per the documentation, the 'incrementColumnValue' is done in exclusive
and serial fashion for each row with a rowlock.  In other words, even in
multi-threading environment we are guaranteed to get a unique key per
thread, correct?

Is this a correct/good design for a table that needs auto increment key?
 Please let me know.  Thanks.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB