mongodb - sentencias - nosql pdf

¿Hay sitios web de comercio electrónico que usen bases de datos NoSQL (8)

Últimamente he leído mucho sobre bases de datos ''NoSQL'' como CouchDB, MongoDB, etc. La mayoría de los sitios web que he visto utilizar son principalmente sitios web basados en texto, como The New York Times y Source forge.

Me preguntaba si podría aplicar esto a sitios web donde el pago es un gran problema. Estoy pensando en los siguientes problemas:

¿Qué tan bien puede proteger los datos?
¿Ofrecen estos sistemas un mecanismo fácil de copia de seguridad / restauración?
Cómo se manejan las transacciones commit / rollback

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

En estas publicaciones, el aspecto de las transacciones si está 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.

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

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

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

EDITAR: marzo de 2013

Originalmente había publicado un enlace a un artículo que escribí en MongoDB y comercio electrónico, pero ya no estoy 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 aquellos interesados:

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

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.

Gilt.com usa Voldemort para manejar cestas / inventario bajo una gran carga. Vea esta presentación de London QCon 2010 sobre los detalles - http://www.infoq.com/presentations/Project-Voldemort-at-Gilt-Groupe

También me gustaría reiterar el hecho de que "NoSQL" no significa "No SQL", sino "No solo SQL", y que en lugar de buscar en cualquier tecnología una copia completa / reemplazo de cualquier otra, debería estar buscando lo 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 destacado es la página principal 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 puedo confirmar que ASOS Marketplace utiliza algunos componentes NoSQL - http://bagcheck.com/bag/9206-asos-marketplace-technology ]

La sobrecarga que hace que los RDBMS sean tan lentos garantiza la atomicidad, la consistencia, el aislamiento y la durabilidad, también conocida 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 NoSQL 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é necesita realmente.

¿Realmente necesita un nivel de rendimiento que un RDBMS no puede ofrecer?
¿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".

Sin embargo, podría considerar usar un RDBMS para datos de transacciones y una base de datos NoSQL para datos no críticos, como páginas de productos, reseñas de usuarios, etc. Pero entonces tendría el doble de software de instalación de datos y cualquier relación entre el los datos en las dos áreas de almacenamiento de datos tendrían que ser administrados en código; no existiría la INCORPORACIÓN de su base de datos NoSQL en 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.

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", entonces tendrías que incorporar en tu capa de acceso a datos un contador desde el primer día (o ejecutar una búsqueda en serie muy costosa de cada pasado transacción). 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. Yo personalmente elegiría una base de datos relacional con Memcached en el medio para un mayor rendimiento, sin embargo ...

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

Ustedes deberían ver esto:

Reconocimiento de replicación a través de getlasterror

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