modify - MySQL sharding enfoques?

rename attribute mysql (5)

¿Conoces algún proyecto o herramienta interesante en esta área?

Varios proyectos nuevos en este espacio:

citusdata.com
spockproxy.sourceforge.net
~~github.com/twitter/gizzard/~~

Cuál es el mejor enfoque para Sharding MySQL tablas. Los enfoques en los que puedo pensar son:

¿Nivel de aplicación sharding?
Sharding en la capa de proxy MySQL?
Servidor de búsqueda central para sharding?

¿Conoces algún proyecto o herramienta interesante en esta área?

Agrupamiento de nivel de aplicación: dbShards es el único producto que conozco que tiene "sharding de aplicación consciente". Hay algunos buenos artículos en el sitio web. Solo por definición, la fragmentación con conocimiento de aplicaciones será más eficiente. Si una aplicación sabe exactamente dónde ir con una transacción sin tener que buscarla o ser redireccionada por un proxy, eso en sí mismo será más rápido. Y la velocidad es a menudo una de las principales preocupaciones, si no la única preocupación, cuando alguien está investigando sharding.
Algunas personas "fragmentan" con un proxy, pero a mis ojos eso derrota el propósito de sharding. Simplemente está utilizando otro servidor para indicarle a sus transacciones dónde encontrar los datos o dónde almacenarlos. Con la fragmentación conciente de la aplicación, su aplicación sabe dónde ir por sí misma. Mucho más eficiente.
Esto es lo mismo que realmente el # 2.

El mejor enfoque para fragmentar las tablas MySQL es no hacerlo a menos que sea totalmente inevitable hacerlo.

Cuando está escribiendo una aplicación, generalmente desea hacerlo de una manera que maximice la velocidad, la velocidad del desarrollador. Optimiza la latencia (tiempo hasta que la respuesta esté lista) o el rendimiento (número de respuestas por unidad de tiempo) solo cuando sea necesario.

Particiona y luego asigna particiones a diferentes hosts (= shard) solo cuando la suma de todas estas particiones ya no cabe en una sola instancia de servidor de base de datos, el motivo es que escribe o lee.

El caso de escritura es a) la frecuencia de las escrituras sobrecarga los discos de estos servidores permanentemente ob) hay demasiadas escrituras en marcha para que la replicación permanezca rezagada en esta jerarquía de replicación.

El caso de lectura para sharding es cuando el tamaño de los datos es tan grande que el conjunto de trabajo ya no cabe en la memoria y las lecturas de datos comienzan a golpear el disco en lugar de ser servidas desde la memoria la mayor parte del tiempo.

Solo cuando tienes que fragmentarlo lo haces.

En el momento en que muere, está pagando por eso de múltiples maneras:

Gran parte de tu SQL ya no es declarativo.

Normalmente, en SQL le está diciendo a la base de datos qué datos desea y le deja al optimizador convertir esa especificación en un programa de acceso a datos. Eso es bueno, porque es flexible y porque escribir estos programas de acceso a datos es un trabajo aburrido que perjudica la velocidad.

Con un entorno fragmentado, probablemente se está uniendo a una tabla en el nodo A contra datos en el nodo B, o tiene una tabla más grande que un nodo, en los nodos A y B y está uniendo datos contra los datos que están en el nodo B y C. Está empezando a escribir manualmente las resoluciones de combinación basadas en hash del lado de la aplicación para resolver eso (o está reinventando el clúster MySQL), lo que significa que termina con una gran cantidad de SQL que ya no es declarativo, pero expresa la funcionalidad SQL de forma procedimental (por ejemplo, está utilizando instrucciones SELECT en bucles).

Estás incurriendo en una gran cantidad de latencia de red.

Normalmente, una consulta SQL se puede resolver localmente y el optimizador conoce los costos asociados con los accesos al disco local y resuelve la consulta de una manera que minimiza los costos para eso.

En un entorno fragmentado, las consultas se resuelven ejecutando accesos de valores-clave en una red a múltiples nodos (con suerte accesos de claves por lotes y no búsquedas de claves individuales por viaje de ida y vuelta) o empujando partes de la cláusula WHERE hacia adelante a los nodos donde se puede aplicar (que se llama ''pushdown de condición''), o ambos.

