NoSQLデータベースを使用するeコマースWebサイトはありますか
最近、CouchDB、MongoDBなどの「NoSQL」データベースについて多くのことを読みました。これを使用して見たWebサイトのほとんどは、主にThe New York TimesやSource forgeなどのテキストベースのWebサイトです。
支払いが大きな問題であるウェブサイトにこれを適用できるかどうか疑問に思っていました。次の問題を考えています。
- データをどれだけ安全に保護できますか
- これらのシステムは、簡単なバックアップ/復元メカニズムを提供しますか
- トランザクションのコミット/ロールバックの処理方法
いくつかの側面をカバーする以下の記事を読みました。
これらの投稿では、カバーされている場合のトランザクションの側面を説明しています。ただし、セキュリティとバックアップの問題はカバーされていません。誰かがこのテーマに光を当てることはできますか？
また、可能であれば、ドキュメントベースのデータベースを正常に実装したeコマースWebサイトを知っている人はいますか。
編集：2013年3月
私はもともとMongoDBとeコマースで書いた記事へのリンクを投稿していましたが、私はそこで行ったすべてのポイントに同意しなくなりました。 MongoDBのドキュメントデータモデルは、eコマースサイトのカタログ管理側やショッピングカートで非常にうまく機能すると信じています。しかし、トランザクションが重要な場合は明らかにあり、MongoDBはこれらを提供しません。投票数が次に多いこの質問に対する答えは、多くのポイントを考慮する価値があります。
興味のある人向けのオリジナル記事は次のとおりです。
http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/（archive.orgリンク）
RDBMSを非常に遅くするオーバーヘッドは、 [〜＃〜] acid [〜＃〜] としても知られる原子性、一貫性、分離、耐久性を保証します。これらのプロパティのいくつかは、お金を扱うアプリケーションにとって非常に重要です。ライトが消えたときに1つの注文を失いたくありません。
NoSQLデータベースは通常、オーバーヘッドを大幅に削減する代わりに、ACIDプロパティの一部またはすべてを犠牲にします。多くのアプリケーションでは、これは問題ありません。ライトが消えたときにいくつかの「掘り」が行方不明になっても、大したことではありません。
Eコマースサイトの場合、本当に必要なものを自問する必要があります。
- RDBMSでは実現できないレベルのパフォーマンスが本当に必要ですか？
- RDBMSが提供する信頼性が必要ですか？
正直なところ、2番目の答えはおそらく「はい」であり、ほとんどのNoSQLソリューションは除外されています。 Amazon.comに匹敵するトラフィックレベルを処理している場合を除き、RDBMは、控えめなハードウェアであっても、おそらく単純なクエリに制限し、適切にインデックスを作成する場合、パフォーマンスニーズを十分に満たすでしょう。 ＃1の答えは「いいえ」になります。
ただし、could、トランザクションデータにはRDBMSを使用し、製品ページ、ユーザーレビューなどの重要でないデータにはNoSQLデータベースを使用することを検討してください。 2倍のデータストアソフトウェアをインストールする必要があり、2つのデータストア内のデータ間の関係はコードで管理する必要があります。NoSQLデータベースをRDBMSに結合する必要はありません。これにより、不必要なレベルの複雑さが生じる可能性があります。
最終的に、RDBMSが信頼性のために必要な機能を提供し、発生する負荷の種類に対して許容可能なパフォーマンスを発揮する場合、RDBMSがおそらく最善の策です。
財務情報の処理は、SQLがジョブに最適なツールである領域の1つです。 NOSQLシステムのほとんどは、データ損失や不整合のリスクを高めることにより、スケーラビリティを改善するように設計されています。また、一般的な大規模なWebサイトでは、単一のレコードを検索して表示するために必要なデータがインデックスに必要なだけであるため、すべてのレコードに対してレポートを実行する機能が制限される傾向があります。にとって。
お金を扱う場合、データの不整合は大きな問題であり、単一のSQLサーバーが提供できる以上のスケーラビリティが必要な場合は、SQLをスケーリングするための高いコストに見合う十分なお金があります。また、SQLから利用できるアドホックレポートは、SQLを使用しないと見逃しがちです。販売履歴に関する情報はほとんどSQLから取得するのは簡単ですが、オブジェクトベースの複雑なカスタムコードが必要になる可能性があります。お店。
NoSQLデータベースのセキュリティは、リレーショナルデータベースのセキュリティと異なるとは思いません。結局のところ、セキュリティは、データが実際にどのように保存されるかという直交的な問題です。それに、ネットワークの観点からはビジネス層のサーバー以外からデータベースへのアクセスを許可するのとは異なります。
バックアップに関しては、私が知っているほとんどのNoSQLデータベースでは、通常のデータベースと同様にホットバックアップが可能です。
本当の質問、IMOは、NoSQLデータベースが課している制限、特にアドホッククエリの一般的な不足に耐えられるかどうかです。たとえば、製品 "X"を購入したすべてのユーザーを知りたい場合は、データアクセスレイヤーに1日目からカウンターを構築する必要があります（または非常に高価過去のすべてのトランザクションのシリアルルックアップ）。通常のSQLデータベースでは、インデックスを追加してクエリを実行するだけで完了です（1回限りのインデックスは追加しないでください）。または、最新バージョンがリリースされる前に製品「Y」を購入したすべてのユーザーを検索することもできます（したがって、アップグレードなどのリマインダーを送信できます）。再び、NoSQLデータベースを使用して事前に計画する必要がありますが、リレーショナルデータベースでは簡単です。
スキーマと使用パターンを事前に計画でき、新しいフィールドまたはメトリックを追加するためにレコードをときどき再スキャンすることが許容される場合、それは理にかなっていると思います。しかし、eコマースWebサイトの場合、アドホッククエリは価値がありすぎて失われない機能だと思います。もちろん、それは私の意見です。2つのデータベース間でアプリケーションの一部を混在させることができなかった理由は確かにありません。 個人的にパフォーマンスを向上させるために、memcachedを使用したリレーショナルデータベースを選択しますが...
Gilt.comはVoldemortを使用して、膨大な負荷の下でバスケット/在庫を処理します。詳細については、ロンドンQCon 2010のこのプレゼンテーションを参照してください- http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe
また、「NoSQL」は「SQLなし」ではなく「SQLのみ」を意味するわけではなく、他の技術を完全にリッピング/置換するためのテクノロジーを検討する代わりに、最高のものを検討する必要があることを繰り返します。仕事のためのツール。 NoSQLデータストアは、非常に優れたデータウェアハウスを作成せず、ユーザートランザクションの保存にはおそらく適切ではありませんが、特定のニッチ領域では非常に優れています-上記のGilt Groupeの例を参照してください。
別の顕著な例はBBCホームページです-トランザクションではありませんが、それでも興味深いです。 CouchDBを使用してユーザー設定を保存します。残念ながら、彼らは負荷の下でクラッシュしたようです。
[更新：ASOS MarketplaceがいくつかのNoSQLコンポーネントを使用していることも確認できます- http://bagcheck.com/bag/9206-asos-marketplace-technology ]
あなたはこれをチェックアウトする必要があります：
MongoDBは、永続的な書き込みを提供しようとしています。それがこのトピックを議論する人々の主な問題だと思います。お金。ネストされたドキュメント機能のため、トランザクション部分はそれほど重要ではありません。
MongoDB を使用する多数の商用Webアプリケーションを次に示します。これは、より一般的なNoSQLデータベースの1つです。
http://www.mongodb.org/display/DOCS/Production+Deployments
それは、それ自体が電子商取引サイトそのものではありませんが、多くは、企業が依存しているNoSQLを活用した側面です。 ChatPast が完全にMongoDBで行われていることを確認できます。 eコマースを行いますが、MongoDBでコマースを行うことを恐れるのではなく、セキュリティ/処理の懸念により、 Chargify にオフロードされます。
はい、 http://myestoreapp.com はすべてにMongoDBを使用します。見てみな;どんな質問でも気軽に撮影してください。