Es una colección de múltiples DB separadas físicamente y que se comunican mediante una red informática.

Hay una parte en Colombia, otra en EEUU, Japón, Australia, México y en todas partes se conectan a través de internet. Un estilo de red P2P.

VENTAJAS

  1. DESARROLLO MODULAR Podemos destinar cada una a diferentes usos o diferentes Usuarios. A veces es mejor separar los usuarios de EEUU con los de México y eso aumenta el tiempo de respuesta. En vez de pensar una Base Datos como un conjunto, mejor hacemos módulos para cada país y la separamos.
  2. INCREMENTA LA CONFIABILIDAD Al estar especializada a una zona geográfica nos incrementa velocidad y confiabilidad de las respuestas.
  3. MEJORA EL RENDIMIENTO Buscamos una DB que este más cerca. Los estudiantes de México de Platzi es solo un subconjunto del total.
  4. MAYOR DISPONIBILIDAD
  5. MAYOR RAPIDEZ EN RESPUESTA

DESVENTAJAS

  1. MANEJO DE SEGURIDAD Cada Servidor debemos blindarlo, en cada zona debemos pensar en su Seguridad en cuanto a redes y arquitectura.
  2. COMPLEJIDAD DEL PROCESAMIENTO Si quiero ver Data de EEUU, México, Colombia al tiempo, será complicado ya que NO se encuentra dentro del mismo servidor, sino que están Distribuidos.
  3. INTEGRIDAD DE DATOS MAS COMPLEJA
  4. COSTO Debemos proteger cada Servidor de forma individual, entre más operaciones abramos en otros lados los Costos aumentaran.

HOMOGENEAS Y HETEROGENEAS

  1. HOMOGENEAS Son las que tienen el mismo RDBMS y OS. La DB de EEUU y Perú están bajo las misma Distribución de Linux, ambas usan Postgre con la misma versión, y el modelado de Datos en global es el mismo.
  2. HETEROGENEAS Varia algo de lo anterior, una corre en Postgre en Linux y otra en Windows Server. Una en SQL y otra en NoSQL y aun así tienen cierta conexión donde se sincronizan Datos. El modelo de Datos debe ser más sutil a la hora de planear mi Estructura de DB, una tiene una parte de la estructura y en la otra tengo otra parte de la Estructura.

ARQUITECTURAS

  1. CLIENTE - SERVIDOR Es la más Clásica. Tenemos un DB principal y tenemos varias DB que sirven como clientes o esclavos que tratan de operar datos en la DB principal.
  2. P2P Todos los nodos en la red de la DB distribuida son iguales y se hablan como iguales. Se organizan entre ellas sin tener que responder a una sola Entidad que sea coordinadora de las demás.
  3. MULTIMANEJADOR DE DB MongoDB conectado a PostgreSQL conectado a MySQL conectado a Firestore, etc.

ESTRATEGIAS DE DISEÑO

  1. TOP DOWN Configuro de Arriba hacia Abajo dependiendo de mis necesidades. Quiero arriba un Coordinador que sea un Servidor de tal tipo, y para abajo quiero tres instancias de PostgreSQL, una de MongoDB y que se conecten a través de esto.
  2. BOTTOM UP Hacer un DB Distribuida con algo que ya existe. Tratar de construir encima de lo que ya existe, la infraestructura para convertirla en una DB Distribuida. La DB de EEUU y México ya están corriendo, están en producción, No conviene empezar de cero o hacer migraciones, y mejor unimos esas dos DB.

ALMACENAMIENTO DISTRIBUIDO

Al estar guardando los Datos en diferentes localizaciones geográficas, físicamente tiene algunas implicaciones:

  1. FRAGMENTACION Que Datos van en donde, quiero tener toda la información en todos lados, o mejor todo fragmentado los de EEUU en EEUU y los de México en México.
  2. REPLICACION Tengo los mismos Datos en todas las DB No importa donde estén.
  3. DISTRIBUCION Pensar cómo se va a pasar la Data entre una DB y otra, o una parte de la DB y otra. Tiene que ver con Networking, tiempos, latencia, etc.

FRAGMENTACION (SHARDING)

  1. HORIZONTAL (Tuplas) Partir la Tabla en diferentes pedazos Horizontales. Si tengo una sección destinada a EEUU, Todos esos Rows que dicen EEUU se van a EEUU, los de Canadá se van a Canadá, etc.
  2. VERTICAL (Columnas) Tal vez me sirve tener los Datos personales en un lado de la DB en una de esas instancias y todos los demás Datos tenerlos en otra instancia distinta.
  3. MIXTA Tengo algunas columnas y Rows en un lugar, y algunas columnas y Rows en otro lugar.

REPLICACION

  1. COMPLETA Toda la DB siempre está en varias versiones a lo largo del planeta, toda la información esta igualita en todas las instancias de DB.
  2. PARCIAL Algunos Datos están compartidos y replicados en varias zonas geográficas.
  3. SIN REPLICACION No replico nada de los Datos, cada instancia está completamente separada y no tiene que estarse hablando para sincronizar Datos entre ellas.

DISTRIBUCION DE DATOS

  1. CENTRALIZADA Cuando la distribuyo desde un punto Central a todas las demás.
  2. PARTICIONADA Ya esta partida en las diversas zonas geográficas y se comparten información entre ellas.
  3. REPLICADA Tener la misma información en todas y entre ellas se hablan para siempre tener la misma versión.