Existe-t-il des sites Web de commerce électronique utilisant des bases de données NoSQL?

Question

J'ai beaucoup lu ces derniers temps à propos de "NoSQL" les bases de données telles que CouchDB, MongoDB, etc. La plupart des sites que j'ai vu à l'aide de ce sont principalement basées sur le texte des sites web tels que Le New York Times et de Source forge.

Je me demandais si vous pourriez l'appliquer à des sites web où le paiement est un énorme problème. Je pense aux questions suivantes:

• Comment pouvez-vous obtenir les données
• Ces système d'offrir une solution simple de sauvegarde/restauration machanism
• Comment les transactions sont traitées commit/rollback

J'ai lu les articles suivants abordent certains aspects:

• Puis-je faire des transactions et des verrous dans CouchDB?
• Avantages/Inconvénients de document de la base de données vs base de données relationnelle

Dans ces emplois, l'aspect des transactions couvertes. Toutefois, les questions de la sécurité et des sauvegardes n'est pas couvert. Quelqu'un peut-il éclairer sur ce sujet?

Et si possible, personne ne sait de certains sites de e-commerce qui ont mis en œuvre avec succès le document de base de données.

Answer 1

EDIT: Mars 2013

J'avais posté un lien vers un article que j'ai écrit sur MongoDB et e-commerce, mais je n'ai plus d'accord avec tous les points que j'ai faites là-bas. Je persiste à croire que MongoDB document du modèle de données peut fonctionner très bien pour le catalogue de la gestion d'un site e-commerce et peut-être pour des caddies. Mais il y a évidemment des cas où les transactions sont importantes, et MongoDB ne vous donne pas ces. La réponse à cette question à la prochaine plus grand nombre de voix fait beaucoup de points à considérer.

Voici l'article original pour ceux qui sont intéressés:

http://kylebanker.com/blog/2010/04/30/mongodb-and-ecommerce/ (archive.org lien)

Answer 2

Les frais généraux qui rend SGBDR est si lent, est de garantir l'atomicité, cohérence, isolation, durabilité, également connu comme l'ACIDE. Certaines de ces propriétés sont assez critiques pour les applications qui traitent avec de l'argent. Vous ne voulez pas perdre une seule commande quand les lumières s'éteignent.

Les bases de données NoSQL généralement sacrifice de certaines ou de toutes les propriétés ACID en retour fortement réduit les frais généraux. Pour de nombreuses applications, c'est bien, -- si quelques "diggs" disparaissent quand les lumières s'éteignent, c'est pas une grosse affaire.

Pour un site de commerce électronique, vous devez vous demander ce que vous avez vraiment besoin.

1. Avez-vous vraiment besoin d'un niveau de performance qu'un SGBDR ne pouvez pas livrer?
2. Vous avez besoin de la fiabilité d'un SGBDR?

Honnêtement, la réponse à la n ° 2 est probablement "oui", ce qui exclut la plupart des solutions NoSQL. Et à moins que vous avez à traiter avec des niveaux de trafic comparable à amazon.com's, un Sgbdr, même sur du matériel modeste sera probablement répondre à vos besoins de performances très bien, surtout si vous vous limitez à des requêtes simples et d'indexer correctement. Ce qui rend la réponse à #1 "non".

Vous pourriez cependant, envisager l'utilisation d'un SGBD pour les données de la transaction, et une base de données NoSQL pour les données non essentielles, comme les pages produits, avis des utilisateurs, etc. Mais on aurait alors deux fois plus de magasin de données, installation de logiciels, et les relations entre les données dans les deux banques de données devrait être géré dans le code, il n'y aurait pas de Joindre à votre base de données NoSQL à l'encontre de votre SGBDR. Cela donnerait probablement lieu à une complexité inutile.

En fin de compte, si un SGBDR offre des caractéristiques que vous devez avoir pour la fiabilité, et il effectue de manière acceptable pour le type de charge que vous allez être confronté, un SGBDR est probablement le meilleur pari.

Answer 3

La manipulation de l'information financière 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 de données ou d'incohérence. Ils ont aussi tendance à avoir des capacités limitées pour exécuter des rapports sur tous les records, puisque sur un grand site web, vous avez seulement besoin de suffisamment de données dans l'index pour trouver et afficher un enregistrement unique - le reste peut être complètement inaccessible jusqu'à ce que vous savez de l'enregistrement que vous recherchez.

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é que d'une seule sql server peut vous donner, vous avez assez d'argent que vous pouvez vous permettre le coût élevé de la mise à l'échelle sql. Aussi, les rapports ad hoc disponible à partir de sql est quelque chose qui vous manquer si vous ne l'utilisez pas sql - à peu près toutes les informations que vous voulez sur les ventes de l'histoire est facile à obtenir à partir de sql, mais potentiellement complexes nécessite des code personnalisé à partir d'un objet en fonction du magasin.

Answer 4

Je ne pense pas que la sécurité serait différent sur une base de données NoSQL que sur une base de données relationnelle. En fin de compte, la sécurité n'est orthogonale de la question de la façon dont les données sont enregistrées. En outre, il n'est pas comme vous le feriez pour permettre l'accès à la base de données à partir de rien, mais votre entreprise-de la couche de serveurs à partir d'une mise en réseau de point de vue.

Pour les sauvegardes, la plupart des bases de données NoSQL que je sais de permettre des sauvegardes à chaud, juste comme une base de données classique.

La vraie question, OMI, est de savoir si vous pouvez vivre avec les restrictions qu'une base de données NoSQL met sur vous - en particulier, le manque général de requêtes ad-hoc. Par exemple, si vous avez toujours voulu savoir toutes les personnes qui ont déjà acheté un produit "X", alors vous auriez à construire votre couche d'accès aux données d'un compteur pour que dès le premier jour (ou exécuter un très cher série de recherche de chaque transaction). Dans une base de données SQL, vous pouvez simplement ajouter un index et de faire une requête et que vous avez fait (ou même, de ne pas ajouter un index si c'est un one-off). Ou peut-être vous voulez trouver toutes les personnes qui ont acheté le produit "Y" avant que la dernière version est sorti (de sorte que vous pouvez leur envoyer un rappel de mise à jour ou quoi que ce soit): encore une fois, vous devez planifier à l'avance avec une base de données NoSQL, mais il est trivial avec une base de données relationnelle.

Je pense que cela fait sens quand vous pouvez planifier votre schéma et votre modèle d'utilisation de l'avance de temps, et où l'occasionnel re-scanner de documents à ajouter quelques nouvelles du champ de mesure est acceptable. Mais pour un site e-commerce, je pense que les requêtes ad-hoc sont tout simplement trop précieux d'une fonction à perdre. Bien sûr, c'est juste mon avis, et il n'y a certainement aucune raison pourquoi vous ne pourriez pas mix-n-match des parties de la demande entre les deux bases de données. J'avais personnellement choisir une base de données relationnelle avec memcached dans entre pour une performance accrue, bien que...

Answer 5

Vous devriez vérifier ceci:

Réception de la 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 par rapport à l’argent. La partie transactionnelle est moins importante en raison des fonctionnalités de document imbriquées.