20

現在、多数のユーザーからの多数のテキスト エントリを集約する Web アプリケーションのプロトタイプを開発しています。このデータは頻繁に表示され、頻繁に更新される必要があります。現時点では、MySQL データベース内にコンテンツを保存し、NHibernate ORM レイヤーを使用して DB とやり取りしています。ユーザー、ロール、送信、タグ、通知などに対して定義されたテーブルがあります。このソリューションはうまく機能し、私のコードは見栄えがよく、正気であるため気に入っていますが、サイズが大きくなると MySQL がどのように動作するかについても心配しています。私たちのデータベースの数はかなりの数に達しています。結合操作を十分に速く実行するのに苦労するかもしれません。

これにより、 MongoDB、CouchDB、Cassandra、Hadoopなどの非リレーショナル データベース システムについて考えるようになりました。残念ながら私はどちらも経験がありません。MongoDB に関するいくつかの良いレビューを読みましたが、面白そうです。私は喜んで時間を費やして、いずれかが進むべき道であることが判明したかどうかを学びます. リレーショナルdbmsを使用しない場合に考慮すべき点や問題を提供してくれる人がいれば幸いです。

4

5 に答える 5

18

ここでの他の回答は主に技術的な側面に焦点を当てていますが、スタートアップ企業の側面に焦点を当てた重要なポイントがあると思います。

  • 才能の利用可能性。MySQL は非常に一般的であり、より希少なデータベース システムと比較して、開発者を見つけるのはおそらく簡単 (そしてさらに重要なことに、より安価) であることがわかります。このより大きな開発者ベースは、より多くのチュートリアル、より活発なサポート コミュニティなども意味します。
  • 開発の容易さ。繰り返しになりますが、MySQL は非常に一般的であるため、非常に多くのシステム/サービスで選択されているデータベースであることがわかります。この共通点により、外部統合が少し簡単になる場合があります。
  • あなたは決して存在しないかもしれない状況に備えており、そうなったとしても対処可能です。MySQL の限界に近づいている企業 (新興企業は気にしない) はほとんどなく、敬意を払って (そして、ここで推測しているだけです)。あなたのスタートアップが、適切に構造化され、十分にリソースを備えた MySQL データベースを不自由にするほどのデータ スループットに達する可能性は、ほぼゼロです。

基本的に、MySQL は多くのデータを処理でき、十分に実証され、十分にサポートされているため、どのデータベースを使用するかについて心配することに時間 (== お金) を費やす必要はありません。

技術的な側面に戻ります...データベースの選択よりもアプリの速度にはるかに大きな影響を与えるものは、どれだけ効率的にデータをキャッシュできるかです。効果的なキャッシュは、データベースの負荷を軽減し、アプリの一般的な応答を高速化するという劇的な効果をもたらす可能性があります。キャッシング ソリューションの調査に時間を費やし、それらのソリューションを最大限に活用できる方法でアプリを開発していることを確認してください。

参考までに、私が選んだキャッシング ソリューションはmemcachedです。

于 2010-05-15T14:24:54.877 に答える
8

これまでのところ、リレーショナル側で MySQL の代替として PostgreSQL について言及した人はいません。MySQL ライブラリは純粋な GPL であり、LGPL ではないことに注意してください。リンクした場合、コードをリリースせざるを得なくなる可能性がありますが、法的な経験が豊富な人がその意味をよりよく伝えることができるかもしれません. 一方、MySQL ライブラリへのリンクは、サーバーに接続してコマンドを発行することと同じではなく、クローズド ソースを使用して行うことができます。

通常、PostreSQL は Oracle の最良の無料代替品であり、BSD ライセンスはよりビジネスに適しているはずです。

あなたは非リレーショナル データベースを好むので、移行がより劇的になることを考慮してください。データベースをカスタマイズする必要がある場合は、ライセンス タイプの要因も考慮する必要があります。

