2

CouchDB や MongoDB などの NoSQL の使用に関するミニブックをいくつか読みました (後者の方がよく知っています)。

パフォーマンス、特にスケーリングの観点から、より適切なものは次のとおりです。

  1. 必要に応じて個別のサーバーでホストされる個々の DB
  2. シャーディングを使用して分割された単一の MongoDB

マスター/スレーブなどの SQL スケーリング手法は省略しました (これは、サーバーの規模を超えるアプリケーションで SQL をスケーリングする方法であると理解しています)。

私のアプリケーションの各「アカウント」は、個人的な使用のみを目的としており、非常識なサイズやアクセスにまで成長することはありません。したがって、アプリケーションを 1 つまたは数台のサーバーでホストし、必要に応じてデータを 1 つまたは複数のサーバーに分散させることができると考えています。1 つの SQL がタップアウトされると、DB の半分 (使用量に比例して言えば) を別のサーバー (リモートかどうかに関係なく) に再配置します。理論的には、これによりパフォーマンスが向上し、わずかな労力で多少のスケーリングが可能になるはずです???

あるいは、NoSQL ソリューションでの共有は非常に簡単に思えます - 唯一の副作用は、すべてのレコードを単一のデータベースに保持する必要があることです - 個々のセキュリティがわずかに低下します - 理論的には?

この問題に関するあなたの経験/意見は何ですか?

よろしく、アレックス

4

1 に答える 1

3

この質問は少しややこしいです。2 つの異なるスケーラビリティ アプローチのパフォーマンス特性について質問しています...これは、2 つのスケーラビリティ アプローチがかなり同等であると仮定していますが、そうではありません。

あなたがここで質問したアプローチは 2 つあります。標準的な用語を使用して説明します。これらは NoSQL 固有のものではなく、実際にあらゆるテクノロジーに適用されます。

非常に大規模な単一サーバーである垂直スケーリング。

多数の小規模なサーバーがクラスター化された水平スケーリング。

これら 2 つのソリューションは、本質的に異なります。水平スケーリングにより、一貫した小さなコストで容量を徐々に追加できます。垂直方向のスケーリングには、単一のサーバーの容量がいっぱいになるたびに、非常に大きなコストがかかります。他のすべてのことはさておき、アーキテクトがスケーリングに使用するアプローチが水平スケーリングであるのは、通常、この要因のためです。Google は、90 年代後半にこのアプローチの実行可能性を証明しました。

MongoDB やその他の NoSQL ソリューションでは、このアプローチを使用してスケーラビリティを実現しています。MongoDB ではシャーディングと呼ばれます。次に、パフォーマンス特性について説明します。垂直アプローチでは、最終的に容量が増大するのは、この 1 台のマシン自体が実際には一連のクラスター化されたコンポーネントであるということです。巨大なハード ドライブ アレイ、マザーボード、CPU、RAM のアレイ。実際に使用するハードウェアと環境に大きく依存するため、この 2 つを対比することは不可能です。ただし、1つのことは明らかです。同様のパフォーマンスを達成するには、水平アプローチの方がコストがかからず、複雑さもありません。

水平アプローチにもいくつかの利点があります。いくつかの自然な制限は、単一のマシンで発生しますが、負荷を多くのマシンに分割することで回避できます。

最後に、補足として、マスター/スレーブはスケーリングに使用されません。より多くの読み取り容量を提供するために、すべての書き込みを倍増させます。これは、ノードを追加するたびに得られるメリットが少なくなることを意味します。読み取り容量をわずかに増やすことができますが、スケーリングではなく、高可用性を目的としています。

于 2012-04-10T19:31:27.893 に答える