Existe-t-il des sites Web de commerce électronique qui utilisent des bases de données NoSQL
J'ai lu beaucoup de choses récemment sur les bases de données "NoSQL" telles que CouchDB, MongoDB, etc. La plupart des sites Web que j'ai vus utiliser sont principalement des sites Web basés sur du texte tels que le New York Times et Source Forge.
Je me demandais si vous pouviez appliquer cela aux sites Web où le paiement est un gros problème. Je pense aux problèmes suivants:
- Dans quelle mesure pouvez-vous sécuriser les données
- Ces systèmes fournissent-ils un machanisme de sauvegarde/restauration facile
- Comment les transactions sont-elles gérées?
J'ai lu les articles suivants qui couvrent certains aspects:
- Puis-je faire des transactions et des verrous dans CouchDB?
- Avantages/inconvénients de la base de données basée sur les documents vs base de données relationnelle
Dans ces messages, l'aspect des transactions est couvert. Cependant, les questions de sécurité et de sauvegarde ne sont pas couvertes. Quelqu'un peut-il éclairer ce sujet?
Et si possible, quelqu'un connaît-il certains sites Web de commerce électronique qui ont réussi à mettre en œuvre la base de données basée sur des documents.
EDIT: mars 2013
J'avais initialement publié un lien vers un article que j'ai écrit sur MongoDB et le commerce électronique, mais je ne suis plus d'accord avec tous les points que j'ai soulevés là-bas. Je crois toujours que le modèle de données documentaires de MongoDB peut très bien fonctionner pour la gestion de catalogue d'un site de commerce électronique et peut-être pour les paniers d'achat. Mais il y a clairement des cas où les transactions sont importantes, et MongoDB ne vous les donne pas. La réponse à cette question avec le nombre de votes le plus élevé suivant mérite beaucoup de points.
Voici l'article original pour les personnes intéressées:
http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (lien archive.org)
Le surcoût qui rend les SGBDR si lents, garantit l'atomicité, la cohérence, l'isolement, la durabilité, également connu sous le nom de ACIDE . Certaines de ces propriétés sont assez critiques pour les applications qui traitent de l'argent. Vous ne voulez pas perdre une seule commande lorsque les lumières s'éteignent.
Les bases de données NoSQL sacrifient généralement une partie ou la totalité des propriétés ACID en échange d'une surcharge considérablement réduite. Pour de nombreuses applications, c'est très bien - si quelques "diggs" disparaissent lorsque les lumières s'éteignent, ce n'est pas grave.
Pour un site de commerce électronique, vous devez vous demander ce dont vous avez vraiment besoin.
- Avez-vous vraiment besoin d'un niveau de performance qu'un SGBDR ne peut pas offrir?
- Avez-vous besoin de la fiabilité offerte par un SGBDR?
Honnêtement, la réponse à # 2 est probablement "oui", ce qui exclut la plupart des solutions NoSQL. Et à moins que vous n'ayez affaire à des niveaux de trafic comparables à ceux d'Amazon.com, un RDBM, même sur un matériel modeste, satisfera probablement très bien vos besoins de performances, surtout si vous vous limitez à de simples requêtes et indexez correctement. Ce qui rend la réponse au n ° 1 "non".
Vous pourriez cependant, envisager d'utiliser un SGBDR pour les données de transaction et une base de données NoSQL pour les données non critiques, comme les pages produits, les avis des utilisateurs, etc. Mais alors vous auriez deux fois plus de logiciels de banque de données à installer, et toutes les relations entre les données des deux banques de données devraient être gérées dans le code - il n'y aurait pas de JOIN votre base de données NoSQL contre votre SGBDR. Cela entraînerait probablement un niveau de complexité inutile.
En fin de compte, si un SGBDR offre des fonctionnalités dont vous avez besoin pour la fiabilité et qu'il fonctionne de manière acceptable pour les types de charge que vous rencontrerez, un SGBDR est probablement le meilleur pari.
La gestion des informations financières est l'un des domaines où SQL est vraiment le bon outil pour le travail. La plupart des systèmes NOSQL ont été conçus pour améliorer l'évolutivité en acceptant un risque plus élevé de perte ou d'incohérence des données. Ils ont également tendance à avoir des capacités limitées pour exécuter des rapports sur tous les enregistrements, car sur un grand site Web typique, vous n'avez besoin que de suffisamment de données dans l'index pour rechercher et afficher un seul enregistrement - le reste peut être complètement inaccessible jusqu'à ce que vous connaissiez l'enregistrement que vous recherchez. pour.
Lorsque vous traitez avec de l'argent, toute incohérence des données est un gros problème, et si vous avez besoin de plus d'évolutivité qu'un seul serveur sql peut vous donner, vous avez suffisamment d'argent pour vous permettre le coût plus élevé de la mise à l'échelle sql. De plus, les rapports ad-hoc disponibles à partir de sql sont quelque chose qui vous manquerait si vous n'utilisez pas sql - à peu près toutes les informations que vous voulez sur l'historique des ventes sont triviales à obtenir à partir de sql, mais nécessitent potentiellement du code personnalisé complexe à partir d'un objet basé sur boutique.
Je ne pense pas que la sécurité serait différente sur une base de données NoSQL ou sur une base de données relationnelle. Au final, la sécurité est une question orthogonale sur la façon dont les données sont réellement stockées. En outre, ce n'est pas comme si vous autorisiez l'accès à la base de données à partir de tout sauf de vos serveurs de couche entreprise d'un point de vue réseau.
En ce qui concerne les sauvegardes, la plupart des bases de données NoSQL que je connais autorisent les sauvegardes à chaud, tout comme une base de données régulière.
La vraie question, IMO, est de savoir si vous pouvez vivre avec les restrictions qu'une base de données NoSQL vous impose - en particulier, le manque général de requêtes ad hoc. Par exemple, si vous avez toujours voulu connaître toutes les personnes qui ont déjà acheté le produit "X", vous devez créer dans votre couche d'accès aux données un compteur pour cela dès le premier jour (ou exécuter un très cher recherche en série de chaque transaction passée). Dans une base de données SQL standard, vous pouvez simplement ajouter un index et effectuer une requête et vous avez terminé (ou même, n'ajoutez pas d'index s'il s'agit d'un élément unique). Ou peut-être que vous voulez découvrir toutes les personnes qui ont acheté le produit "Y" avant la sortie de la dernière version (afin que vous puissiez leur envoyer un rappel de mise à niveau ou autre): encore une fois, vous devez planifier cela à l'avance avec une base de données NoSQL, mais c'est trivial avec une base de données relationnelle.
Je pense que cela a du sens quand vous pouvez planifier votre schéma et votre modèle d'utilisation à l'avance, et où une nouvelle analyse occasionnelle des enregistrements pour ajouter un nouveau champ ou une nouvelle métrique est acceptable. Mais pour un site Web de commerce électronique, je pense que les requêtes ad hoc sont tout simplement trop précieuses pour être perdues. Bien sûr, c'est juste mon opinion, et il n'y a certainement aucune raison pour laquelle vous ne pouvez pas mélanger des parties de l'application entre les deux bases de données. J'aimerais personnellement choisir une base de données relationnelle avec memcached entre les deux pour des performances supplémentaires, bien que ...
Gilt.com utilise Voldemort pour gérer le panier/l'inventaire sous une charge énorme. Voir cette présentation de Londres QCon 2010 sur les détails - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe
Je réitérerais également le fait que "NoSQL" ne signifie pas "pas de SQL", mais "pas seulement SQL", et qu'au lieu de regarder n'importe quelle technologie pour un rip/remplacement complet de toute autre, vous devriez chercher le meilleur outil pour le travail. Les magasins de données NoSQL ne font pas de très bons entrepôts de données et ne sont probablement pas appropriés pour stocker les transactions des utilisateurs, mais ils sont très bons dans certains créneaux - voir l'exemple de Gilt Groupe ci-dessus.
Un autre exemple frappant est la page d'accueil de la BBC - pas transactionnelle, mais néanmoins intéressante. Ils utilisent CouchDB pour stocker les préférences de l'utilisateur. Malheureusement, ils semblent s'être écrasés sous la charge.
[MISE À JOUR: Je peux également confirmer que ASOS Marketplace utilise certains composants NoSQL - http://bagcheck.com/bag/9206-asos-marketplace-technology ]
Vous devriez vérifier ceci:
Accusé de réception de réplication via getlasterror
MongoDB est sur le point de fournir des écritures durables. Je pense que c'est le principal problème avec les gens qui discutent de ce sujet w.r.t. argent. La partie transactionnelle est moins importante en raison des fonctionnalités du document imbriqué.
Voici un tas d'applications Web commerciales qui utilisent MongoDB , qui est l'une des bases de données NoSQL les plus populaires.
http://www.mongodb.org/display/DOCS/Production+Deployments
Ce ne sont pas exactement des sites de commerce électronique en soi, mais beaucoup sont des aspects basés sur NoSQL dont les entreprises dépendent. Je peux confirmer que ChatPast est entièrement fait sur MongoDB. Nous faisons du commerce électronique, mais cela est déchargé sur Chargify pour des raisons de sécurité/traitement plutôt que d'avoir peur de faire du commerce sur MongoDB.
Oui, http://myestoreapp.com utilise MongoDB pour tout. Vérifiez-le; n'hésitez pas à répondre à toutes vos questions.