bibliografia:
Se hace una replica de la main DB varias veces.
✅ High Availability (ya que esta replicado en varios servidores, por si falla 1)
Tipos:
- Lider -> Follower: se guarda solo en la lider, luego se replica en otras. Se lee en cualquiera
- Lider <-> Lider: se lee y guarda en cualquiera. Aca se generan conflictos y tenes que setear mecanismos para resolverlos.
- Creo que tambien hay una que es Liderless (dynamoDB) https://youtu.be/bI8Ry6GhMSE?si=ZL68Kau2_Y31lL4X&t=231
Async vs Sync:
Si es asincrona: Puede haber una request a la 1, y esta hace una request a la 2, pero la 1 ya devuelve un resultado. Mientras se procesa la 2. Mientras tanto hay una inconsistencia.
- mejora el read performance y availavility.
mas avanzado: https://www.youtube.com/watch?v=bI8Ry6GhMSE solucionar si un leader se cae, etc. basicamente, tenes 2 db leaders por si una se cae. Porque sino creo que un follower es promocionado a leader cuando uno se cae, y no se si esta bueno.
Dividir la DB en DB mas pequeñas. (por ej por user_id, como hace Instagram) Se diferencia a particion en que sharding, cada shard es una DB completa.
Una fisical shard (el server donde se alojan), pueden contener varias logica shards (que seria las particiones/data chunks)
Tiene una shard key, la cual es la condicion por la que se asigna data a los shards.
en sql tenes que implementar la sharding logic por tu cuenta. Asi es la naturaleza de las DB relacionales.
La ultima "geo sharding" ademas tiene el beneficio que podes situar el server en una zona mas cercana para que tenga menos ping, lo malo es que no tiene una distribucion equitativa de data.
- buena distribucion (buena seleccion shard key)
- pensar en todos los valores posibles = cardinality.
- considerar la frecuencia, en base a los valores que mas se van a usar (de la shard key)
- tener en cuenta del rate of change de shard key:
si dividimos usuarios x cantidad de compras.
el shard que tenga a los usuarios con mas cantidad de compras, va a seguir acumulando. (por ej si tenemos rows con compras del mes del usuario o algo asi)
o capaz si tengo un timestamp que acumula un monton, (ej desde el 2024 y no creo mas condiciones)?
se pueden usar en combinación
"migrate" -> Mueve data de un shard a otro? para mantener el balance de la cantidad de data.
"split" -> divide el key range en 2. (crea 2 shards de uno)