title: MongoDb vs Cassandra:Read/Write myths?
body: <p>Read couple of articles on net regarding MongoDB vs. Cassandra read/write performance, </p>
  
  <p><strong>Write</strong> </p>
  
  <p>It is generally said that Cassandra's write performance is better than Mongo's when data is humongous. See the statement below.</p>
  
  <blockquote>
    <p>Cassandra's storage engine provides constant-time writes no matter how
    big your data set grows. Writes are more problematic in MongoDB,
    partly because of the b-tree based storage engine, but more because of
    the per database write lock.</p>
  </blockquote>
  
  <p><strong>Here is my question :-</strong> Is this statement still correct? Per my understanding Mongo supports lock per document instead per database . Right? So at present is Cassandra still better than Mongo in write performnace? if yes why?</p>
  
  <p><strong>Read</strong> </p>
  
  <p>It is generally said that Mongo's read performance is better than Cassandra's but I did not find any reasoning what makes Mongo's read better than Cassandra's ?</p>
  
  <p><strong>Update :-</strong></p>
  
  <p>From Jared Answer at <a href="https://www.quora.com/NoSQL-Which-is-a-better-choice-for-read-intensive-work-load-MongoDB-or-Cassandra" rel="noreferrer">this forum</a> </p>
  
  <blockquote>
    <p>Reads are more efficient in MongoDB's storage engine than they are in
    Cassandra. Cassandra's storage engine performs very well on writes
    because it stores data in an append only format. This makes great use
    of spinning disk drives that have poor seek times, but can do serial
    writes very quickly. But the downside is that when you do a read, you
    often need to scan through several versions of an object to get the
    most recent version to return to the caller. MongoDB updates data in
    place. This means it does more random IO when writes are processed,
    but it has the benefit of being faster when processing reads, since
    you can find the exact location of the object on disk in one b-tree
    lookup.</p>
  </blockquote>
  
  <p>It helped me to understand Cassandra is faster while delete/edit on existing record because it has to just append it at last instead of in place edit like Mongo which has to search first and then edit it. This makes cassandra better in write than Mongo</p>
  
  <p>But the same thing thing makes Mongo slower than Cassandra because Cassandra has to scan through several versions of an same record to get the most recent version to return to the caller</p>
  
  <p>Another reason from this  <a href="https://scalegrid.io/blog/cassandra-vs-mongodb/" rel="noreferrer">blog</a> why cassandra is better in write</p>
  
  <blockquote>
    <p>MongoDB with its “single master” model can take writes only on the
    primary. The secondary servers can only be used for reads. So
    essentially if you have three node replica set, only the master is
    taking writes and the other two nodes are only used for reads. This
    greatly limits write scalability. You can deploy multiple shards but
    essentially only 1/3 of your data nodes can take writes. Cassandra
    with its “multiple master” model can take writes on any server.
    Essentially your write scalability is limited by the number of servers
    you have in the cluster. The more servers you have in the cluster, the
    better it will scale.</p>
  </blockquote>
  
  <p>From the same <a href="https://scalegrid.io/blog/cassandra-vs-mongodb/" rel="noreferrer">blog</a> why Mongo is better in read than cassandra</p>
  
  <blockquote>
    <p>Secondary indexes are a first-class construct in MongoDB. This makes
    it easy to index any property of an object stored in MongoDB even if
    it is nested. This makes it really easy to query based on these
    secondary indexes. Cassandra has only cursory support for secondary
    indexes. Secondary indexes are also limited to single columns and
    equality comparisons. If you are mostly going to be querying by the
    primary key then Cassandra will work well for you.</p>
  </blockquote>