programacion - mongodb tutorial español
Base de datos NoSQL para comercio electrónico (2)
Dado que el comercio electrónico puede abarcar desde carritos de compra hasta membresías y suscripciones recurrentes, es difícil adivinar exactamente qué requisitos y complejidad está visualizando.
Al construir un sitio de comercio electrónico, una de las primeras consideraciones debería ser investigar si ya existe un producto de comercio electrónico o conjunto de herramientas establecido que pueda cumplir con sus requisitos. Existen muchas sutilezas en procesos como pedidos, facturación, pagos, productos y relaciones con los clientes, incluso cuando su caso de uso parece ser sencillo. También puede ser posible separar su aplicación en los aspectos de "gestión de catálogos" (posiblemente más personalizados) frente a la "facturación" (potencialmente de terceros, tal vez incluso a través de una API alojada de facturación / pago).
Otra consideración debe ser para quién está desarrollando el sitio de comercio electrónico: ¿se trata de arañar su propia picazón o de un cliente? El tiempo, el presupuesto y las características para una construcción personalizada pueden ser difíciles de estimar y programar ... y una elección de tecnología de nicho puede dificultar la búsqueda / contratación de experiencia en desarrollo adicional.
Una tercera consideración es cuál es su (s) idioma (s) de elección para desarrollar su aplicación. Algunos idiomas tendrán controladores más completos / maduros / documentados y / o abstracciones del marco para las diferentes bases de datos.
Dicho esto, escribir un sistema de comercio electrónico parece ser un rito de iniciación para muchos desarrolladores ;-).
Para MongoDB en particular, es posible que desee investigar:
Delantero : una nueva plataforma de comercio electrónico de código abierto que utiliza MongoDB (con la intención declarada de admitir otras bases de datos). Actualmente se describe como "beta privada" pero parece que vale la pena investigar (y aparentemente ya se usa para algunos sitios en vivo). Noté que se mencionó recientemente en el blog de MongoDB: Cómo MongoDB facilita el comercio electrónico personalizado .
MongoDB y E-Commerce : una publicación de blog de Kyle Banker, autor del libro de Manning MongoDB en acción . Tiene algunos años, pero tiene una discusión interesante sobre consideraciones de modelado de datos; también hubo un seguimiento del Inventario de Comercio Electrónico . Nota: las opciones de agregación e informes disponibles para MongoDB han mejorado mucho desde esas publicaciones.
Realice confirmaciones de dos fases : un patrón de diseño para realizar actualizaciones de múltiples documentos en MongoDB
La replicación de Master-Master ( MVCC ) que menciona no parece ser una característica relevante para el comercio electrónico, donde generalmente se necesita una gran coherencia en lugar de una coherencia final. Menciona la sincronización de las bases de datos de usuarios, por lo que tal vez ese requisito específico podría abordarse mejor con una solución de inicio de sesión único, como OpenID.
Construiré un sitio de comercio electrónico y me gustaría utilizar una base de datos sin sql, que se ajuste a los planes de la aplicación. Pero cuando se trata de la base de datos que se ajuste al trabajo, no estoy seguro. Después de comparar varios DB, los que parecen mejores pueden ser mongo, couch o incluso orientdb. He visto argumentos para todos ellos para ser utilizados o no utilizados en comparación con algo como MySQL. Pero entre ellos (bases de datos nosql), ¿cuál encajaría bien con una solución de comercio electrónico?
Tenga en cuenta que, para el caso de uso, no tendré miles de transacciones por segundo. O tasas de escritura similares. estarán moderadamente seguros, pero a un nivel que cualquier base de datos establecida podría manejar.
CouchDB: tiene maestro para dominar la replicación, que realmente podría usar. De lo contrario, igual tendré que implementar la misma funcionalidad en el código de todos modos. Necesito poder tener una base de datos de usuarios, sincronizar con la nave nodriza. (los usuarios tendrán su propia base de datos potencialmente local, que podría sincronizarse con el servidor de dominios principal). Couch también es rápido, una vez que tus consultas se han almacenado en el db. Como es probable que tenga una mayor necesidad de rendimiento de lectura. Aunque no por mucho.
MongoDB: las consultas son muy sencillas y fáciles de usar. Además, con el hecho de que los usuarios finales pueden necesitar consultar ciertas cosas en un momento dado que es posible que no pueda contabilizar antes de tiempo, parece que puede ser una mejor opción. No tengo que pre-almacenar mis consultas en el db. Admite transacciones atómicas, aunque solo cuando se escribe en un solo documento a la vez.
OrientDB: una base de datos de gráficos. muy diferente a lo que la mayoría de la gente está acostumbrada, pero con las necesidades, también podría encajar muy bien. Orient tiene los beneficios de no tener esquemas, así como de tener soporte para transacciones ACID. Hay muchas relaciones de clientes y productos con las que una base de datos de gráficos podría ser excelente. Orient también admite master to master replication, similar a couchdb.
No me malinterpreten, puedo ver cómo construir esto tradicionalmente con algo como MySQL, pero la facilidad y simplicidad de una solución nosql es muy atractiva. Aunque, en mi caso, necesitar una solución sin esquema, sería mucho más fácil en nosql que en mysql. un producto dado puede tener más o menos artículos, que otro. y evitando volver a crear una tabla cada vez que se agrega un nuevo campo, es preferible.
Entonces, entre estos 3 (o incluso otros que crees que pueden ser mejores), ¿para qué características de cada uno podría funcionar, o en mi contra en relación con un sitio basado en comercio electrónico, cuando se trata de transacciones con clientes?
Editar: La razón por la que no estoy usando una solución existente es porque con las características integradas que necesito, no hay soluciones disponibles. También pretendemos utilizar esto como un producto completo para nuestra empresa. Habrá un puñado de otras integraciones aparte de las ventas. También va a funcionar con el sistema POS de una tienda.
Consulte la comparación de diferentes bases de datos NoSql aquí . Adaptarse a su requisito según eso.