- Colas para administrar actualizaciones de inventario para cada canal.
Esto no es necesariamente un problema de la base de datos. Es mejor que busque un sistema de mensajería (por ejemplo, RabbitMQ)
- Tabla de inventario que tiene una instantánea correcta de la asignación en cada canal.
- Mantener ID de sesión y otros datos de acceso rápido en un caché.
los datos de la sesión probablemente deberían colocarse en una base de datos separada más adecuada para la tarea (por ejemplo, memcached, redis, etc.) No existe una base de datos única para todos
- Proporcionar un panel similar a Facebook (XMPP) para mantener actualizado al vendedor lo antes posible.
Mis limitaciones son:1. Las actualizaciones de inventario no se pueden perder.
Hay 3 formas de responder a esta pregunta:
-
Esta característica debe ser proporcionada por su aplicación. La base de datos puede garantizar que un registro erróneo sea rechazado y revertido, pero no garantiza que se ingresen todas las consultas. La aplicación deberá ser lo suficientemente inteligente para reconocer cuándo ocurre un error e intentarlo de nuevo.
-
algunas bases de datos almacenan registros en la memoria y luego descargan la memoria en el disco periódicamente, lo que podría provocar la pérdida de datos en caso de un corte de energía. (por ejemplo, Mongo funciona de esta manera de forma predeterminada a menos que habilite el registro en diario. CouchDB siempre se agrega a los registros (incluso una eliminación es una marca que se agrega al registro, por lo que la pérdida de datos es extremadamente difícil))
-
Algunos DB están diseñados para ser extremadamente confiables, incluso si ocurre un terremoto, un huracán u otro desastre natural, siguen siendo duraderos. estos incluyen Cassandra, Hbase, Riak, Hadoop, etc.
¿A qué tipo de durabilidad te refieres?
- Las colas de trabajos deben ejecutarse en orden y preferiblemente nunca perderse.
La mayoría de las soluciones noSQL prefieren ejecutarse en paralelo. por lo que tiene dos opciones aquí.1. use una base de datos que bloquee toda la tabla para cada consulta (más lenta) 2. cree su aplicación para que sea más inteligente o tenga eventos (cola secuencial del lado del cliente)
- Desarrollo fácil/rápido y mantenimiento futuro.
en general, descubrirá que SQL es más rápido de desarrollar al principio, pero los cambios pueden ser más difíciles de implementar. SQL puede requerir un poco más de planificación, pero es más fácil realizar consultas ad hoc o cambios de esquema.
Las preguntas que probablemente debas hacerte son más como:
-
"¿Tendré que realizar consultas intensas o un análisis profundo para el que Map/Reduce se adapte mejor?"
-
"¿Tendré que cambiar mi esquema con frecuencia?
-
"¿Mis datos son altamente relacionales? ¿De qué manera?"
-
"¿El proveedor detrás de mi base de datos elegida tiene suficiente experiencia para ayudarme cuando lo necesito?"
-
"¿Necesitaré funciones especiales como indexación geoespacial, búsqueda de texto completo, etc.?"
-
"¿Qué tan cerca del tiempo real necesitaré mis datos? ¿Me dolerá si no veo los registros más recientes en mis consultas hasta 1 segundo después? ¿Qué nivel de latencia es aceptable?"
-
"¿Qué necesito realmente en términos de conmutación por error?"
-
"¿Qué tan grande es mi información? ¿Cabe en la memoria? ¿Cabe en una computadora? ¿Cada registro individual es grande o pequeño?
-
"¿Con qué frecuencia cambiarán mis datos? ¿Es esto un archivo?"
Si va a tener múltiples clientes (¿canales?) cada uno con sus propios esquemas de inventario, una base de datos basada en documentos podría tener sus ventajas. Recuerdo una vez que miré un sistema de comercio electrónico con inventario y ¡tenía casi 235 tablas! Por otra parte, si tiene ciertos datos relacionales, una solución SQL también puede tener algunas ventajas.
Ciertamente puedo ver cómo podría construir una solución usando mongo, couch, riak u orientdb con las restricciones dadas. Pero en cuanto a cuál es el mejor? Intentaría hablar directamente con los proveedores de bases de datos y tal vez mirar las cintas de nosql