どれが最良のデータベースの選択であるかに実際に深い影響を与える3つのことがありますが、言及していません。

  1. データのサイズ、またはデータベース内にファイルを保存する必要があるかどうか。
  2. 膨大な数の読み取りと、ごくわずかな (制限付きの) 書き込み。その場合、データベース以上に LDAP などのディレクトリが必要です
  3. データの配布や複製の重要性。ほとんどのリレーショナル データベースは多かれ少なかれ適切に複製できますが、その概念/設計により、データ分散も処理しません...ただし、1 つのサーバーに収まらないデータや、特別な分離が必要なアクセス権を持っているデータをできるだけ多く処理しますか? /余分なサーバー?

ただし、ほとんどの人は、SQL を学ぶのが好きではないという理由だけで、非リレーショナル データベースを選択します。

于 2010-05-15T14:14:28.913 に答える
1

各データベースを試して、アプリケーションの開発が最も簡単なデータベースを選択することをお勧めします。http://try.mongodb.orgにアクセスして、簡単なチュートリアルでMongoDBを試してください。最初は開発者の時間がCPU時間よりも価値があるので、速度についてはそれほど心配しないでください。

多くのMongoDBユーザーがORMとキャッシングレイヤーを捨てることができたことを私は知っています。Mongoのデータモデルは、リレーショナルテーブルよりも操作するオブジェクトに非常に近いため、コメント付きのブログ投稿など、ネストされたオブジェクトのリストが含まれている場合でも、通常はオブジェクトをそのまま直接保存できます。また、mongoはほとんどのサイトで現状のままで十分に高速であるため、キャッシュの複雑さに対処することを回避し、通常、よりリアルタイムのサイトを提供できます。たとえば、Wordnik.comは、1.2TB/50億のオブジェクトDBで250,000回の読み取り/秒と100,000回の挿入/秒を報告しました。

.NetからMongoDBに接続する方法はいくつかありますが、そのプラットフォームについて十分な経験がなく、どれが最適かを知ることができません。

免責事項：私はMongoDBで10genで働いているので、少し偏見があります。

于 2010-05-17T18:37:23.413 に答える
1

推測せずに測定してください。

リレーショナル データベースと NoSQL データベースはどちらも、アプリケーションがそれぞれのケースで適切に作成され、実行されるシステムが適切に調整されていれば、非常にスケーリングできます。

そのため、NoSQL のユースケースがある場合は、それに合わせてコーディングしてください。または、リレーショナルに慣れている場合は、それに合わせてコーディングしてください。次に、そのパフォーマンスとスケーリングを測定し、問題がなければ続行し、そうでない場合はその理由を分析します。

パフォーマンスの問題を理解してから、エキゾチックなテクノロジーを探しに行くべきです。そのテクノロジーに慣れているか、他の理由でそれを試してみたい場合を除きます。

于 2010-05-15T10:08:53.713 に答える
1

かなりの量のデータとは何だと思いますか? MySQL、および基本的にほとんどのリレーショナル データベース エンジンは、適切なインデックスと適切なデータベース スキーマを使用して、かなり大量のデータを処理できます。

より多くのデータ量でMySQLがどのように動作するかをあなたのセットアップで試してみませんか? MySQL テスト データベースに現実的なデータを生成するスクリプトをいくつか作成し、システムにいくらかの負荷を生成して、十分に高速かどうかを確認します。

十分に高速でない場合にのみ、まずデータベースの最適化と別のデータベース エンジンへの変更を検討してください。

NHibernateには注意してください。コーディングが簡単で優れたソリューションを作成するのは簡単ですが、大量のデータではパフォーマンスが低下します。たとえば、関連付けで遅延フェッチと積極フェッチのどちらを使用するかは、慎重に検討する必要があります。NHibernate を使用してはならないという意味ではありませんが、NHibernate がどのように機能するか、たとえば「n + 1 が選択する」-problem の意味などを理解していることを確認してください。

于 2010-05-15T09:15:48.077 に答える