0

Web ショップの典型的な製品カタログには、どのテクノロジが適しているかを考えています。私はエンタープライズ環境での nosql に関する修士論文を書いており、長い間ドキュメント ストアに焦点を当てていたと思います。何千もの異なる製品をモデル化するために必要な柔軟性のために、ドキュメント ストアを推奨する記事をたくさん読んでください。しかし、私が今知る限り、Cassandra のようなカラム ファミリー ストアは同じ柔軟性を提供します。

私がcassandraを使用するアイデアの中で最も気に入っているのは、nosql-database.orgがそれについて述べていることです（最も興味深い機能をマークしています）：

大規模なスケーラビリティ、パーティション化された行ストア、マスターレス アーキテクチャ、リニア スケールのパフォーマンス、単一障害点なし、複数のデータ センターとクラウド アベイラビリティ ゾーンにわたる読み取り/書き込みサポート。API / クエリ方法: CQL および Thrift、レプリケーション: ピアツーピア、記述言語: Java、並行性:調整可能な一貫性、その他: 組み込みデータ圧縮、MapReduce サポート、プライマリ/セカンダリ インデックス、セキュリティ機能。

最後に、セッション用の K/V ストア、製品カタログ用のドキュメント ストアまたは列ファミリ ストア、および在庫/価格設定用の RDBMS など、ポリグロットの永続性を利用する、可用性が高くスケーラブルなマルチショップ システムのプロトタイプの構築に焦点を当てます。 Sadalage と Fowler は、著書「NoSQL Destilled」で言及しています。

可能であれば、科学論文またはその他の信頼できる情報源を回答に提供してください。

ありがとう！

4

2 に答える 2

3

ドキュメントストアのアキレス腱

Stuart Hallowayは、ドキュメント ストアは柔軟性に欠ける最大のスキーマ ロック ソリューションであると述べましたが、私もこれに同意します。Couch/Mongo などは、セカンダリ インデックスを作成するための回避策、単純なオブジェクト ID を認識する機能と必要性などを提供することで、それを軽減しようとします。もちろん、バージョン管理について考える場合 (つまり、システムに「時間」変数を追加する場合) 、ドキュメント ストアはスムーズなサポートとタイム トラベルをすぐに提供できなくなります。

列ストア: 問題の関連性

Cassandra は、AWS で 500 の Cassandra ノードを数分間立ち上げることができ、すべてのリクエストが Cassandra リングにヒットする Netflix などの実際の例を使用して、「スケーラブル」/「分散型」システムを構築するための非常に魅力的なソリューションです。

ただし、質問に記載されている問題を考えると、Cassandraは不必要なやり過ぎです。「その他」よりも少し複雑である、または列指向のストアの上にしっかりしたデータモデルを作成するのが精神的に難しいという理由だけでなく、「製品カタログ」の問題がロケット科学ではないためでもあります. 機械学習を後で予測/認識などに追加したい場合は可能ですが、カタログ自体はそうではなく、たとえばPostgreSQLなどのより単純なストアで簡単に解決できます。

NoSQL への単純な欲求

製品カタログに NoSQL を本当に使用したい場合は、プロトタイプに適合する 3 つのソリューションを検討します。

  • 「セッションの K/V」としてのRiak
  • 「商品カタログ・在庫・価格」を解決するDatomic
  • 問題のサイズと性質、および最終的な解決策に応じて、Datomic をストレージ サービスとして Riak の上に快適に配置しながら、これらのセッションをRedisにキャッシュすることを検討します。

実践と理論

NoSQL を実際に初めて現実のものにした 2 つの古典的な NoSQL 論文は、DynamoとBigTableです。Datomic は、スキーマ ロックのない真の指標と関係を備えたハイブリッド データ モデルを導入することで、DB ユニバースの次の進化的ステップであると考えています。

実際には、修士論文でなければ、実際の問題の規模と定義に応じて、カタログ、在庫、価格設定などを解決するために、Datomic と PostreSQL のどちらかを選択することになります。

  • ここでの Datomic の大きな利点はタイムトラベルです。実際には、「ショッピング システム」でそれを安全かつ簡単に実行できることが非常に重要です。

  • PostgreSQL の大きな利点は、使い慣れていることと、分析とレポート作成のための SQL ツールを利用できることです。

于 2013-06-12T14:39:35.227 に答える
3

今のところ、Column-Family Stores は製品のカタログにはあまり適していないと思います。これは、製品にタグ、音楽レコードのトラックリスト、服のさまざまなサイズなどのコレクションが含まれていることが多いためです。

Cassandraは現在コレクションをサポートしていますが、検索はできません! これは、たとえばタグには必須の機能です。対照的に、たとえばMongoDbは、ネストされた配列を検索するための$in演算子を提供しています...

Cassandra で製品カタログをモデル化できないとは言いたくありませんが、ドキュメント ストアでモデル化する方がはるかに簡単だと思います。

于 2013-07-25T08:25:00.263 に答える