[erlang-questions] Web app back-ends

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Thu Jun 19 11:17:58 CEST 2014

Replying inline

On Wed, Jun 18, 2014 at 11:21 PM, Lloyd R. Prentice <lloyd@REDACTED>
> SQL/Relational Databases:
> postgeSQL
> - consider when: you want to use a battle-tested relational data store.
> - reject when: your data needs are more key-value oriented or
> free form/less structured.
This is a bad reason for rejecting it. Postgres usually outperforms MongoDB
for workloads with a good write/read split around 50/50. Furthermore, in
9.4, the jsonb type will make short work of anything that MongoDB stands

The major weakness is a foreign store and this might slow prototyping down.

> MySQL/MariaDB/etc:
> - consider when: You want a SQL datastore that's fast, but that is known
> to take some shortcuts in the name of speed or "ease of use" (such as
> silently truncating strings if too long for fields), and master/slave
> replication is good enough.
> - reject when: Your data needs are more key-value oriented or
> free form/less structured.

Never use. Never ever use. Only a viable option if an existing part of the
infrastructure use MySQL.

The very reason MySQL got market share is ease-of-use. They targeted making
it easy to get up and running and the weak constraint validation is a big
part of this.

> NoSQL/Key-Value stores:
> dets
> - consider when: speed is not a priority, since all requests immediately
> go to and come from disk
> - reject when: speed is essential or you need replication.
Reject when your data grows beyond 2 gigabyte.

> mnesia
> - consider when: you want built-in clustering/replication, storing Erlang
> records and terms natively, and built into the Erlang system (no
> dependencies needed)
> - reject when: you don't want to mess around with records or QLC.

Excellent choice for databases up to 128-1024 gigabyte, depending on how
beefy a machine you can get. Read the original mnesia white paper on this
one (it's on erlang.se somewhere)

* sub microsecond k/v lookup.
* occasional transactions with no soft-realtime-guarantee
* distribution for live replication of the data store

> riak
> - consider when: you need high availability, no-single-point-of-failure,
> replicated clustered key-value datastore.
> - reject when: __________

A good reason for rejecting is your data size. Most people can store all of
their data in less than a Terabyte and then there is less need for
something like Riak.

> mongoDB:
> - consider when: https://www.youtube.com/watch?v=b2F-DItXtZs
> - reject when: https://www.youtube.com/watch?v=b2F-DItXtZs

MongoDB understands time to market. Look at their focus:

* Good drivers for major languages
* Easy interface
* Very easy to set up and get running
* Excellent for prototyping

On the other hand:

* Do not trust it real-world-data
* Performance suffers once your data size grows
* The distribution features has historically been unstable and full of

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140619/443c5589/attachment.htm>

More information about the erlang-questions mailing list