title: NoSQL quorum comparing to virtual sharding
body: <p>After reading about few NoSQL techniques it looks for me that <em>Quorum</em> fails comparing with <em>Virtual Sharding</em>. Virtual sharding allow scalability and does not increase amount of read/writes across a system. What's also bad that I absolutely can't find any benefit of quorum over sharding.</p>
  
  <p><strong>Question:</strong> <em>May you act as an advocate of quorum technique from perspective of data consistency/performance/scalability and bring a light to situations where it's better than sharding?</em></p>
  
  <p>Below is my vision of the stuff:</p>
  
  <p><strong>Quorum:</strong></p>
  
  <p>Suppose I have a booking system which demand high data consistency. As one of approaches with NoSQL to achieve data consistency is <em>quorum</em>, means <code>R + W &gt; N</code>, where <code>R</code> - read nodes, <code>W</code> - write nodes and <code>N</code> - total amount of nodes. </p>
  
  <p>As I understand, if you use quorum than to write a row  your db need to perform a write operation <code>W</code> times. Also to read something your db need to do <code>R</code> reads. <em>Right?</em></p>
  
  <p><strong>Virtual sharding:</strong></p>
  
  <p>As I understand, <em>sharding</em> - it's when there's something similar to hashmap, which by some criteria tells you where income data should be stored / from where should be read. Suppose you have <code>N</code> nodes. <em>Virtual</em> means that in order to avoid scalability problems, that hash map would be bigger than <code>N</code>, but suppose <code>10*N</code>. That allow easily reconfigure it on adding new nodes.</p>
  
  <p>What is extremely good about it that it doesn't demand any replication like quorum! Of course in sake of availability/failover you can bring one master-slave backup for each node. But that won't increase amount of read/writes in a system.</p>