5

オンライン プラットフォーム (API、サーバー、データ、Wahoo!) の構築に着手しています。コンテキストとして、Twitter のようなものを構築する必要があると想像してください。ただし、コメント (ツイート) はライブ イベントを中心に編成されています。ライブ イベント自体に関する情報は、可能な限り迅速かつ一貫してクライアントに配信する必要がありますが、イベントに関するコメントは、配信されるまでに多少時間がかかる可能性があります。ライブ イベントが終了した後は、読み物に夢中になります。

スケーラビリティは非常に重要です。VPS スライスのレンタルを開始し、そこから拡張したいと考えています。私はクラウドの大ファンで、できるだけ長くそこにとどまりたいと思っています。おそらくRubyを使用するでしょう。

RDBMS の代わりにドキュメント ストアを試してみたいと確信しています。スキーマレス ストレージのアイデアと、キーと値に焦点を当てることでスケーラビリティが容易になるという約束が気に入っています。

問題は、どのテクノロジーが当社のプラットフォームに最も適しているかわからないことです。私は、Couch、Mongo、Tokyo Cabinet、Cassandra、および blob されたドキュメントを持つ RDBMS を見てきました。この特定の仕事に適したツールを選ぶのに何か助けはありますか?

4

3 に答える 3

7

BJ Clarkによる NO SQL 代替比較をチェックしてください。

スケーラビリティは非常に重要です。

次に、彼のブログからの抜粋を検討する必要があります。

  1. 東京内閣 - スケールしない
  2. Redis - スケーリングしない
  3. ヴォルデモート計画 - 鱗
  4. MongoDB - 制限付き (シャーディングが実装されています)
  5. カサンドラ - 鱗
  6. Amazon S3 - スケール
  7. Couch -スケーリングしない(クラスタリングとレプリケーション)
  8. MySQL - スケーリングしない

HyperTableを検討してください。これは、No-SQL の代替案の重要な候補でもあります。これは、Google の BigTable コンセプトのオープン ソース実装です。中国の検索エンジン Baidu やエンターテイメント ポータルの Rediff で広く使用されているため、拡張性に優れていると思います。

あなたは言っていました：

ライブ イベント自体に関する情報は、可能な限り迅速かつ一貫してクライアントに配信する必要がありますが、イベントに関するコメントは、配信されるまでに多少時間がかかる可能性があります。ライブ イベントが終了した後は、読み物に夢中になります。

これはTwitterのアプローチのようなものです。プログラミング言語の選択も非常に重要です。Twitter は当初、バックエンド メッセージ配信に Ruby を使用していましたが、それは正しい選択ではないと言っており、メッセージ配信システム全体をScala言語に移行しました。

彼らはまだフロントエンドに Ruby を使用しています。スケーラブルな環境に適した、信頼性が高くフォールト トレラントなシステムを使用する場合は、ScalaまたはErlangを検討する必要があります。

于 2010-01-22T06:10:48.677 に答える
1

水平方向にスケーリングする (複数のノードにデータを分散する) 場合は、CAP 定理を考慮する必要があります。

http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

簡単なことではありませんが、選択する必要があります。常に何らかのトレードオフがあります。

于 2010-01-22T22:24:53.950 に答える
1

Ramesh は良い要約をしています。Cassandra は通常の Dynamo クローン (Voldemort や Dynomite など) よりも豊富なデータ モデルを持っていることを付け加えておきます。Cassandra は Twitter、Mahalo、Ooyala、SimpleGeo、WebEx など ( http://n2.nabble.com/Cassandra-users-survey-td4040068.html ) で使用されており、少なくともそのうちのいくつかは EC2 で Cassandra クラスターを実行しています。またはラックスペース クラウド サーバー。

于 2010-01-22T15:30:45.840 に答える