Acceso concurrente a la base de datos o archivo de memoria de múltiples procesos, ¿es eso posible?

Question

Aquí está mi situación. Tengo una aplicación de servidor diseñada para que múltiples usuarios lo usen, por lo que hay mucha operación de lectura/escritura al mismo tiempo. Y las respuestas deben ser rápidas.

Actualmente almacené en caché todos los datos en la memoria, por lo que la operación de lectura/escritura de datos es tan rápido como esperábamos. Para evitar que el bloqueo de datos me causara problemas, utilicé la cola para alinear las solicitudes de los usuarios, haga que ingresen al proceso del controlador uno uno. por uno.

Pero pronto encontré un problema. El programa solo puede manejar una solicitud a la vez. Incluso el temporizador de referencia del programa me informa que usó cero MS para procesar, pero todavía hay límites para manejar las solicitudes en un segundo. Ayuda, ahora manejé unas 100 veces por segundo.

Así que busco algunos métodos más concurrentes, como 8 procesos para manejar las 8 solicitudes al mismo tiempo. Eso será tan agradable. Pero hay un problema mayor con el intercambio de datos, no quiero reinventar la rueda. Así que revisé el MongoDB, Redis y SQLite.

Aquí está mi tarea, corrígeme si estaba equivocado, muchas gracias

MongoDB y Redis son realmente rápidos como dijeron, pero usaron el mismo mecanismo, pueden manejar una solicitud una vez, eso no es lo que estoy buscando.

Por lo tanto, el SQLITE está bastante más cerca, múltiples procesos pueden abrir el mismo archivo de DB al mismo tiempo y leer, el dolor es su bloqueo de escritura (no cuánto mejor funciona el nuevo bloqueo en SQLITE3).

Aquí está mi pregunta, ¿hay una solución sólida y buena para este escenario? Si separo el proceso de escritura en uno, ¿ayudaría?

Gracias por cualquier comentario

Answer 1

La solución con MongoDB es fragmentar. Fragmento de mongodb Básicamente le permite lanzar más procesadores al problema. Más procesadores = más hilos de escritura.

Cada instancia de MongoDB solo tiene un hilo de escritura. El fragmento da más instancias y, por lo tanto, permite más escrituras.

Sin embargo, hay un problema mayor aquí. Rendimiento del disco.

He tenido Mongo corriendo más de 1000 insertos / seg si todo está en RAM. Pero la mayoría de las personas usan Mongo como una base de datos con un respaldo de archivo real. Entonces, si está utilizando Mongo para escrituras realmente pesadas, debe estar preparado con discos que puedan aceptar ese nivel de rendimiento.

Nuevamente, la forma en que alrededor del problema de rendimiento del disco es fragmentar. Construya más fragmentos y obtendrá menos escrituras / disco y básicamente menos bloqueo por todas partes.