Construiré un sitio de comercio electrónico y me gustaría utilizar una base de datos sin sql, que se ajustará bien a los planes para 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?NoSQL Database for ECommerce
Nota, 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 replicación de maestro a maestro, 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áfico. 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 evitar 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), ¿qué características de cada uno podrían funcionar o contra mí en relación con un sitio de comercio electrónico cuando se trata de transacciones de 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.
Ve a SQL + Solr/ElasticSearch. SQL para una tasa de escritura/consulta moderada, seguridad de los datos y seguridad de las transacciones (¿quién quiere que dos nodos DB vendan lo mismo a dos personas diferentes?). Y Solr/ElasticSearch para un esquema flexible (o nulo), consultas ad-hoc muy capaces y búsquedas realmente rápidas. Posiblemente pueda hacer una copia de seguridad de su SQL DB en un solo archivo cada noche. – aitchnyu
@aitchnyu No estoy seguro de que usted justifique el uso de SQL tan bien. ¿Qué quiere decir con "dos nodos DB para vender lo mismo a dos personas diferentes"? – Sammaye
Hay una plataforma de comercio electrónico de código abierto que usa MongoDB. Compruébelo: getfwd.com –