<story><title>Sharding data models</title><url>https://www.citusdata.com/blog/2017/08/28/five-data-models-for-sharding/</url></story><parent_chain></parent_chain><comment><author>contingencies</author><text>For financial transaction services I can recommend sharding first by customer, then by ledger. As a result, instead of enforcing double-entry book-keeping standards within a single database, do it at an application-specific middleware server layer to enforce only the guarantees you need.&lt;p&gt;As with all decisions, there are tradeoffs. For a little more up-front complexity and a tiny nominal performance hit, this allows maintenance, encryption, non-uniform storage paradigms to suit individual ledgers, rolling upgrades, storage location migration, and other cool stuff which is typically painful with traditional all-or-nothing RDBMS architectures.</text></comment>
<story><title>Sharding data models</title><url>https://www.citusdata.com/blog/2017/08/28/five-data-models-for-sharding/</url></story><parent_chain></parent_chain><comment><author>njay</author><text>Citus is a pretty powerful tool. We recently used Citus to help scale one of our databases and wrote a blog post about it:
 &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;hipmunk.github.io&amp;#x2F;posts&amp;#x2F;2017&amp;#x2F;Aug&amp;#x2F;16&amp;#x2F;a-fare-cache-in-a-sharded-data-cluster&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;hipmunk.github.io&amp;#x2F;posts&amp;#x2F;2017&amp;#x2F;Aug&amp;#x2F;16&amp;#x2F;a-fare-cache-in-...&lt;/a&gt;</text></comment>