database - Muy grandes mesas de Mnesia en producción
erlang solaris (1)
Estamos utilizando Mnesia como base de datos principal para un sistema muy grande. Mnesia Fragmented Tables se ha comportado muy bien durante el período de prueba. El sistema tiene aproximadamente 15 tablas, cada una replicada en 2 sitios (nodos), y cada tabla está altamente fragmentada. Durante la fase de prueba (que se centró en la disponibilidad, la eficiencia y las pruebas de carga), aceptamos el Mnesia con sus muchas ventajas de estructuras complejas, dado que todas nuestras aplicaciones que se ejecutan en la parte superior del servicio son aplicaciones Erlang / OTP. Estamos ejecutando Yaws 1.91 como el servidor web principal.
Para configurar de manera eficiente las tablas fragmentadas, utilizamos varias referencias que han usado mnesia en grandes sistemas:
Estos son: Mnesia One Year Later Blog , Parte 2 del Blog , Lo seguí incluso aquí , Acerca del hash . Estas publicaciones del blog nos han ayudado a afinar aquí y allá para un mejor rendimiento.
Ahora, el problema. Mnesia tiene límites de tamaño de mesa, sí estamos de acuerdo. Sin embargo, los límites en la cantidad de fragmentos no se han mencionado en ninguna parte. Por motivos de rendimiento, y para atender grandes volúmenes de datos, ¿cuántos fragmentos mantendrían a mnesia "ok"?
En algunas de nuestras mesas, tenemos 64 fragmentos. con n_disc_only_copies establecido en el número de nodos en el cluster para que cada nodo tenga una copia por fragmento. Esto nos ha ayudado a resolver los problemas de falla de escritura de mnesia si un nodo dado está fuera de alcance en un instante. También en el blog anterior, sugiere que the number of fragments should be a power of 2 , esta declaración (dice) se investigó por la forma en que mnesia hace su hashing de registros. Sin embargo, necesitamos más explicaciones sobre esto, y de qué poder de dos se habla aquí: 2,4,16,32,64,128, ...?
El sistema está diseñado para ejecutarse en HP Proliant G6, que contiene procesadores Intel (2 procesadores, cada uno de 4 núcleos, 2,4 GHz de velocidad de cada núcleo, 8 MB de tamaño de caché), 20 GB de RAM, 1,5 Terabytes de espacio en disco. Ahora, 2 de estas máquinas de alta potencia están a nuestra disposición. La base de datos del sistema debe ser replicada en los dos. Cada servidor ejecuta Solaris 10, 64 bit.
¿En qué cantidad de fragmentos puede comenzar a degradarse el rendimiento de mnesia? ¿Está bien si aumentamos el número de fragmentos de 64 a 128 para una tabla determinada? ¿Qué tal 65536 fragmentos (2 ^ 16)? ¿Cómo podemos escalar nuestra mnesia para hacer uso del espacio Terabyte utilizando fragmentación?
Por favor, proporcione las respuestas a las preguntas y puede asesorar sobre cualquier otro parámetro que pueda mejorar el sistema.
NOTA: Todas las tablas que deben contener millones de registros se crean en el tipo disc_only_copies , por lo que no hay problemas de RAM. La memoria RAM será suficiente para las pocas tablas RAM que ejecutamos. Otros DBMS como MySQL Cluster y CouchDB también contendrán datos y utilizarán el mismo hardware con nuestro DBMS de Mnesia. MySQL Cluster se replica en los dos servidores (cada uno con dos nodos NDB, un servidor MySQL), y el nodo de administración se encuentra en un HOST diferente.
La sugerencia de tener una potencia de dos números de fragmentos se relaciona simplemente con el hecho de que el módulo de fragmentación predeterminado mnesia_frag utiliza hashing lineal, por lo que el uso de fragmentos 2 ^ n garantiza que los registros se distribuyan por igual (más o menos, obviamente) entre fragmentos.
En cuanto al hardware a disposición, es más una cuestión de pruebas de rendimiento. Los factores que pueden reducir el rendimiento son muchos y la configuración de una base de datos como Mnesia es solo una parte del problema general. Simplemente le aconsejo que haga una prueba de estrés en un servidor y luego pruebe el algoritmo en ambos servidores para comprender si se escala correctamente.
Hablando de la escala numérica de los fragmentos de Mnesia, recuerde que al usar disc_only_copies la mayor parte del tiempo se gasta en dos operaciones:
decidir qué fragmento contiene qué registro
recuperar el registro de la tabla de dets correspondiente (Mnesia backend)
El primero no es realmente dependiente de la cantidad de fragmentos considerados que, por defecto, Mnesia utiliza hashing lineal. El segundo está más relacionado con la latencia del disco duro que con otros factores.
Al final, una buena solución podría ser tener más fragmentos y menos registros por fragmento, pero al mismo tiempo tratar de encontrar el punto medio y no perder las ventajas de algunas mejoras en el rendimiento del disco duro como los búferes y cachés.