¿Hay sitios web de comercio electrónico que usen bases de datos NoSQL?

He leído mucho últimamente sobre bases de datos 'NoSQL' como CouchDB, MongoDB, etc. La mayoría de los sitios web que he visto usar son principalmente sitios web basados en texto como The New York Times y Source forge.¿Hay sitios web de comercio electrónico que usen bases de datos NoSQL?

Me preguntaba si podría aplicar esto a los sitios web donde el pago es un gran problema. Me refiero a las siguientes cuestiones:

tan bien puedes asegurar los datos
hacer estas sistema de proporcionar una copia de seguridad fácil/restauración machanism
Cómo se transacciones manejadas comprometen/rollback

he leído los siguientes artículos que cubren algunos aspectos:

En estos puestos el aspecto de las transacciones si cubierto. Sin embargo, las cuestiones de seguridad y copias de seguridad no están cubiertas. ¿Alguien puede arrojar algo de luz sobre este tema?

Y, si es posible, ¿alguien sabe de algunos sitios web de comercio electrónico que han implementado con éxito la base de datos basada en documentos.

Fuente

2010-04-05 Saif Bechan

No es constructivo, con 208 votos acumulados al alza para la pregunta y las respuestas. Felicitaciones, @ Anti-Santa. – SzG

EDIT: marzo de 2013

que había publicado originalmente un enlace a un artículo que escribí en MongoDB y el comercio electrónico, pero ya no estar de acuerdo con todos los puntos que hice allí. Sigo creyendo que el modelo de datos de documentos de MongoDB puede funcionar muy bien para el lado de administración de catálogos de un sitio de comercio electrónico y quizás para los carritos de compra. Pero claramente hay casos en que las transacciones son importantes, y MongoDB no te da esto.La respuesta a esta pregunta con el siguiente número de votos hace que valga la pena considerar muchos puntos.

Aquí está el artículo original para los interesados:

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

Fuente

2010-05-01 14:55:41

+1. Buen articulo. El punto principal es que uno no debe modelar instintivamente la solución como un conjunto de tablas RDBMS, ya que eso conduce a una serie de problemas que solo pueden resolverse mediante un RDBMS. Si en cambio piensa en términos de documentos/objetos, el problema relacionado con ACID simplemente desaparece y está claro que también puede usar una base de datos no SQL para el comercio electrónico. –

Excelente artículo! ¡Gracias! – Matt

@tegiri: Entonces, ¿qué? –

No creo que la seguridad sea diferente en una base de datos NoSQL que en una base de datos relacional. Al final, la seguridad es una pregunta ortogonal sobre cómo se almacenan realmente los datos. Además, no es como si permitiera el acceso a la base de datos de cualquier cosa que no sean los servidores de su capa empresarial desde el punto de vista de la red.

En cuanto a las copias de seguridad, la mayoría de las bases de datos NoSQL que conozco permiten realizar copias de seguridad en caliente, al igual que una base de datos normal.

La verdadera pregunta, IMO, es si puede vivir con las restricciones que le impone una base de datos NoSQL, en particular, la falta general de consultas ad-hoc. Por ejemplo, si alguna vez quisiste conocer a todas las personas que alguna vez compraron el producto "X", tendrías que construir en tu capa de acceso a datos un contador desde el primer día (o ejecutar una muy costosa búsqueda serial de cada transacción pasada). En una base de datos SQL normal, puede simplemente agregar un índice y hacer una consulta y listo (o incluso, no agregar un índice si se trata de una sola vez). O tal vez quiera conocer a todas las personas que compraron el producto "Y" antes de que saliera la última versión (para que les envíe un recordatorio de actualización o lo que sea): nuevamente, debe planificar eso con una base de datos NoSQL, pero es trivial con una base de datos relacional.

Creo que tiene sentido cuando puede planificar su esquema y su patrón de uso con anticipación, y donde la reexploración ocasional de registros para agregar un nuevo campo o métrica es aceptable. Pero para un sitio web de comercio electrónico, creo que las consultas ad-hoc son una característica demasiado valiosa para perder. Por supuesto, esa es solo mi opinión, y ciertamente no hay ninguna razón por la cual no puedas mezclar y combinar partes de la aplicación entre las dos bases de datos. Me gustaría personalmente elegir una base de datos relacional con memcached mientras tanto para un mayor rendimiento, aunque ...

Fuente

2010-04-05 23:29:15

+1 Gracias por los buenos puntos hechos. MySQL y memcached han demostrado su rendimiento y confiabilidad desde hace bastante tiempo. Creo que para los sitios web, esta es la mejor solución por ahora. Una pregunta, ¿qué quiere decir con consultas ad-hoc y por qué nosqq nos falta eso? –

