Arquitectura de referencia para la implementación de MySQL con uso intensivo de escritura

Nosotros concebimos Herramientas en la nube de Percona (configuración de hardware y software) para manejar una carga de trabajo de script MySQL muy intensiva. Por ejemplo, ya hemos observado inserciones de más de mil millones de puntos de datos por día. Así que quería compartir qué tipo de hardware usamos para obtener este resultado.

Permítanme describir lo que usamos y luego explicaré por qué.

Servidor:

  • Chasis: Chasis de montaje en rack Supermicro SC825TQ-R740LPB 2U
  • Placa base: Supermicro X9DRI-F de doble zócalo
  • CPU: Dual Intel Xeon Ivy Bridge E5-2643v2 (6x core 3.5Ghz, 12x core HT, 25M L3)
  • Memoria: 256 GB (16x 16 GB de cuatro canales de 256 bits) ECC registrado DDR3-1600
  • Raid: controlador RAID de hardware LSI MegaRAID 9260-4i de 4 puertos 6G / s, búfer de 512M
  • Memoria principal: SSD PCIe HGST FlashMAX II de 4,8 TB
  • Almacenamiento secundario (SO, registros): RAID 1 en 2 discos duros de 3 TB

Software:

Al elegir el hardware para su aplicación, debe tener en cuenta varios aspectos; por lo general, busca una solución para la que ya tenga experiencia trabajando y que también haya demostrado ser la opción más eficaz. Para nosotros fue así:

Nube vs metal desnudo
Tenemos experiencia en tener hardware alojado en el centro de datos, así como dinero para inversiones iniciales en hardware, por lo que decidimos optar por un hardware físico autohospedado en lugar de la nube. Seguir esta ruta también nos dio la máxima flexibilidad para elegir una configuración de hardware que fuera la más óptima para nuestra aplicación en lugar de seleccionar una de las opciones de acciones.

Escalar hacia arriba frente a escalar hacia afuera
Diseñamos un sistema desde cero para poder usar múltiples servidores a través de fragmentación, por lo que nuestra principal preocupación es elegir la configuración más óptima para el servidor y suministrar los servidores según sea necesario. Además del rendimiento bruto, también debemos considerar el uso de energía y los gastos generales de administrar varios servidores, lo que generalmente hace que valga la pena tener un hardware un poco más avanzado.

Utilización de recursos
Cada aplicación usa los recursos de diferentes maneras, por lo que la configuración óptima será diferente según su aplicación. Sin embargo, todas las aplicaciones utilizan los mismos recursos que debe tener en cuenta. Por lo general, desea planificar el uso sustancial de todos sus recursos, lo que proporciona cierto margen de maniobra para los picos y el mantenimiento.

UPC

  • Nuestra aplicación procesa una gran cantidad de datos y utiliza el motor de almacenamiento TokuDB, que utiliza una gran cantidad de CPU para la compresión, por lo que necesitamos CPU potentes.
  • Muchas funciones de MySQL no son paralelas, piense en ejecutar una sola consulta o alterar la tabla, por lo que optamos por CPU con núcleos más rápidos en lugar de una mayor cantidad de núcleos. La configuración resultante con 2 zócalos que dan 12 núcleos y 24 cables es lo suficientemente buena para nuestras cargas de trabajo.
  • Las CPU inferiores como la Xeon E3 tienen una relación precio/rendimiento muy atractiva, pero solo admiten 32 GB de memoria, lo que no fue suficiente para nuestra aplicación.

Memoria

  • Para las cajas de bases de datos, la memoria se usa principalmente como caché, por lo que, dependiendo de su aplicación, puede ser mejor invertir en memoria o almacenamiento para un rendimiento óptimo. Echa un vistazo a esta publicación de blog para obtener más detalles.
  • El acceso a los datos en la memoria es mucho más rápido que incluso en un almacenamiento flash más rápido, por lo que sigue siendo importante.
    Para nuestra carga de trabajo, tener datos recientes en la memoria es muy importante para tener una cantidad de memoria «económica», ya que podemos llenar las 16 ranuras con dimms de 16 GB que tienen un costo atractivo por GB en este punto.

