問題タブ [horizontal-scaling]

いくつかのグーグルの後、私は見つけました：

mysql docsからのメモ:

MySQL Cluster はノード間でテーブルを自動的にシャード (分割) し、データベースを低コストのコモディティ ハードウェアで水平方向にスケーリングして、SQL からアクセスする場合と NoSQL API を介して直接アクセスする場合の両方で、読み取りと書き込みが集中するワークロードに対応できるようにします。

リレーショナル データベースは水平スケーリングできますか? どういうわけかNoSQLデータベースに基づいていますか?

誰かが実際の例を持っていますか?

このようなデータベースで SQL リクエスト、トランザクションなどを管理するにはどうすればよいですか?

エクスプレスバックエンドでスケーリングしようとしています。問題は、ユーザーが来るたびに、またはサーバーを再起動すると、新しい socket.id が取得されることです。さらに、[Circular JSON] 問題が発生するため、ソケット全体をメモリに保存できません。ソケットの一部を redis に保存して、他のサーバーから同じソケットを取得できるようにするにはどうすればよいですか?

Cassandra (v2.1) クラスターを正常にセットアップして実行した後、いくつかの負荷テストを実行して、YCSB ライブラリー ( https://github.com/jbellis/YCSB fork) を使用してそのパフォーマンスを評価しています。

私の評価では、さまざまなサイズと数の EC2 ノードで同じ構成を使用していますが、パフォーマンスは実際には予測できません。これは、線形にスケーリングすると思われる公式の datastax ドキュメントの主張とは対照的です。

より正確には、2 x m3.large ノードと 4 x m3.large ノードは、100 または 200 スレッドおよび 100k または 1m オペレーションでワークロードを実行する場合、ほぼ同じパフォーマンスを示します。EC2Snitch と 2 つのシード ノードを 1 つのリージョン クラスターで使用しています。コメントされていませんcommitlog_sync: batch。 commitlog_sync_batch_window_in_ms: 50

私は何を間違っていますか、何が欠けているのでしょうか?

ありがとう

データ ストアの設計中に、エントリを分割する方法を検討しています。主なボトルネックは、共有カウンターの分割中です。提供されるチケットがあるとしましょう（典型的な列車の予約、IRCTCなど）。クライアントがそれらの間でライブの一貫性を確認できるように、データストアをどのように分割しますか (予約されたパーセンテージ、つまり現在の値/x)。

読み取りごとの集計はコストがかかりすぎるため、他のポインターがあれば便利です。

また、書き込み操作には同時実行性が想定されているため (スレーブへの読み取りのオフロードはありません)、最終的な一貫性には問題ありません。しかし、不整合の違いをシャード全体で最小限に抑える方法はありますか。たとえば、100 チケットの分割は、4 つのシャード全体で 25、25、25、25 のように行われます。任意の時点で、データベースのビューは x% フルのようになり、シャード間の不整合 (ラウンド ロビン、ハッシュなどの単純な操作) を最小限に抑える方法が必要です。

データ量が多いため、アプリケーション DB をスケールアウトする必要があります。PostgreSQL 9.3 上にあります。それで、私は PostgreSQL-XL を見つけました。これはすばらしく見えますが、分散テーブルの制限について理解するのに苦労しています。レプリケーションによってそれらを分散する (すべてのデータノードでテーブル全体がレプリケートされる) ことはまったく問題ありませんが、データノードに沿って「分割」する必要がある 2 つの大きな関連テーブルがあるとします。

Postgre-XL のドキュメントには、次のように記載されています。

• "(...) 分散テーブルでは、UNIQUE 制約にテーブルの分散列を含める必要があります"
• 「(...)ディストリビューション列は PRIMARY KEY に含める必要があります」
• "(...) REFERENCES (FK) を含む列は分散列にする必要があります。(...) PRIMARY KEY も分散列にする必要があります。"

彼らの例はあまりにも単純すぎて乏しいので、誰かがDISTRIBUTE BY HASH()を使用して postgres-XL の上記の 2 つのテーブルを DDL してくれませんか?

または、スケールアウトする他の方法を提案してください。

いくつかの NoSQL 手法について読んだ後、QuorumはVirtual Shardingと比較して失敗しているように見えます。仮想シャーディングはスケーラビリティを可能にし、システム全体の読み取り/書き込みの量を増加させません。また、シャーディングに対するクォーラムの利点がまったく見つからないことも悪いことです。

質問: データの一貫性/パフォーマンス/スケーラビリティの観点からクォーラム手法の支持者として行動し、シャーディングよりも優れている状況に光を当てていただけますか?

以下は、私のビジョンです。

定足数：

高いデータ整合性を要求する予約システムがあるとします。NoSQL を使用してデータの一貫性を実現するためのアプローチの 1 つとしてクォーラムがあります。つまりR + W > N、Rノードの読み取り、ノードのW書き込み、およびNノー​​ドの合計量です。

私が理解しているように、行を書き込むよりもクォーラムを使用する場合、データベースは書き込み操作をW何度も実行する必要があります。また、何かを読み取るには、データベースがR読み取りを行う必要があります。右？

仮想シャーディング:

私が理解しているように、シャーディング- ハッシュマップに似たものがある場合です。これは、いくつかの基準によって、収入データをどこに保存する必要があるか、どこから読み取る必要があるかを示します。ノードがあるとしますN。仮想とは、スケーラビリティの問題を回避するために、そのハッシュ マップが より大きいことを意味しますNが、仮に10*N. これにより、新しいノードを追加する際に簡単に再構成できます。

クォーラムのようなレプリケーションを必要としないことは、非常に優れています。もちろん、可用性/フェイルオーバーのために、ノードごとに 1 つのマスター/スレーブ バックアップを使用できます。ただし、システムの読み取り/書き込みの量は増えません。

キューからメッセージを受信し、指定された Id を持つ製品をドキュメント データベースから読み取り、メッセージに基づいて何らかの操作ロジックを適用し、最後に更新された製品をデータベースに書き戻すワーカー サービスがあるとします (a)。

この作業は、異なる製品を扱う場合でも安全に並行して実行できるため、水平方向にスケーリングできます (b)。ただし、複数のサービス インスタンスが同じ製品で動作する場合、同時実行の問題またはデータベースからの同時実行例外が発生する可能性があります。その場合、何らかの再試行ロジックを適用する必要があります (それでも、再試行は再び失敗する可能性があります)。 .

質問: どうすればこれを回避できますか? 2 つのインスタンスが同じ製品で動作していないことを確認する方法はありますか?

例/使用例: オンライン ストアでは、productA、productB、および productC のセールが 1 時間で終了し、何百人もの顧客が購入しています。購入ごとに、メッセージがキューに入れられます (productId、numberOfItems、price)。 目標: ワーカー サービスの 3 つのインスタンスを実行し、productA のすべてのメッセージが instanceA に、productB が instanceB に、productC が instanceC に到達するようにするにはどうすればよいでしょうか (同時実行の問題は発生しません)。

注: 私のサービスは C# で記述され、ワー​​カー ロールとして Azure でホストされています。メッセージングには Azure Queues を使用し、ストレージには Mongo を使用することを考えています。また、エンティティ ID はGUID.

それはテクニック/デザインに関するものなので、問題を解決するために別のツールを使用する場合、私はまだ興味があります.

私は 20 ドル/月を使う必要があります。

DigitalOcean 512MB-1CPU ドロップレットのコストは、それぞれ 5 ドル/月です。2GB-2CPU ドロップレットのコストは月額 20 ドルです。

私は一緒に行くべきかどうか疑問に思っています：

• 1 つのフロント プロキシ + 2 つのアプリ サーバー + 1 つの DB サーバー それぞれ 512 MB
• 2GB + 2CPU のサーバー 1 台?

どちらがより良いパフォーマンスを出力しますか?