MongoDB ofrece un buen soporte para consultas adhoc y creación adhoc de índices. Sin embargo, creo que debería usar una base de datos ACID para todo lo relacionado con el dinero. – Theo

Varias bases de datos NoSQL proporcionan "vistas" o "índices" que permiten lo que yo llamaría consultas "semi ad-hoc", pero aún no es un sustituto de la capacidad de decir simplemente 'SELECT * FROM usuarios INNER JOIN compras en ... TENIENDO ... ' –

El manejo de la información financiera es una de las áreas donde SQL realmente es la herramienta adecuada para el trabajo. La mayoría de los sistemas NOSQL fueron diseñados para mejorar la escalabilidad al aceptar un mayor riesgo de pérdida de datos o inconsistencia.También tienden a tener capacidades limitadas para ejecutar informes sobre todos los registros, ya que en un sitio web grande típico solo necesita suficientes datos en el índice para buscar y mostrar un solo registro; el resto puede ser completamente inaccesible hasta que sepa el registro que está buscando. para.

Cuando se trata de dinero, cualquier inconsistencia de datos es un gran problema, y si necesita más escalabilidad de la que puede ofrecerle un solo servidor sql, tiene suficiente dinero para poder pagar el mayor costo de escalar sql. Además, los informes ad-hoc disponibles de sql son algo que extrañaría si no utilizara sql: prácticamente toda la información que desee sobre el historial de ventas es trivial obtener de sql, pero posiblemente requiera código personalizado complejo de un objeto basado almacenar.

Fuente

2010-04-05 23:38:08

+1 Creo que la tecnología es demasiado nueva para que un sitio web de comercio electrónico pueda confiar en este sistema. La forma en que usa solo JSON es que el almacenamiento se dispara. Espero que en el futuro este método se pueda utilizar como un método confiable para sitios web impulsados por dinero. Hasta entonces solo me quedaré con MySQL con memcached. –

La novedad de la tecnología no es el problema: estas herramientas están siendo utilizadas por algunos de los sitios más grandes de la red. Sin embargo, la tecnología está diseñada para resolver un conjunto de problemas completamente diferente y probablemente nunca sea la opción más adecuada para trabajar con dinero. –

Ok, lo entiendo.Gracias por señalar eso –

La sobrecarga que hace RDBMS tan lento, garantiza la atomicidad, consistencia, aislamiento, durabilidad, también conocido como ACID. Algunas de estas propiedades son bastante críticas para las aplicaciones que se ocupan del dinero. No quiere perder un solo pedido cuando se apagan las luces.

Las bases de datos No SQL generalmente sacrifican algunas o todas las propiedades ACID a cambio de una sobrecarga severamente reducida. Para muchas aplicaciones, esto está bien; si faltan algunos "diggs" cuando se apagan las luces, no es gran cosa.

Para un sitio de comercio electrónico, debe preguntarse qué es lo que realmente necesita.

¿Realmente necesita un nivel de rendimiento que un RDBMS no puede entregar?
¿Necesita la fiabilidad que proporciona un RDBMS?

Honestamente, la respuesta al # 2 es probablemente "sí", que descarta la mayoría de las soluciones NoSQL. Y a menos que esté lidiando con niveles de tráfico comparables a los de amazon.com, un RDBM, incluso en hardware modesto, probablemente satisfará sus necesidades de rendimiento, especialmente si se limita a consultas simples e indexa correctamente. Lo que hace que la respuesta al # 1 sea "no".

Usted podría sin embargo, considerar el uso de un RDBMS de datos de la transacción, y una base de datos NoSQL para datos no críticos, como las páginas de productos, opiniones de usuarios, etc. Pero entonces tendría el doble de software de almacén de datos para instalar , y cualquier relación entre los datos en las dos áreas de almacenamiento de datos tendría que ser administrada en código; no habría UNIÓN a su base de datos NoSQL contra su RDBMS. Esto probablemente resultaría en un nivel innecesario de complejidad.

Al final, si un RDBMS ofrece características que debe tener para la confiabilidad, y se desempeña de manera aceptable para el tipo de carga que experimentará, un RDBMS es probablemente la mejor opción.

Fuente

2010-04-05 23:56:30

+1 De hecho, al final estaba cuestionando la solución para tener una mezcla como usted indicó. Pero comparta su opinión sobre el nivel innecesario de complejidad. Mantendré tus puntos en mente. –

