<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Apr 23, 2016, at 3:10 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" class="">jaypipes@gmail.com</a>> wrote:<br class=""><div class=""><br class=""><blockquote type="cite" class="">BTW, note to Ed Leafe... unless your distributed data store supports transactional semantics, you can't use a distributed data store for these types of solutions. Instead, you will need to write a whole bunch of code that does post-auditing of claims and quotas and a system that accepts that oversubscription and out-of-sync quota limits and usages is a fact of life. </blockquote><div class=""><br class=""></div><div class="">Yes, that was one of the things that I liked about Cassandra: <a href="http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0" class="">http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0</a></div><div class=""><br class=""></div><div class="">For instance, in the scheduler, making a claim would simply fail if another process had changed any of the resources in question, as the transaction would not be allowed.</div><br class=""><blockquote type="cite" class="">Not to mention needing to implement JOINs in Python.</blockquote></div><br class=""><div class="">Heh, JOIN in a column family database is not needed. You do have to think about data a lot differently, and that means unlearning everything you know about normalization. As a long-time SQL DB admin, it took my brain quite some time to be able to understand the different approach.</div><div class=""><br class=""></div><div class="">-- Ed Leafe</div></body></html>