タグ付けされた質問 「sharding」

ユースケースを考えます： テナントデータはクロストークしてはいけません。あるテナントは別のテナントのデータを必要としません。 各テナントには、大量の履歴データが潜在的に含まれている可能性があります。 SQL ServerはAWS EC2インスタンスでホストされます。 各テナントは地理的に離れています。 PowerBI Embeddedなどのサードパーティの視覚化ツールを使用する意図があります。 データ量は時間とともに増加すると予想されます システムのコストには制約があります。 ソリューションは、24時間365日の実稼働DBAなしで保守可能でなければなりません。 ソリューションは水平方向にスケーリングできる必要があります。 テナントの総数は50未満です 推奨されるアーキテクチャは何ですか？このユースケースのリファレンス実装はありますか？多くの人がエンタープライズソフトウェア開発のためにすでにこの問題に直面していると思います。 これは、マルチテナントデータベースアーキテクチャで増加するテナントの処理とは異なる状況だと思います。その質問で言及されているユースケースは、より多くのテナントを扱っていますが、これは非常に少数の大きなテナントを持つこととは非常に異なります。ここで説明したアーキテクチャは、ここで解決策になる可能性があります。これは、私がもっと知りたいことです。

12 sql-server  database-design  sharding  scalability  multi-tenant 

このドキュメントで説明されているベストプラクティスについて質問したいと思います。 http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf 複数のクエリルーターを使用します。複数のサーバーにまたがる複数のmongosプロセスを使用します。一般的な展開は、アプリケーションサーバー上のmongosプロセスを同じ場所に配置することです。これにより、アプリケーションとmongosプロセス間のローカル通信が可能になります。mongosプロセスの適切な数は、アプリケーションと展開の性質によって異なります。 展開についてのほんの少しの背景。多くのアプリケーションサーバーノードがあります。それらはそれぞれ、ステートレスRESTful WSで1つのJVMベースのプロセスを実行します。このベストプラクティスが示唆するように、すべての単一のアプリケーションサーバーノードは独自のmongosプロセスを実行します。つまり、JVMプロセスの数は常にプロセスの数に等しくなりmongosます。 すべてのmongosプロセスは、3つの構成サーバーと複数のmongo断片（各断片内にレプリカセットがある）に接続します。シャード展開を使用している場合でも、実際にはコレクションをシャーディングしていません。実際、作成時にすべてのシャードに分散する多数のデータベースがあります（これが現時点でのシャーディングの主な使用例です）。 ベストプラクティスでは「適切なmongosプロセスの数はアプリケーションとデプロイメントの性質に依存する」ことも示唆しているので、私たちの使用mongosが実際に適切かどうか、または複数の専用mongosノードを用意して、アプリサーバーはmongosローカルで実行せずに接続します。 mongosアプリケーションサーバーのインスタンス数またはMongoDBクラスターのサイズに関連して適切なインスタンスの数を決定するための最適なアプローチについて、あなたはどう思いますか？ 最近、ステートレスWebサービスのクラスター管理を検討し始めました。つまり、Docker、Apache Mesos、Kubernetesなどのツールを意味します。Dockerを使用している場合、一般的にコンテナ内で複数のプロセスを実行することは推奨されません。この事実を考慮すると、アプリケーションサーバーコンテナとmongosコンテナを常に同じ物理ノードに配置し、同じ量のプロセスを確保することは非常に困難になります。これは、このベストプラクティスが今説明したクラスターアーキテクチャにまだ当てはまるのかと思います。そうでない場合は、mongosこのアーキテクチャでプロセスを見つけて展開するためのより良い方法を提案してください。

12 mongodb  best-practices  sharding  deployment  docker 

私はmongodbシャードクラスターを持っていますが、シャードキーはハッシュされています。2つのシャードレプリカセットがあります。各レプリカセットには2つのマシンがあります。 別の2つのシャードレプリカセットを追加して実験を行ったところ、リバランスが開始されました。 ただし、しばらくすると、チャンクの移行がかなり遅くなることがわかりました。1.4GBのデータを移動するのに1時間かかります。 それは私を心配させます、それは私が13日間待って500GBのチャンク移行を完了する必要があることを意味します！ 私はこのことについては初心者であり、それが遅い、速い、または通常であるかどうかについての神の感触はありません。しかし、それでも、それらの数は私を納得させません。 実験に関する追加メモ：-m3中型awsマシンを使用-他のプロセスは実行せず、チャンク移行のみ-デフォルト設定のmongodbシャーディングインストールで追加の設定なし-シャードキーはオブジェクトID（_id）でハッシュを使用-最大チャンクサイズ64MB

9 mongodb  sharding