Esta mañana estaba revisando algunos feeds de Escalabilidad y Alta Disponibilidad y he encontrado un blog que me ha gustado bastante y al que por supuesto le doy mis dos semanas de rigor para ver si se mantiene en el GReader al pie del cañón.
Del post que he llegado vía High Scalability me ha gustado mucho la explicación de tres posibles soluciones a un problema típico con un cluster de BBDD particionado en fragmentos. El post surge en respuesta al comentario de un lector del blog en un post previo:
“… Let’s say I have shards that store proverbial invoices. Since each shard is a stand-alone db instance, it will have “invoices” table with auto_incremental PK. Each shard auto increments the PK value on its own and so values are not unique among shards. In such a case I cannot expose an invoice by its id. www.example.com/invoices/123 could return multiple invoices from multiple shards. Am I missing anything here? …”.
Básicamente, se aborda el problema de cómo gestionar identificadores únicos a nivel de cluster si tenemos n instancias independientes de BBDD cada una de ellas con tablas iguales (en este caso, se usa el ejemplo de invoices o “facturas”).
En How to Organize a Database Table’s Keys for Scalability propone tres formas de abordar el problema:
1.- La más simple. A través de una identificación por id de fragmento como parte de una primary key adicional al invoiceId (índice base del que se parte). Me ha gustado mucho el cómo quedan las URL´s aunque bien es cierto que tiene el problema de la relación entre URL y modelo de datos que no veo muy clara además de en efecto poder ser realmente caótico cuando quieres cruzar datos de diferentes fragmentos por problemas en las claves definidas como autonuméricas.
2.- Utilizar identificadores únicos universales (GUID) almacenados de forma comprimida (quitando guiones, …). El mismo autor es la que reconoce usar en los comentarios y a mi parecer quizá también sea la que me parece más limpia. Habría que evaluar en tiempo eso si qué porcentaje nos llevaría el codificar / decodificar estos elementos, pero tiene la ventaja de que no necesita conocer nada de la organización interna de la información a lo largo de los fragmentos.
3.- Hacer uso de las propiedades de algunos SGBD para a partir de algoritmos matemáticos simples, preparar un desplazamiento asociado a cada fragmento de forma que no colisiones con los identificadores de otros fragmentos. Es bastante dependiente del sistema subyacente e incluso diría que me parece una solución poco limpia. De esta forma a un fragmento le corresponderían por ejemplo los id´s (1,4, …), a otro (2, 5, …), … El ejemplo que se incluye con cuatro instancias es bastante revelador.
En los comentarios Jamie Hall realiza uno que tiene más que ver con la organización de los fragmentos en tu cluster de BBDD y que me parece muy interesante con las posibilidades de table partitioning que tienen los SGBD en sus versiones más actuales (no todos xD – MySQL, Oracle, …).
“The simplest answer is to include whatever is the basis for the logical segmentation of your shards as part of your lookups. For example, you can choose to shard by customers, with a million customers on each shard, each with the invoices belonging to those customers. To look up an invoice all you need is a customer ID and an invoice ID, the combination of which is unique across all your shards. You can have a master lookup table for determining which customers are on which shards, or use a simpler, yet ultimately less flexible technique based on a hash of the customer ID or whatever”.
La combinación de una buena elección de metodología de particionado y de sus claves sin duda ofrece un incremento de rendimiento espectacular.
Aconsejo enormemente la lectura del artículo.
Bueno otra NocheBuena más.