Los Queries distribuidos tiene que tomar en cuenta todos los retos a los que se enfrenta la DB Distribuida para hacer hasta el más simple Query.

Normalmente nos enfrentamos en que tenemos todo en la misma maquina en la misma región en el mismo servidor o en la misma región también de Cloud y se puede tardar unos segundos.

Debo tener en cuenta todas esas variables para optimizar la forma en que hago los Queries, por eso es importante conocer primero la estructura que tiene mi DB Distribuida y una vez que tengo eso en mente empezar calcular todos estos costos añadidos que tiene el hacer un Query.

1. Vamos a tener un caso teórico en donde me enfrento a un Query que parece muy simple pero cuando voy tomando en cuenta todos los factores que se involucran a la hora de tomar una DB Distribuida puede que no sea tan simple.

Contamos con 3 Tablas:

• Cada Tupla tiene 25 Bytes (200 bits).
• El Query será: Obtener los números de proveedor de Bogotá que tienen repuestos de color rojo.
• P >< PR ><R = Unión de P con PR y PR con R.

Tenemos 3 Tablas: Proveedor, Repuestos y una Tabla transitiva Proveedor-Repuestos.

Proveedor cuenta con dos columnas de ID y Ciudad, y tiene 10.000 registros. Toda esta Data esta alojada en la Región A. Aplico la misma lógica a las otras dos Tablas.

SUPOSICIONES DE CARDINALIDAD

• Repuestos Rojos: 10
• Numero de pedidos hechos por proveedores de Bogotá 100.000

SUPOSICIONES DE COMUNICACION

• tasa de transferencia: 50.000 bits por segundo.
• Latencia de acceso: 0.1 s.

Las suposiciones de Comunicación son números arbitrarios para darme cuenta de que hay que tomar en consideración cuando hago un Query Distribuido.

FORMULA

• Retraso Total en la Comunicación = (Retraso Total de Acceso) + (Volumen Total de Datos / Tasa de Transferencia)
• Retraso Total en la Comunicación = (número de mensajes/10)+(número de bits/50.000)

Debido a que en una sola base de datos responder una misma pregunta puede tener múltiples soluciones con diferencias de ejecución en el rango de milisegundos. Pero en las bases de datos distribuidas dependiendo de en donde se encuentre la información físicamente, que información hay en cada región y que pregunta se quiere contestar, las diferentes formas de resolver la pregunta mediante una consulta SQL puede tener vastas diferencias en el tiempo de ejecución, como ejemplo algunas soluciones pudiesen llegar al rango de 5 horas para ejecutarse y otras solamente necesitando 0.10 segundos. La fórmula Anterior nos ayuda a proveer estos tiempos de respuesta.

POSIBLES SOLUCIONES:

Tenemos diversas soluciones

Cada estrategia resuelve de una manera o de otra el cómo podemos hacer el Query, como podemos tener toda la info junta.

Algunos tienen que ver con Joins no importa de zona geográfica, otros tienen que ver con mover tablas completas, otros con mover solo una parte de la tabla.

Aunque todos resuelven el problema, teniendo en cuenta la red de latencia, distribución geográfica, etc, puedo ver la disparidad de opciones que se tienen.

El truco no es saber cómo estructurar el Query (porque eso es muy fácil), sino en hacer que la información este en un solo lugar, ya que los Queries necesitan que la información esté junta. La opción 4 es la que lleva menos tiempo de ejecución, es mover los repuestos rojos (no todos) de la región actual B a la otra región A.

Analiza cual tabla tiene la menor cantidad de datos (columnas+tablas) Filtra esos registros donde sea menor cantidad Trae esos pocos registros a la misma región donde están la mayor cantidad de datos evitar realizar JOINs cuando se encuentran en zonas geográficamente diferentes.

RESPUESTAS DE OTROS ESTUDIANTES:

1. Analiza cual tabla tiene la menor cantidad de datos (columnas+tablas).
2. Filtra esos registros donde sea menor cantidad.
3. Trae esos pocos registros a la misma región donde están la mayor cantidad de datos.