MySQL Sharding vs MySQL Cluster

Considerando solo el rendimiento , ¿puede un Clúster MySQL superar una solución MySQL personalizada de fragmentación de datos? fragmentación = partición horizontal

Cuando me refiero al sharding, estoy considerando el sharding hecho en la capa de aplicación, por ejemplo, distribuyendo registros de manera uniforme en instancias MySQL independientes. Para dos servidores, podría ser (clave mod 2).

mysql ndbcluster

— gsb
fuente

Divulgación: Soy un empleado de MySQL, trabajando en MySQL Cluster.

Diría que MySQL Cluster podría lograr un mayor rendimiento / host que MySQL + InnoDB fragmentado, siempre que:

Las consultas son simples
Todos los datos caben en la memoria

En términos de latencia, MySQL Cluster debería tener una latencia más estable que MySQL fragmentado. La latencia real para los datos puramente en memoria podría ser similar.

A medida que las consultas se vuelven más complejas y los datos se almacenan en el disco, la comparación de rendimiento se vuelve más confusa. Para obtener una respuesta más específica, debe describir más acerca de su aplicación y las consultas que realiza, así como la cantidad de hosts y el volumen de datos. MySQL Cluster ha obtenido recientemente la ejecución de consultas localizadas paralelas (AQL), lo que significa que puede ser competitivo con MySQLD independiente a pesar de tener datos distribuidos en varios hosts.

MySQL Cluster está actualmente limitado a 'fragmentar' en 48 hosts. Sharded MySQL en teoría no tiene límite. Sin embargo, para un rendimiento objetivo determinado, se pueden necesitar menos hosts MySQL Cluster que hosts host MySQL.

Las diferencias más interesantes son cuando observa áreas distintas al rendimiento:

MySQL Cluster admite consultas arbitrarias en todos los fragmentos
MySQL Cluster admite transacciones arbitrarias en todos los fragmentos
MySQL Cluster admite la replicación síncrona de fragmentos con recuperación y conmutación por error automática
MySQL Cluster admite agregar nodo en línea (expansión de clúster)
Sharded MySQL es más 'rodar tu propio'

Tener fragmentos integrados en su aplicación le brinda el máximo potencial de escala, pero agrega complejidad y limita su flexibilidad en términos de consultas y operaciones de fragmentos cruzados. Si su fragmentación es prematura, puede ser la raíz de algunos problemas para usted. MySQL Cluster le permite obtener algunos de los beneficios de la creación de fragmentos sin tener que restringir su aplicación para que solo tenga un solo fragmento.

En cuanto a la respuesta anterior, algunas aclaraciones:

"Aunque MySQL Cluster es una queja de ACID, no proporciona un motor de almacenamiento adecuado para datos con claves compuestas".

MySQL Cluster admite claves compuestas primarias y secundarias. No estoy seguro de lo que no es "adecuado" al respecto. Tal vez el cartel anterior puede explicar?

"Para tener datos con las mismas características clave almacenadas en un conjunto particular de nodos de datos, puede hacer lo siguiente:

Ponga todos los nodos de datos fuera de línea, dejando solo los nodos de datos que desea alojar datos con las mismas características clave.

Cargue sus datos en el MySQL Cluster, que llena solo sus nodos de datos seleccionados

Vuelva a poner en línea todos los nodos de datos "

Esto es incorrecto. La distribución de datos es independiente de qué nodos estén en línea en cualquier momento. MySQL Cluster admite varios esquemas de distribución de datos para admitir las optimizaciones que describe. Describo la distribución de datos en MySQL Cluster en una publicación de blog aquí: Distribución de datos en MySQL Cluster

— Frazer Clement
fuente

Hola Frazier. Leí el enlace que proporcionaste. Solo para aclarar, mi comentario de 'clave compuesta' se basó en índices no únicos. La empresa de mi empleador probó MySQL Cluster alrededor del primer trimestre de 2007 y no le gustó debido al bajo rendimiento. En mi humilde opinión, eran las malas elecciones del cliente para las claves (pequeñas cardinalidades) y sus consultas. MySQL Cluster debe haber madurado más desde entonces en función de su enlace. En cuanto a mi segunda declaración, esta es la cantidad de usuarios de MongoDB que rellenan fragmentos específicos. Algunos de los clientes de mi empleador han hecho esto con sus configuraciones personalizadas de MySQL.

— RolandoMySQLDBA

En su enlace, mencionó 'un escaneo de índice ordenado' que no se pudo eliminar, ya que no se garantiza que las filas coincidentes se almacenen en un fragmento de tabla. Esta es la razón por la que estaba sugiriendo aislar datos a fragmentos específicos (nodos de datos) para minimizar los lugares donde se propagarían los datos. Dado que su respuesta resalta el lado positivo de MySQL Cluster, se ajusta mejor a la pregunta original publicada. Mi respuesta se equivoca a favor de la precaución, el pesimismo y ser un tanto ingenuo del poder de MySQL Cluster hoy.

— RolandoMySQLDBA

En lugar de mis desvaríos y desvaríos, ¡¡+1 por tu respuesta!

— RolandoMySQLDBA

Hola Rolando, gracias por aclarar tus declaraciones. Es cierto que los escaneos de índice ordenados no podados son 'caros' en el Clúster, ya que todos los nodos de datos están involucrados. Parece que estos escaneos en índices de baja cardinalidad serían caros en cualquier sistema, pero en Cluster se volvieron visiblemente caros. Su cautela y pesimismo sin duda lo han salvado más de una vez :) Gracias por el +1

— Frazer Clement