Archivo plano vs base de datos: ¿velocidad?

Question

Estoy haciendo un programa de chat, y necesito un lugar para almacenar mensajes. El cliente se comunicaría con el servidor cada x segundos con el último ID de mensaje recibido, y el servidor encontraría todos los mensajes con un ID más alto que ese, en las salas a las que el cliente se ha unido.

Como no voy a guardar cosas para siempre, estoy pensando en usar archivos planos (uno por habitación, así como mensajes directos) con solo los últimos 40 o más mensajes. Sin embargo, creo que con la comparación de números una base de datos sería más rápida.

¿Qué método de almacenamiento de datos debo usar?

Answer 1

El archivo plano puede ser un poco más rápido, pero terminará siendo más defectuoso en el largo plazo, porque en lugar de simplemente hacer un SELECT * FROM messages WHERE room=nnn AND ID > yyy, tendrá que cargar el archivo, analizarlo, escanear cada fila para el ID de mensaje, vaya al mensaje correcto y luego léalo.

Ese es solo el primer problema. Un archivo de texto no admite la escritura de varios usuarios (¿qué pasa si dos personas están publicando en la misma habitación al mismo tiempo?) Y puede dañarse fácilmente.

Teniendo en cuenta todo, yo diría que es mejor usar DB en general, incluso si es algo simple como SQLite, que tiene un excelente soporte de PHP. Sin embargo, considere la condición de muchos usuarios, MySQL es probablemente una opción mucho mejor. Además, MySQL tiene excelentes capacidades de almacenamiento en caché, por lo que la mayoría de las veces, los datos recientes provienen directamente de la memoria RAM, y serán servidos más rápido de lo que podría escanear un archivo de texto en PHP de cualquier manera.

Answer 2

En general, una base de datos sería mucho más rápida, ya que un índice le permitiría ir directamente a los registros que el servidor debe enviar.

OTOH, con solo 40 mensajes, es bastante probable que encaje en la RAM, y con tan pocos registros, incluso la rutina de búsqueda lineal más simple sería mucho más rápida que un solo acceso a HD.

Aún así, usar una base de datos es mucho más fácil, lo usaría por simplicidad y no por velocidad. Además, si tiene muchas salas simultáneas, escribirlo usted mismo significa muchas oportunidades para errores pequeños y triviales que retrasan el desarrollo innecesariamente.

Simplemente vaya con una base de datos.

Answer 3

Parece que no tiene que mantener el historial de chat en absoluto, entonces ¿por qué está considerando utilizar un método de almacenamiento permanente de datos (base de datos o archivo plano)? Puede hacerlo utilizando el software de caché de memoria como Memcashed, que es más rápido que la base de datos o el archivo plano.

Answer 4

Me pondré mi gorra en el ring, aunque esta es una vieja pregunta. Por velocidad, confiabilidad y facilidad de uso, una base de datos es la elección obvia fácil ... Con una advertencia importante que mucha gente está pasando por alto, y que es la mayoría de los hosts compartidos (la forma más común de alojamiento web) solo permiten 15 o así que las conexiones a la vez, incluso las de VPS generalmente solo permiten 100-200, dedicadas a 500 o más. Lo que eso significa es que si tiene (n) usuarios agrupando cada (s) segundos, esas conexiones se consumirán rápidamente, incluso más rápido si también está ejecutando algún tipo de CMS. Estando en el medio de desarrollar mi propio código de sala de chat en un VPS, también me enfrento a estos problemas.

Hasta ahora mi método ha sido este.

• Asegúrese de pasar una variable lastMessageReceived para limitar la respuesta.
• Si una sala de chat pública pasa un filtro de marca de tiempo además de
• , utilice un motor de caché de DB como MySQLnd con el caché de consultas habilitado y TTL configurado como la tasa de agrupación.
• No te vuelvas loco con la frecuencia de agrupación. Los intervalos de 1-2 segundos pueden parecer ordenados, pero matarán tu conteo de conexiones. Bajar eso a 5s o incluso más realmente hará una gran diferencia y los usuarios probablemente no lo notarán, y la carga de tu servidor será mucho más liviana. Incluso considere una tasa de agrupación variable que se eleva a sí misma durante la carga alta.
• Escriba su ajax para usar el tiempo de espera en lugar del intervalo para su agrupación y coloque la llamada de tiempo de espera en la devolución de llamada exitosa ajax, esto evita que las solicitudes se acumulen durante el uso máximo.
• Y la más grande, si usa una sala de chat compartida con muchos usuarios, escriba su propio código para almacenar en caché la consulta SQL en un archivo json y publíquelo para ajax, y escriba código TTL personalizado para verificar su edad y -popularlo según sea necesario durante las solicitudes, CRON sería genial aquí si su anfitrión lo permite. La edad que revisa un archivo y redirigir una solicitud AJAX es una función de nivel superior con muy poca sobrecarga de servidor, especialmente en comparación con consultar un DB. Y no analice el archivo en PHP buscando filtrar los mensajes antiguos, almacene el archivo con el primer mensaje en el nombre de archivo como chat_243.json y guárdelo como json formateado, luego solo sirva el archivo completo si llega una solicitud al php con lastMessageReceived = 243. Como esto creará varios archivos, necesitará una función para limpiar archivos de más de (m) minutos, pero también es un trabajo liviano para el servidor.

También hay opciones como los motores de base de datos diseñados para el chat y tomas de corriente (Node.js), pero los que requieren más ajustes del servidor de cuentas de alojamiento típicos permiten, para mis propósitos He estado escribiendo mi custodia sala de chat en cuenta la idea de que pueda implementarse en un servidor compartido en algún momento.