<div dir="ltr">Replying inline<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 18, 2014 at 11:21 PM, Lloyd R. Prentice <span dir="ltr"><<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div><span style="background-color:rgba(255,255,255,0)"><br>SQL/Relational Databases:</span></div><div><span style="background-color:rgba(255,255,255,0)"><br>postgeSQL<br>- consider when: you want to use a battle-tested relational data store.<br>
- reject when: your data needs are more key-value oriented or free form/less structured.<br><br></span></div></div></blockquote><div><br></div><div>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 for.</div>
<div><br></div><div>The major weakness is a foreign store and this might slow prototyping down.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">
<div><span style="background-color:rgba(255,255,255,0)"></span></div><div><span style="background-color:rgba(255,255,255,0)">MySQL/MariaDB/etc:<br>- 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.<br>
- reject when: Your data needs are more key-value oriented or free form/less structured.<br></span></div></div></blockquote><div><br></div><div>Never use. Never ever use. Only a viable option if an existing part of the infrastructure use MySQL.</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div><span style="background-color:rgba(255,255,255,0)">NoSQL/Key-Value stores:</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">dets<br>
- consider when: speed is not a priority, since all requests immediately go to and come from disk<br>- reject when: speed is essential or you need replication.<br><br></span></div></div></blockquote><div><br></div><div>Reject when your data grows beyond 2 gigabyte.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span style="background-color:rgba(255,255,255,0)"></span></div><div><span style="background-color:rgba(255,255,255,0)">mnesia<br>
- consider when: you want built-in clustering/replication, storing Erlang records and terms natively, and built into the Erlang system (no dependencies needed)<br>- reject when: you don't want to mess around with records or QLC.<br>
</span></div></div></blockquote><div><br></div><div>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 <a href="http://erlang.se">erlang.se</a> somewhere)</div>
<div><br></div><div>* sub microsecond k/v lookup.</div><div>* occasional transactions with no soft-realtime-guarantee</div><div>* distribution for live replication of the data store</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div><span style="background-color:rgba(255,255,255,0)">riak<br>- consider when: you need high availability, no-single-point-of-failure, replicated clustered key-value datastore.<br>- reject when: __________<br>
</span></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span style="background-color:rgba(255,255,255,0)"></span></div><div><span style="background-color:rgba(255,255,255,0)">mongoDB:<br>
- consider when: <a href="https://www.youtube.com/watch?v=b2F-DItXtZs" target="_blank">https://www.youtube.com/watch?v=b2F-DItXtZs</a><br>- reject when: <a href="https://www.youtube.com/watch?v=b2F-DItXtZs" target="_blank">https://www.youtube.com/watch?v=b2F-DItXtZs</a></span></div>
</div></blockquote><div><br></div><div>MongoDB understands time to market. Look at their focus:</div><div><br></div><div>* Good drivers for major languages</div><div>* Easy interface</div><div>* Very easy to set up and get running</div>
<div>* Excellent for prototyping</div><div><br></div><div>On the other hand:</div><div><br></div><div>* Do not trust it real-world-data</div><div>* Performance suffers once your data size grows</div><div>* The distribution features has historically been unstable and full of problems</div>
<div> </div></div><div><br></div>-- <br>J.
</div></div>