Infraestructura para DB altamente concurrente y de alta escritura

Mis requisitos son:

• 3000 conexiones
• 70-85% escritura vs lectura

Actualmente, estamos maximizando una instancia extra grande de CPU alta con 700 conexiones. Los 8 núcleos están al máximo. Creemos que es el número de conexiones concurrentes ya que la memoria está bien. La escritura en sí es muy simple (las validaciones ralentizan las cosas). Para escalar a 3000, necesitamos ir a múltiples servidores, opciones actuales:

• Fragmento de MySQL
• Cluster MongoDB
• Cassandra
• Hadoop y MySQL (cachés de Hadoop, volcado único a MySQL)
• MongoDB y MySQL (en lugar de Hadoop, usamos mongo para caché)

Para manejar este número de conexiones, una serie de preguntas:

1. ¿Puede MySQL Sharding manejar las conexiones concurrentes?
2. ¿Puede un solo maestro manejar estas conexiones concurrentes, o es una opción mejor como un multicabezal como Mongo?

Pido disculpas si no estoy describiendo bien mi problema. Por favor haga preguntas.

Si está utilizando MySQL como la base de datos principal, es posible que desee considerar el uso de una topología en estrella a través de MySQL Replication.

Ahora, antes de decir UGHHH, ROFL y OMG a MySQL Replication, escúchame.

Una topología en estrella le permite escribir en un servidor DB (llamado Distribución Mster [DM]) y enviar los comandos SQL a varios servidores DB. ¿Cómo se configura dicha infraestructura de base de datos?

Aquí está la descripción

Tiene 5 servidores de base de datos (servidor A, B, C, D, E)

Servidor A

• En la configuración de MySQL Replication, será el maestro
• Desempeña un papel especial como DM
• Maestro de servidores B, C, D, E
• Todas las tablas usan el motor de almacenamiento BLACKHOLE (/ dev / null)
• Solo almacena registros binarios
• Máquina de metal desnudo
• Beneficios
  • Escrituras muy rápidas ya que todas las tablas en el DM usan BLACKHOLE
  • La latencia de red es un problema menor, ya que las lecturas representan el 15-30% de la actividad de la base de datos
  • Todos los esclavos se actualizan estrictamente desde el DM

Servidores B, C, D, E

• Esclavo de un
• Servidor una base para SELECT pesados
• El servidor puede ser virtual o desnudo
• Para todos los servidores cuyas tablas de usuario usan el motor de almacenamiento InnoDB
  • Puede servir como servidor de base de datos en espera caliente
  • Las copias de seguridad no intrusivas se pueden ejecutar contra él
• Para todos los servidores cuyas tablas de usuario usan el motor de almacenamiento MyISAM
  • Configurar con oprion de solo lectura
  • Las tablas pueden tener sus formatos de fila rehechos para acelerar las lecturas

He escrito publicaciones sobre esto antes

• /server/264374/mysql-in-star-topology/264444#264444
• /programming/5273043/mysql-in-star-topology/5781504#5781504

Para mantener MySQL Replication en la mejor forma

• Use MySQL 5.5
• Usar replicación semisincrónica
• Ajuste InnoDB para activar más CPU

MySQL Cluster podría ser otro enfoque para el fragmentación. Revise la publicación aquí .

También soy un gran admirador de Cassandra, pero depende mucho de su modelo de datos y de las consultas que desee realizar. Cassandra es increíblemente rápida para escribir, porque siempre son secuenciales en el disco.

Si vas a tener varias cabezas (lo que probablemente necesites si realmente necesitas conexiones activas de 3K), probablemente miraría a Riak o tal vez a Cassandra. Realmente depende de lo que haga su aplicación en cuanto a qué tan bien encajará, pero por lo que ha descrito, creo que encajaría en algo como Riak.

Dicho esto, un enfoque fragmentado parece bastante factible, si puede encontrar una buena manera de segmentar los datos, y puede minimizar cualquier necesidad de material de fragmentos cruzados. Me mantendría alejado de cualquiera de las cosas de anillo / estrella / mmm en mysql, y solo me quedaría con el fragmentación recta. En realidad, si estaba dispuesto a usar Postgres, podría crear prototipos con bastante facilidad utilizando esquemas en algo como heroku, y luego bifurcar y dividir las bases de datos a medida que comienzan a superar los nodos individuales.

Ah, y aunque creo que podría intentar escalar algo como esto verticalmente (un nodo único que maneja todas las conexiones de 3K), no creo que pueda hacerlo en la nube.

Si es una opción para su aplicación específica, tal vez pueda usar alguna forma asíncrona para escribir datos en su base de datos (cola de trabajo, inserciones en lotes ...) y / o alejar las muchas conexiones de clientes de su base de datos con algún proxy al frente .

Con el fragmentación, generalmente puede escalar bien (2x servidores db == 2x conexiones), pero depende en gran medida de la naturaleza de su conjunto de datos y de cómo puede dividirlo en fragmentos.

Personalmente prefiero MongoDB por su facilidad de administración, escalabilidad y facilidad de uso general. Además, a menos que realmente necesite un RDBMS, voy a usar un no-SQL.

Dicho esto, elija la base de datos que tenga más sentido para su aplicación. Si necesita transacciones o no puede diseñar su aplicación sin combinaciones (o simplemente tiene más sentido con ellas), use un RDBMS (MySQL, PostGres, etc.)

Aunque personalmente prefiero MongoDB, la idea de que MySQL no escala o no puede manejar una alta tasa de transacciones es puramente falsa. El equipo de ingeniería de Facebook (y el equipo de MySQL dentro de él) entra en gran detalle con él. Consulte también el blog del equipo de Etsy Ops; ellos aman MySQL también.

Finalmente, no usaría MongoDB para un caché MySQL; usa Memcached para eso.

Redis también es un almacén de valores clave en RAM que es bueno para manejar ciertos casos de uso. Hay algunas entradas de blog en blog.agoragames.com que describen algunos casos de uso.

También debe consultar CouchDB si está pensando en No-SQL. Solo tenga en cuenta que requiere un mantenimiento regular para mantener baja la utilización del disco. (Cambia la velocidad y la conveniencia por la utilidad del disco ...)

Finalmente, la planificación de la capacidad no es fácil de predecir. Debe realizar las pruebas en las condiciones más realistas posibles y estar preparado para remediar según lo que ve. Lamentablemente, la "informática" es tanto arte como ciencia.