MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？ - Quora
この質問はちょっと古いですね。NoSQLに勢いがあったのは2009-2015年にかけての頃です。
2018年現在は、PostgreSQL 10やMySQL 8などRDBMS（以下、わかりやすくSQLと呼びます）でJSONをネイティブに扱える（インデックスを貼ったりツリーの一部を操作したり）のがスタンダードになったので、むしろこれらSQLのほうに勢いがあります。
当時NoSQLが流行った理由は、ちょうどiOSのプラットフォームとSDKが開放されてモバイルアプリの開発が始まって、爆発的にユーザ数が増えるシステムが多くなり、そういった状況ではデータベースがボトルネックになりがちで、スレーブに逃がせるreadよりも分散できないwriteのほうが追いつかなくなって詰んでしまうという逼迫感がありました。
そこで、それよりも少し前からあったmemcachedで標準的な分散手法であったコンシステントハッシュ法などにヒントを得て、CAP定理のような理論的な根拠が見直されたこともあって、分散ストレージのブームとともに、シャーディングといって、writeをする対象そのものを水平分散するのが流行しました。
この勢いに乗じて、「SQLはジョインするから水平分散できない」というよくわからない理由で（SQLでもNoSQLのようにジョインしなければ条件は同じなのですが）、ACIDなどトランザクションの特性やその他の長年積み上げてきたものをいったん全否定することでゼロから作り直そうというムーブメントが生まれました。
それがNoSQLです。
データベースの内部構造をよく知っている人たちは冷静にみていて、あまりデータベースの技術的な詳細を知らない人たちが大騒ぎしているな、という印象でした。
当時も今もNoSQLの代表格といえばMongoDBですが、MongoDBのwriteは速い！と言われて、よく調べるとちゃんと永続化してないので/dev/nullに書いているのと同じという笑い話がありました（ちなみにMySQLにはblackholeといって本当に/dev/nullに書くストレージエンジンがあります。どのように使うのか興味がある人は調べてみてください）。そのMongoDBは、その数年後、問題の多かった自社エンジンを捨てて、Wired TigerというInnoDBそっくりなストレージエンジンを買収し、さらに数年後のつい最近、複数行にまたがる「普通の」トランザクションを実装することを発表しました。その結果起きたことは？PostgreSQLやMySQLと同じ性能になりました。（笑）
しかし、それ以前の話として、コンピュータサイエンスの1年目で習うような話ですが、ただの水平分散というのはベストケースでO(n)の性能しか出ず、さらにいうとアムダールの法則により、かけたコストあたりの見返りは漸減していくので、アルゴリズム的には「ナイーブ」とか「ブルートフォース（力任せ）」と揶揄される悪手です。
つまり、10万ユーザあたり1台必要なら、100万ユーザで10台、1000万ユーザで100台、1億ユーザで1000台と、規模に正比例して台数が増えていくことになります。（実際には並列化によるオーバーヘッドでさらに悪化していきます）
これが内部状態を持たないアプリケーションサーバなら良いのですが、大量のデータを抱えるデータベースがこのように分散してしまうと、身動きが取れなくなっていき、将来とれるオプションがどんどん減っていきます。
コンピュータサイエンスは、そういうことではなく、たとえばリニアな問題を対数の問題に変換する、つまりO(n)の問題をO(log n)の問題にするのが真髄です。
10万ユーザあたり1台なら、100万ユーザで2台、1000万ユーザで3台、1億ユーザで4台というように、対数的にしか増えていかないようにする、これがアルゴリズムの本当のパワーです。
この対数化を実現しているのが、実はSQLのインデックスで使われているB-treeというアルゴリズムで、このインデックスがあるがゆえに、テーブルの行数が10倍、1万倍、1億倍になっても性能は1億分の1ではなく8分の1ぐらいのおだやかな性能劣化で収まるのです。こういう圧倒的なパワーこそがサイエンスと呼ぶにふさわしいものです。
ちなみに、私はそのモバイルアプリ全盛期の2009年頃、激しくスケールするシステムで、メインとなるMySQLに加えてMongoDBとRedisも併用していました。NoSQLが流行っていたので、批判するだけでなく実際に使ってみなければわからないことも多いだろうということで採用したのですが、やはり性能面では想定の範囲内というか、ACIDのデータベースとは違うトレードオフを選択しているだけだな、という印象でした。永続化もmmapベースで、ややこしい部分はOSに丸投げしてるだけでした。
しかし、MongoDBは複雑な構造をもったレポートなんかを1つの文書として保存できるのは思いのほか便利で（見出しがあって明細があってメタデータがあってタグの配列があって、というような）、あとcapped collectionといって決まったデータサイズをどんどん上書きしながらログを書いてくれるリングバッファ構造があって、メンテナンスフリーのログとして使えるので、そういったMongoDBならではの機能は重宝しました。性能ではなくて機能重視ですね。
ちなみに、Redisは万人にすすめられる、文句なしに最高に素晴らしい製品です。データベースというよりは、プログラミング言語の配列やマップをサーバ上でアトミックに安全に読み書きできる共有メモリ構造といった感じで、一時的なデータ置き場として使うことが多いですが、SQLしか使ってない人もみんな触れてみてほしいです。
個人的に、MySQLを選ぶかPostgreSQLを選ぶかは気分で決めますが、Redisだけは必ず併用します。
ま、そんなわけで、NoSQLを語るときに「性能」を持ち出す人は、はっきり言って素人だと思います。そうではなくて、SQLにないデータ構造の扱いやすさ、ゼロから作った設計のモダンさ（MongoDBのレプリカセットは全自動で素晴らしい）などがメリットで、そういった良さが生きる部分で「部分的に」使うのが正解だと思います。
それ以外の80%以上のユースケースでは、いまだSQLにまさるものはないでしょう。
GoogleがMap-Reduceの論文を発表して、Hadoopが大流行したあとに起きたことはなんでしたか？Postgresと同じAPIで動かせるRedshiftの大流行でしたね。Googleはanti-SQLの筆頭でしたが、最近ではあきらめてSQLに追随するという流れになっています。
ちなみに、AIと同じで、NoSQLの流行は、今回が初めてじゃないんです。実はOracleが登場する前の1970年代にも、階層データベースからグラフデータベース、オブジェクトデータベースまで、さまざまなデータベースが登場して市場を競っていたんです。そういったことを何度も乗り越えて生き残っているのがSQLというわけです。
この世界は流行り廃りが激しいですが、技術の本質を見極める目を持ちたいものですね。
