Yo he usado ambos enfoques en diferentes puntos de mi carrera, y ambos son válidos.
En primer lugar, hay un par de declaraciones que no son muy correctas.
...Y en un archivo en disco con el fin de evitar la pérdida de todos los datos si el programa se bloquea.
... tienen la TWS de la API de recepción de datos asincrónica de alimentación y anexar los datos en un plano/archivo binario en el sistema. Varios
Me suena que va a escribir en el disco en el primer paso de todo el sistema para lograr la persistencia. Esto todavía no es garantía de nada - tu disco puede fallar, su matriz RAID podría fallar, a continuación, el disco podría fallar durante resilvering debido a la tasa de error de bit en grandes discos, su sistema operativo puede ser guardado en el buffer de escritura en caché de la página y la máquina se cuelga antes de que se vacíe. De hecho, dada la estabilidad de los servidores de hoy en día, el disco es probablemente más probabilidades de fracasar que de memoria.
Si usted escribe a disco en las aguas de ruta de acceso de todos los demás optimización usted está pensando probablemente no signifique nada.
PRO: todo está perfectamente integrado y todos los datos están en la memoria, así no se pierde tiempo en operaciones de e / s.
Tener una sola aplicación que se ejecute como un proceso único, una única ejecución de la aplicación como de varios procesos, o varias aplicaciones (cada uno de ellos ejecuta como un proceso separado) no tiene ninguna relación en si sus datos están en la memoria o en el disco. Prácticamente todas las aplicaciones multiproceso para el comercio se emplean memoria compartida o sockets de dominio para comunicarse.
cual plana/archivos binarios de tipos podría ser adecuado para el soporte de múltiples sólo lectura y una escritura única/sólo anexar procesos al mismo tiempo sin la necesidad de serializar estas operaciones en un único hilo en un solo proceso (e.g véase el inciso aquí para pandas.HDFStore)?
Generalmente no hay ningún hilo de los temas de seguridad con un solo escritor y varios lectores del mismo archivo, y el archivo de formato de serialización no afecta a este. Si los lectores han estado independiente, se puede utilizar cualquier formato que usted desee. Si usted necesita coordinar estado, aunque, por ejemplo lector 1 se lee como número de bytes hasta que se llena el buffer de lectura, a continuación, hace un poco de trabajo con el que, de lectura y de los 2 debe seguir de forma secuencial, donde el lector 2 dejó, entonces termina con condiciones de carrera.
La mayoría de los problemas de concurrencia con e/S de archivo surgir en múltiples escritor implementaciones.
Así que usted puede conseguir a través de las cosas con una sola escritura y múltiples lectores con un estado independiente.
Multiprocesamiento
Pros:
- Más fácil de implementar, ya que cada aplicación mapeada en un sistema operativo de proceso, y usted puede confiar en el sistema operativo para la programación y para aislar desbordamiento de memoria.
- Más fácil de perfil y utilizar las herramientas de depuración en contra de las aplicaciones modulares a través de procesos de hilos.
Contras:
- Es necesario que los procesos compartan memoria, con separación de los espacios de dirección, se basa en el sistema operativo soporte para memoria compartida.
- Menos memoria eficientes que los hilos desde los procesos de mantener el estado (por ejemplo, del cambio de contexto, la red identificador de la tabla).
Multithreading
Pros:
- No se basa en el sistema operativo de memoria compartida construcciones para la comunicación entre las piezas.
- Más escalable debido a una menor huella en la memoria de los hilos.
Contras:
- No OS la protección contra hilos separados se desborda en cada uno de los otros de la memoria.
- Difícil para el soporte de múltiples plataformas debido a las diferentes roscado interfaces.
