GOPHERSPACE.DE - P H O X Y
gophering on gopher.beastieboy.net
      ___________________________

       WHEN SHALL I USE MONGODB?

     Nicolas Herry
      ___________________________


       2017/12/02





1 When shall I use MongoDB?
===========================

  When to pick MongoDB over a relational database can be a tricky
  question. Luckily, I'm here to help with a quick FAQ. Guaranteed 100%
  bias free.


1.1 Does MongoDB guarantee data persistence?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MongoDB is not ACID-compliant, which means that data can be lost. You
  should only pick MongoDB when you intend to store data you don't mind
  losing.


1.2 Does MongoDB scale well?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  With MongoDB, data is stored duplicated. This means that indexes, when
  they are used, cannot be as effective as that of a relational
  database. Also, since data is duplicated, this means that databases
  tend to occupy more space on the disk than with a relational
  database. However, MongoDB scales through sharding, which means that
  data is spread across multiple servers to both balance the load and
  provide some redundancy. So if scaling is limited on one server, one
  can always add more servers to cope with the load. As for writing,
  MongoDB offer two approaches: with the MMAPv1 engine, it locks
  collections when a document is being saved, disallowing concurrent
  writing to different documents. This in part comes from the fact that
  MongoDB lacks transaction isolation (ACIDity). The second option
  involves the new default engine, WiredTiger, which relies on the
  optimistic concurrency model, assuming very low data contention. When
  a conflict occurs, transactions are rolled back and need to be run
  again. This is fine if transactions deal with different piece of data;
  and very costly when multiple writes happen at the same time on the
  same document.


1.3 Is MongoDB more flexible than old cranky relational databases?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MongoDB gives developers the possibility to store data as documents,
  that is without any defined schema. In a collection, documents can
  actually look very different. This means the shape of the data doesn't
  have to be anticipated from the beginning, and fields can be added
  later. However, as a result, there is no way to alter a collection as
  a whole in one go: each record has to be fetched, edited, and saved
  back in the database. On large datasets, this can take hours. One also
  should think if their scenario really implies going on production
  without a clear idea of what the data looks like.


1.4 Does MongoDB makes the life easier for application developers?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Since MongoDB allows application developers to start working without
  thinking about the schema or the data itself, things are indeed
  easy. However, since the approach revolves only around data storage
  and not data itself (shape, type, constraints, etc.), developers have
  to write the validation part themselves, on the application side. This
  means more code to write, maintain, debug.


1.5 Is MongoDB the quickest engine with flexible, modern JSON data?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  MongoDB makes JSON and binary JSON data its sole data format and tries
  to be effective at storing and reading it back. However, relational
  databases can also manage JSON and binary JSON data, and can be pretty
  efficient with it. Actually, PostgreSQL outperformed MongoDB is a
  series of benchmarks. Benchmarks being benchmarks, one can consider
  that at the very least, it's not clear which of MongoDB and PostgreSQL
  is the most efficient. However, it is clear that with PostreSQL, one
  also gets to benefit from all the rest it has to offer: ACIDity, data
  validation, indexes, etc.


1.6 To sum up
~~~~~~~~~~~~~

  One should use MongoDB when they want to store a moderate quantity of
  data they don't mind losing, don't know much about and don't mind
  locking for basic maintenance tasks. It's stunning how much cutting
  edge in 2017 resembles cutting edge in 1997, when startups were trying
  to circumvent the shortcomings of MyISAM by cobbling together piles of
  Perl code, ending up with half-working data processing pipelines.