1

NDA のため、詳細についてはお話しできませんが、構築中のシステムの概要が、データベースに関する決定を下す際の参考になれば幸いです。

店頭での在庫/購入の記録に基づいて戦略的な提案を行うことで、ベンダーが競争して顧客を獲得するのに役立つアプリを構築しています。

アプリの 1 つの側面は、店舗の所有者が提示されたオファー、ネットワークなどを確認するためのものです。私は標準の php/MySQL セットアップでそれを行っています。

在庫の記録について質問です。私たちはここで数百万のレコードをほぼ即座に話しています. 私が使用しているサンプル データは、1 年または 2 年の間に 4 人のマネージャー (数十人いる) のロールアップであり、約 30 列以上で 50 万行を超えていました。すべてのマネージャーがいる多数の店舗を取得すると、少なくとも私がこれまでに取り組んできたものと比較して、大規模になります.

ベンダーは、これらの記録を検索し、それに基づいて競争力のある提案を行うことができる製品の側面を持っています。

mongo のようなものを使用する十分な理由は、サイズが大きいことですか? それとも、データがどのようにレイアウトされているか、またはデータが何から構成されているかという問題ですか? または、私が考慮していない他の要素ですか？

そして、mongo/nosql ではない場合、そのような大規模なデータ ストアが私が使用することでメリットが得られる他の方法やテクノロジはありますか (シャーディング、Amazon クラウド データベースなど)。

ありがとう

4

1 に答える 1

2

回答..。

Q：サイズが大きいので、mongoのようなものを使用するのは良い理由ですか？

A：そう思います。Mongoは、大規模な方法でゼロからスケールアップして構築されました。スケーリングに役立つレプリカセットとシャーディングがあります。また、地理的に適切に分散されたデータセンターにデータを確実に保存する機能もあります。

Q：それとも、データがどのように配置されているか/データが何で構成されているかという問題ですか？

A：Mongoはドキュメントデータベースです。その通り、データモデルは異なります。データは、正規化ではなく非正規化された方法で考える必要があります。他のテクノロジーと同じように、ドキュメントとして物事を保存することには賛否両論があります。

いくつかの長所：スキーマ管理は簡単です。データは、アプリケーション内のオブジェクトにより自然に適合します。複雑な/遅い結合の代償を払う必要はありません。

いくつかの短所：スキーマに一貫性がない可能性があります-スキーマを管理する必要があります。データが繰り返されますが、これは管理されていないため、データに一貫性がなくなる可能性があります。

一般的に、モンゴはその規模に対処するのに良い選択だと思います。Mongoには、ドキュメントのクエリに多くのSQL概念をもたらす新しい集約フレームワークがあります。複雑なクエリを簡単に作成できます。また、Mongoには、あらゆる種類のクエリを実行するためのmap/reduceがあります。

Mongoを約1年間毎日使用した後、製品としてのMongoのサポートと、Mongoのセットアップと操作の一般的な使いやすさを本当に楽しんでいます。

于 2013-03-03T22:07:58.493 に答える