Almacenamiento
Hay muchos usos para el almacenamiento, por lo que hay varias variables a considerar

  • banda ancha
    • Necesitamos poder acceder a los datos en el dispositivo de almacenamiento rápidamente y con un tiempo de respuesta estable. HGST FlashMax II ha sido capaz de satisfacer estas necesidades tan exigentes.
  • Resistencia
    • Al usar el almacenamiento flash, debe preocuparse por la resistencia: la duración de la batería con el almacenamiento flash que puede manejar antes de deshacerse de él. Algunas SSD MLC de bajo costo se eliminarán en unas pocas semanas si se escriben a toda velocidad. HGST FlashMax II tiene una clasificación de resistencia de 10 petabytes escrito (para una carga de trabajo aleatoria) – 30 petabytes escrito (para una carga de trabajo secuencial)
    • También usamos el motor de almacenamiento TokuDB que reduce significativamente la cantidad de escritura en comparación con Innodb.
  • Durabilidad
    • ¿Proporciona el almacenamiento una durabilidad real con datos garantizados para ser persistentes cuando se reconoce la escritura en el nivel del sistema operativo cuando se corta la energía o es posible que se produzca una pérdida?
      No queremos correr el riesgo de dañar la base de datos en caso de corte de energía, por lo que estamos buscando una solución de almacenamiento que garantice la durabilidad.
      HGST FlashMax II garantiza la durabilidad que ha sido confirmada por nuestras pruebas de estrés.
  • Cortar
    • Para escalar los requisitos de almacenamiento de aplicaciones, debe escalar tanto la cantidad de operaciones de E/S que el almacenamiento puede manejar como el tamaño del almacenamiento. Para el almacenamiento flash, a menudo es el tamaño el que se convierte en un factor limitante.
      La capacidad HGST FlashMax II de 4,8 TB es la mejor disponible en el mercado, lo que nos permite usar «All Flash» y obtener un acceso muy rápido a todos nuestros datos.
  • Almacenamiento secundario
    • No todas las aplicaciones necesitan propiedades de almacenamiento flash.
    • Disponemos de almacenamiento secundario con unidades convencionales para el sistema operativo y logs.
      El modelo de lectura/escritura secuencial funciona bien con unidades convencionales de bajo costo y también le permite aumentar la vida útil del flash, al tener menos manejo de escritura.
    • Usamos RAID con BBU para el almacenamiento secundario para poder tener registros binarios completamente duraderos sin pagar una penalización de alto rendimiento.

¿Por qué PCIe SSD sobre SATA SSD?
Hay argumentos de que SATA SSD solo proporciona un rendimiento bastante bueno para MySQL y no hay necesidad de PCIe. Si bien estos argumentos son válidos en una dimensión, hay muchos más que considerar.

Primero, como dije, PCIe SSD siempre proporciona uno el mejor tiempo de respuesta absoluto y es un factor importante para la experiencia del usuario final en sistemas similares a SaaS Herramientas en la nube de Percona.
En segundo lugar, considéralo Operaciones de mantenimiento como copias de seguridad, ALTER TABLES o configuraciones esclavas. Si bien estas operaciones son tediosas y no reciben tanta atención como el tiempo de respuesta o el rendimiento en los puntos de referencia, siguen siendo operaciones que los DBA realizan básicamente todos los días, y es muy importante terminar un copia de seguridad o ALTER TABLE en un tiempo predecible, especialmente en el rango de datos de 3-4 TB. Y aquí es donde PCIe SSD funciona mucho mejor que SATA SSD. Para los SSD SATA, especialmente los más grandes, la resistencia a la escritura es otro punto de preocupación.

¿Por qué el motor TokuDB?
El motor TokuDB es el mejor cuando se trata de insertar operaciones en un gran conjunto de datos, y entran en juego algunos factores más:

  • La compresión TokuDB es una gran victoria. Estoy estimado en este almacenamiento (FlashMAX II 4.8TB) llegaremos a eso 20-30 TB de datos sin procesar.
  • TokuDB es compatible con SSD, ya que realiza mucha menos escritura de datos por operación INSERT que InnoDB, lo que extiende mucho la vida útil de SSD (que es, bueno, costoso, por decir lo menos).

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario