1

アプリケーション用のデータベースを選択中です。私はMySQLを最も長い間使用していますが、現在のアプリケーションではパフォーマンスとスケーラビリティが重要であり、MySQLには制限があることを知っており、Key-Valueストア、列ベースのDB、ドキュメントベースのDBなどについて多くのことを聞いています。 。私は調べました：

  • カサンドラ
  • MongoDB
  • Redis
  • CouchDB

それらはすべて、MySQLなどのリレーショナルDBよりも高速であるように見えます（または主張しています）。
私はRubyonRailsを使用していますが、上記すべてのクライアントがあるので、問題はないはずです。

私のデータモデルは、ほとんどの場合、写真、ビデオ、投稿などのさまざまなアイテムに関連するユーザーオブジェクト（豊富なプロファイルと設定）を中心とした単純なものであり、それぞれに1つ以上のタグがあります。

これらのデータベースが新しいという事実は、オンラインでそれらのための多くのリソースがないようです。さらに、それらは構造的に異なるため、後で切り替えるのは簡単ではありません。

優れたパフォーマンスと拡張性を備えた、私のアプリケーションに最も適していると思われるDBについてのご意見をお聞かせください。ありがとう、

タム

4

3 に答える 3

8

ステップ1）最も強力なテクノロジーを使用してデザインを作成します。

ステップ2）ソーシャルネットワークを解放し、非リレーショナルデータベースの調査を開始し、最も快適に感じる方をマスターします。

ステップ3）データ層をリファクタリングして、MySQLを新しく学習したDBテクノロジーにすばやく簡単に置き換えることができるようにします。

ステップ4）Webサイトが大きくなりすぎて、MySQLを交換する必要が生じ、穴を塞ぎ始めるのを待ちます。

これはちょっと生意気なように思えますが、実際に私のポイントは、ソフトウェアをリリースして、実際に問題になるときにスケールなどについて心配し始めることです。

于 2010-02-20T19:34:10.433 に答える
0

少なくともアプリにとって、ドキュメントデータベースのようなものの主な利点は、ユーザーの情報グロブ全体を単一のドキュメントとして扱うことができることです。プロパティや新機能などのテーブルを追加することを心配する必要はありません。むしろ、その大部分をユーザードキュメントに保持し、動的に更新することができます。

頻繁に読む場合、めったに書かない場合、これは扱います。

これで、このようなことを行うために「ドキュメントデータベース」は必要ありません。MySQL et alは、ドキュメントを保持するための主キーとCLOB（テキスト）/BLOBフィールドで問題なく動作します。

CouchDB（この分野で私が最もよく知っているもの）のようなものが役立つのは、レプリケーションが十分にサポートされていることであり、ドキュメントの特定の属性に関するビューを作成するのは簡単です（たとえば、すべての「プレミア」が必要です）メンバー、または何でも）。

さらに、CouchDBはHTTPであるため、利用可能な最新のキャッシュなどでうまく機能します。これは、特に大量の操作を読み取る場合に、スケーリングに役立ちます。

これの多くは、実際のツールよりも全体的なアーキテクチャに関するものなので、最初にそれを検討するようにしてください。

于 2010-02-20T19:13:54.967 に答える
0

いくつかの大規模なサイトで使用されている東京キャビネットもあります。

私はまだ使用していませんが、Twitterのようなサイトが大量のメッセージを非常に迅速に処理する必要がある場合、RDBMSのオーバーヘッドは非常に大きく、応答時間が大幅に遅くなり始めると理解しています。

あなたがする必要があるのは、RDBMSから得られる利点を見て、それをその速度と比較検討し、nosqlタイプのデータベースに対して同じことを逆に行うことです。

RDBMSは標準を提供し、セキュリティ、整合性、およびセットに基づく汎用言語を提供して、データ操作を容易にします。ただし、その構造のすべてまたは一部が必要ない場合は、速度が低下します。

SQLの前は、CODASYLとネットワークデータベースでした。SQLは、スキルの移植性や移転性などの理由で成功しました。しかし、モバイル有線の世界はこれを変えており、調査する価値があると思います。

于 2010-02-20T19:29:09.210 に答える