¿Tiene alguna idea sobre la cantidad de memoria extra que costará tener ambos funcionando? Tal vez sea una buena idea tener el catálogo cargado en mongodb. Deje salir la complejidad, ¿ve algún beneficio importante para esto? –

Saif: no es necesario tener todo en el mismo servidor, por lo que la memoria extra no es un problema. A menos, por supuesto, que solo tenga un servidor :) Acerca de los beneficios, depende de cada aplicación en particular. Si su sitio tiene un montón de solicitudes que no requieren ACID, y solo unas pocas que sí lo requieren, * Y *, si tiene más usuarios de los que un solo RDBMS puede manejar, sin importar el hardware, * O *, si tiene toneladas de usuarios pero quiere ahorrar dinero en el hardware mediante el uso de muchos servidores básicos en lugar de uno enorme, entonces una solución mixta es el camino a seguir. – Cristian

chicos con los que debe comprobar esto:

Replication Acknowledgement via getlasterror

MongoDB está a punto de dar las escrituras duraderos. Creo que ese es el problema principal con las personas que debaten este tema w.r.t. dinero. La parte transaccional es menos importante debido a las características del documento anidado.

Fuente

2010-04-29 23:18:25

+1 para señalar esto. Pero, ¿este "Reconocimiento de replicación" no funciona en contra del "rendimiento" por el que NoSql es tan famoso? ¿Al menos parcialmente para esa transacción en particular? Aunque estoy de acuerdo en que todavía puede usar las partes fáciles de "replicación" y "escalabilidad" de un DB como MongoDB, ¡lo cual es genial! – techexpert

Sí y no. Disminuye el rendimiento para la solicitud de un solo usuario. Por lo tanto, el tiempo real de carga de la página podría degradarse un poco. Pero eso no afecta la velocidad de escalamiento. Si tuviste 1,000 usuarios simultáneos, sospecho que la métrica de páginas/seg no se vería afectada. Por lo tanto, creo que dependerá de lo que quieras decir con velocidad. –

Este enfoque solo funcionará si tiene 1 cliente y todas las solicitudes están sincronizadas, ya que no proporciona atomicidad Imagine tener un hilo que recupera un valor, mientras procesa el valor, otro hilo podría actualizar el mismo valor y replicarlo a todos los servidores antes de que termine el primer subproceso. El primer subproceso luego actualiza la base de datos con el resultado que se calculó en base a datos desactualizados. Esta es una situación que RDBMS maneja a la perfección, para hacer esto en la mayoría de las bases de datos NOSQL tendría que renunciar a la concurrencia y usar algún tipo de bloqueo distribuido. – mikerobi

Gilt.com utiliza Voldemort para manejar la cesta/inventario bajo carga enorme. Vea esta presentación de London QCon 2010 en los detalles - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe

También reitero el hecho de que "NoSQL" no significa "Sin SQL", sino "No solo SQL", y que en lugar de mirar cualquier tecnología para un desgarre/reemplazo completo de cualquier otro, debería estar buscando la mejor herramienta para el trabajo. Los almacenes de datos NoSQL no son muy buenos almacenes de datos, y probablemente no sean apropiados para almacenar transacciones de usuarios, pero son muy buenos en ciertas áreas de nicho - vea el ejemplo anterior de Gilt Groupe.

Otro ejemplo prominente es la página de inicio de la BBC, no transaccional, pero interesante de todos modos. Usan CouchDB para almacenar las preferencias del usuario. Desafortunadamente, parecen haberse estrellado bajo la carga.

[ACTUALIZACIÓN: También puede confirmar que ASOS mercado utiliza algunos componentes NoSQL - http://bagcheck.com/bag/9206-asos-marketplace-technology]

Fuente

2010-06-22 09:19:23

Aquí hay un montón de aplicaciones web comerciales que utilizan MongoDB, que es una de las bases de datos más populares NoSQL.

http://www.mongodb.org/display/DOCS/Production+Deployments

Eso no es exactamente sitios de comercio electrónico en sí, pero muchos son los aspectos que funcionan con NoSQL que las empresas dependen. Puedo confirmar que ChatPast está completamente hecho en MongoDB. Hacemos comercio electrónico pero está descargado al Chargify debido a problemas de seguridad/procesamiento en lugar de tener miedo de hacer comercio en MongoDB.

Fuente

2011-04-07 00:12:39

Sí, http://myestoreapp.com usa MongoDB para todo. Echale un vistazo; Siéntase libre de disparar sobre cualquier pregunta.

Fuente

2011-12-13 19:36:47

¿Hay sitios web de comercio electrónico que usen bases de datos NoSQL?

Respuesta

Cuestiones relacionadas