Sharding de base de datos en SQL Azure

- January 22, 2010

SQL Azure permite crear múltiples bases de datos de forma sencilla y rápida. Para poder aumentar la escalabilidad de las aplicaciones es necesario poder aumentar la capacidad de manejo de datos de forma casi lineal. Para poder lograr esto podemos recurir a la capacidad de creación dinámica de base de datos en SQL Azure y de esa forma poder distribuir los datos de una única base de datos en múltiples bases de datos, esta técnica es conocida como Database Sharding.

Existen diferentes técnicas para hacer Database Sharding entre estas están:

Particionamiento basado en rangos. En esta técnica se divide una única tabla en varios servidores, para esto se debe utilizar un algoritmo que permita dividir los datos de forma uniforme y predicible. El criterio para dividir debe procurar que la división de los datos sea balanceada, por ejemplo si se divide por estado entonces podría que un estado tenga más datos que otro y la división no será balanceada.
Particionamiento vertical. Esta técnica implica asignar o almacenar tablas grandes en base de datos distintas, por ejemplo, una BD tiene la tabla de clientes, otra BD tiene la tabla de órdenes y otra BD la tabla de imágenes. En esta técnica el problema surge si la tabla de clientes crece mucho, entonces en este caso deberemos utilizar particionamiento por rangos.
Particionamiento basados en llaves artificiales o hash. En este caso uno o más atributos o columnas de la tabla son utilizados en una función de hash que permite asignar una llave con base de la cual se hace la división de los datos. El único detalle a considerar con esta técnica es que tenemos que saber de antemano la cantidad de base de datos que deseamos crear ya que es un parámetro utilizado en la función de hash.
Pariticionamiento dinámico. Esta técnica también conocida como particionamiento por directorios implica la creación de una función del tipo ObtenerServidorDe, esto significa que en la capa de acceso a datos se llama a esta función para determinar en cual base de datos se encuentra el registro que deseamos obtener. Esta técnica es la más dinámica de todas puesto que podemos agregar o quitar bases de datos sin que se afecte al resto de la arquitectura de la aplicación.
Particionamiento aleatorio. Similar al particionamiento dinámico con la única diferencia de que utiliza algoritmos aleatorios para asignar un registro a una base de datos determinada.

Un ejemplo de pseudocódigo de particionamiento dinámico sería el siguiente:

string connectionString = ObtenerServidorDe(idOrden);

SqlConnection conn = new SqlConnection (connectionString);

conn.Open();

SqlCommand cmd = new SqlCommand("….”);

Algunas consideraciones al utilizar el Sharding son las siguientes:

Cómo manejar la integridad referencial. Debido a que no se soporta integridad referencial entre servidores, es necesario que la capa de acceso a datos realice las verificaciones de integridad referencial, aunque esto implica más código y tiempo de desarrollo, nos asegura la integridad de los datos.
Rebalanceo de particionamiento. Se puede dar el caso de que en primera instancia se utiliza un modelo de particionamiento pero después hay que cambiarlo, en este caso la técnica de particionamiento dinámico es la más factible, aunque es un punto único de fallo, lo más recomendado es utilizar un Azure Worker Role para implementar este tipo de particionamiento.
Consultas entre tablas relacionados. Al momento de utilizar sharding ya no será posible realizar consultas que unan tablas en distintas base de datos, para hacer esto se pueden utilizar tres técnicas: la primera implica que todas las consultas complejas deben eliminarse por consultas simples que accesan una única tabla y los joins se hacen a nivel lógico en la capa de acceso a datos, la segunda implica desnormalizar las tablas para que se puedan hacer consultas desde una sola tabla, la tercer técnica es utilizar tablas de consolidación. En las tablas de consolidación todas las tablas individuales están en una BD distinta, pero para aquellas consultas que necesitan hacer búsquedas sobre todos los registros, se crea una tabla resumen en otra bd que contine todos los registros de todos los shards, aunque esta técnica permite hacer búsquedas sobre todos los registros, implica moficar la capa de acceso a datos para que le de mantenimiento a las talbas individuales y las tablas consolidadas lo cual aumenta la complejidad de la aplicación.

Debido a que la aplicación de Sharding tiene ventajas y desventajas es necesario seguir algunos principios:

No todas las tablas deben ser consideradas para Sharding, antes de implementar una estrategia de Sharding es necesario elegir cuales son las tablas candidatas para particionamiento físico. Estas tablas candidatas son aquellas que crecen mucho en nuestro sistema y que posible dividir en varias bases de datos sin poner mucho estres u overhead en la capa de acceso a datos
En algunas ocasiones es mejor utilizar Windows Azure Storage que SQL Storage, por ejemplo, las imágenes y videos es mejor utilizarlas en Windows Azure Storage

Saludos,

Ing. Eduardo Castro Martinez, PhD – Microsoft SQL Server MVP

http://mswindowscr.org

http://comunidadwindows.org

Costa Rica

Technorati Tags: SQL Server

LiveJournal Tags: SQL Server

del.icio.us Tags: SQL Server

http://ecastrom.blogspot.com

http://ecastrom.wordpress.com

http://ecastrom.spaces.live.com

http://universosql.blogspot.com