Pero incluso en el mejor de los casos, esto implica muchos viajes redondos más que una situación local, y es más complicado. Especialmente dado que el optimizador de MySQL no sabe nada sobre la latencia de la red en absoluto (Ok, el clúster de MySQL está mejorando lentamente en eso, pero para MySQL vainilla fuera del clúster que todavía es cierto).

Está perdiendo mucho poder expresivo de SQL.

Bueno, eso es probablemente menos importante, pero las restricciones de clave externa y otros mecanismos de SQL para la integridad de datos son incapaces de abarcar múltiples fragmentos.

MySQL no tiene API que permita que las consultas asíncronas funcionen correctamente.

Cuando los datos del mismo tipo residen en múltiples nodos (por ejemplo, datos de usuario en los nodos A, B y C), las consultas horizontales a menudo deben resolverse contra todos estos nodos ("Buscar todas las cuentas de usuario que no han iniciado sesión durante 90 días o más"). El tiempo de acceso a los datos crece de forma lineal con el número de nodos, a menos que se puedan solicitar varios nodos en paralelo y los resultados se agreguen a medida que entren ("Map-Reduce").

La condición previa para eso es una API de comunicación asíncrona, que no existe para MySQL en una buena forma de trabajo. La alternativa es una gran cantidad de bifurcaciones y conexiones en los procesos hijos, que es visitar el mundo de chupar un pase de temporada.

Una vez que comienza a fragmentar, la estructura de datos y la topología de red se hacen visibles a medida que el rendimiento apunta a su aplicación. Para tener un rendimiento razonablemente bueno, su aplicación debe ser consciente de estas cosas, y eso significa que realmente solo tiene sentido la fragmentación de nivel de aplicación.

La pregunta es más si se quiere auto-fragmento (determinando qué fila va dentro de cada nodo mediante claves hash, por ejemplo) o si se quiere dividir funcionalmente de forma manual ("Las tablas relacionadas con la historia del usuario xyz van a este maestro, mientras que las tablas relacionadas abc y def van a ese maestro ").

La fragmentación funcional tiene la ventaja de que, si se realiza correctamente, es invisible para la mayoría de los desarrolladores la mayor parte del tiempo, ya que todas las tablas relacionadas con su historia de usuario estarán disponibles localmente. Eso les permite aún beneficiarse de SQL declarativo el mayor tiempo posible, y también incurrirá en una menor latencia de la red debido a que el número de transferencias entre redes se mantiene mínimo.

La fragmentación funcional tiene la desventaja de que no permite que una sola tabla sea más grande que una instancia, y requiere la atención manual de un diseñador.

La fragmentación funcional tiene la ventaja de que se realiza con relativa facilidad a una base de código existente con una cantidad de cambios que no es demasiado grande. http://Booking.com lo ha hecho varias veces en los últimos años y funcionó bien para ellos.

Habiendo dicho todo eso, al ver su pregunta, creo que está haciendo las preguntas incorrectas, o estoy malinterpretando completamente su declaración de problema.

Nivel de aplicación por supuesto.

El mejor enfoque que alguna vez he visto en rojo que he encontrado en este libro

Alto rendimiento MySQL http://www.amazon.com/High-Performance-MySQL-Jeremy-Zawodny/dp/0596003064

Breve descripción: puede dividir sus datos en muchas partes y almacenar ~ 50 partes en cada servidor. Le ayudará a evitar el segundo mayor problema de fragmentación: el reequilibrio. Simplemente mueva algunos de ellos al nuevo servidor y todo estará bien :)

Te recomiendo que lo compres y leas la parte de "escalado de mysql".

Shard-Query es una solución de fragmentación basada en OLAP para MySQL. Le permite definir una combinación de tablas fragmentadas y tablas sin bordes. Las tablas sin bordes (como las tablas de búsqueda) se pueden unir libremente a las tablas fragmentadas, y las tablas fragmentadas se pueden unir entre sí siempre que las tablas estén unidas por la clave del fragmento (sin cross shard o uniendo los límites del fragmento cruzado). Siendo una solución OLAP, Shard-Query generalmente tiene un tiempo de respuesta mínimo de 100 ms o menos, incluso para consultas simples, por lo que no funcionará para OLTP. Shard-Query está diseñado para analizar grandes conjuntos de datos en paralelo.

También existen soluciones de fragmentación OLTP para MySQL. Las soluciones de código cerrado incluyen ScaleDB , DBShards . La solución de código abierto OLTP incluye JetPants , Cubrid o Flock/Gizzard (infraestructura de Twitter).