5

バックエンドで PHP/MySQL/Solr を使用し、フロントエンドで Javascript/jQuery/Backbone を使用して、ほとんどの Web 開発を行ってきました。

私はすでにいくつかの Node アプリを作成しましたが、多くの Node チュートリアル/書籍で使用されている Mongodb/Couchdb の代わりに MySQL を使用しています。Node を開発しているほとんどの人が使用しているので、MySQL の代わりに Mongo/Couch を使い始めますか? MySQL は問題なく動作しているようですが、Mongo/Couch に切り替えるメリットがよくわかりません。

現在、「フロントエンド」アプリ サーバーが PHP/MySQL で、数値計算サーバーが Node.js にあるサイトを開始しています。「フロントエンド」を提供するために PHP に固執する理由は、PHP フレームワークでの開発に非常に慣れているからです。

ノードを選択する理由は、アイドル/待機時間が秒単位の同時タスクが多数あるためです。そして、これは高度にスケーラブルでなければなりません。

データベースに保存されるものは、MySQL テーブルに保存する通常のものと似ています。

4

2 に答える 2

8

あなたが考慮する必要があるいくつかのこと -

  1. スケーリングは、mongoDB に移行した最も重要な理由の 1 つです。MongoDB を分割して複製するのは簡単です。したがって、アプリケーションを水平方向にスケーリングする必要がある場合は、mongoDB が最適です。垂直方向のスケーリングは、すぐにハードウェアの制限に達するまでしかできません...さらに、mysql でのシャーディングは本当に苦痛です。
  2. 2 つ目は DB スキーマです。私たちのようなほとんどのスタートアップでは、要件と機能が非常に急速に変化します。そのため、一定期間にわたって、mysql スキーマ ベースの DB は「優れた実践」というよりも束縛のようなものになる可能性があります。そのような状況では、誰も「良い習慣」を気にしません。そのため、拡張可能な非スキーマ DB が必要な場合は、mongoDB を検討してください。
  3. これにはすべて、mongoDB (およびその他の NoSql ソリューション) が DB の世界で輝かしい新しいおもちゃであるという免責事項が付属しています。それらは MySQL ほど成熟していません。mongo を含むそれらのほとんどは、トランザクションを適切に処理しません。したがって、金融取引システムを構築しているとしましょう。その場合、ACID 準拠 (innodb エンジンを参照) として mysql をやみくもに使用するように伝えます。繰り返しになりますが、これらの決定の多くは、達成しようとしていることに依存しています...

結論: NoSQLからの言い換え

指摘しておくべき本当のことは、データベースを選択できないために何か素晴らしいものを作ることをためらわれているのであれば、それは間違っているということです. あなたがmysqlを知っているなら、それを使ってください。実際に必要なときに最適化します。ak/v ストアのように使用し、rdbms のように使用しますが、神のために、キラー アプリを作成してください。これは、ほとんどのアプリにとって重要ではありません。Facebook は今でも MySQL をたくさん使っています。ウィキペディアは MySQL をよく使用しています。FriendFeed は MySQL を多用しています。NoSQL は優れたツールですが、競争上の優位性にはならないことは確かです。アプリを熱くすることもありません。また、何よりも、ユーザーはこれについて気にしません。

次のアプリは何に基づいて構築する予定ですか? おそらくPostgresです。NoSQL を使用しますか? 多分。Hadoop と Hive も使用する可能性があります。すべてをフラットファイルに保存するかもしれません。リニアモーターカーのハッキングを始めるかもしれません。仕事に最適なものは何でも使用します。レポートが必要な場合、NoSQL は使用しません。キャッシングが必要な場合は、おそらく Tokyo Tyrant を使用します。ACIDity が必要な場合、NoSQL は使用しません。大量のカウンターが必要な場合は、Redis を使用します。トランザクションが必要な場合は、Postgres を使用します。1 種類のドキュメントが大量にある場合は、おそらく Mongo を使用します。1 日に 10 億個のオブジェクトを作成する必要がある場合は、おそらく Voldemort を使用します。全文検索が必要な場合は、おそらく Solr を使用します。揮発性データの全文検索が必要な場合は、おそらく Sphinx を使用します。

おもしろすぎて関連性がありすぎて再投稿できません - MongoDb は Web スケールです

ここに画像の説明を入力

于 2012-12-29T05:21:03.913 に答える
0

複数のテーブルの IO がボトルネックになるようなデータの大幅な正規化を行わない限り、MySQL は問題なく動作します。ほとんどの人が node.js で mongo を使用しているという理由だけで切り替える理由はありません。

Mongodb/Couchdb/Orientdb は、多数の「ドキュメント」オブジェクトを格納するのに最適です。データが RDBMS スキーマに収まる場合は、ドキュメントを作成する必要はありません。私が見たところによると、オブジェクトを作成する際の主な待ち時間は、データ フィールドにデータを入力するときに発生します。NoSQL DB ではすべてのデータを一度に取得できますが、正規化された RDBMS ではデータ フィールドがさまざまなソースから入力されるため、わずかな遅延が生じます。もちろん、キャッシュを使用してそれを改善することもできます。RDBMS でスケーラビリティが必要な場合は、NuoDB を検討できます。

バックエンド アプリ サーバーにはスケーラビリティが必要なので、vertx を調べることもできます。ベンチマークによると、ノードよりも優れているように見えますが、まだ非常に新しい.

于 2012-12-29T10:34:11.900 に答える