Sharding e índices

Question

Quiero fragmentar mi base de datos, pero no soy profesional en este tema. Así que aquí están mis consideraciones. Aunque la clave de fragmentación es un excelente índice para dirigir las solicitudes a los nodos correctos, ¿qué pasa con el resto de los índices que se definirán en mis tablas? Deseo que las solicitudes que hacen referencia a esos índices se entreguen también a los nodos correctos, de modo que solo un nodo procese la solicitud. Por lo que entiendo para este propósito, deben existir algunos nodos de índice centralizados. Entonces mi pregunta es si esta funcionalidad ya está presente en RDBMS como MYSQL o debería usar otros productos especiales.

Answer 1

responsabilidad: yo trabajo para ScaleBase, vivo y la respiración sharding todos los días ...

Yo aconsejaría aquí que si Fragmento de acuerdo a la columna A, por ejemplo, una columna con DONDE = xx va a ir a una solo shrad. DONDE columnB = xx tendrá que ir todos los fragmentos porque puede haber columnB = xx en todos ellos. A menos que columnA y columnB estén relacionados. Y entonces realmente necesita guardar la relación en una tabla de mapeo. Puedo decir que ejecutar todas las bases de datos puede ser súper rápido, necesita ejecutar en paralelo y fusionar resultados. En ScaleBase que permite la combinación de ORDER BY, GROUP BY, etc. No es fácil ...

Hey ver más información en mi blog: http://database-scalability.blogspot.com

Answer 2

Andrei, lo que usted está describiendo es exactamente cómo funciona la base de datos, donde Clustrix los datos y los índices se distribuyen automáticamente, luego las consultas se distribuyen entre los nodos. Clustrix "brings the query to the data" y tiene una arquitectura de nada compartido (por lo que no se necesita un índice centralizado). MySQL no tiene ninguna funcionalidad incorporada para computación distribuida, y si bien hay varias opciones de conexión, finalmente encontrarán límites de escala cuando se tocan los límites de los recursos centralizados.