Este método usa una fórmula matemática (una función hash) en la clave de fragmento para asignar datos. Por ejemplo, el sistema podría calcular el ID de usuario (módulo 4) para asignar un usuario a uno de los cuatro servidores.

Aunque las funciones hash ayudan a distribuir los datos de forma uniforme, solo aseguran una distribución uniforme si la clave de fragmentación tiene una cardinalidad alta y una baja desviación de frecuencia. Si eliges una clave de partición con un valor común, como "Apellido", donde "Pérez" aparece 1000 veces más que "García", la función hash enviará todos los registros de "Pérez" al mismo fragmento. Esto crea un "fragmento caliente" a pesar de usar una fórmula matemática.

Añadir nuevos servidores también es difícil con este método, ya que la fórmula cambia, lo que a menudo requiere que "vuelvas a fragmentar" o que muevas tus datos a través del nuevo clúster de servidores.

Los datos se asignan en función de intervalos de valores. Por ejemplo, puedes colocar los IDs de usuario del 1 al 1000 en el servidor A y los del 1001 al 2000 en el servidor B. Es muy intuitivo y resulta ideal para las consultas que necesitan leer una secuencia de datos (consultas de rango). La desventaja es que se crean "puntos calientes": si todos los usuarios nuevos se asignan al servidor B, este hará todo el trabajo mientras que el servidor A se mantiene inactivo.

Esta estrategia usa una tabla de consulta (un directorio) que registra exactamente qué fragmento contiene qué datos. Ofrece la mayor flexibilidad, ya que puedes mover datos entre fragmentos sin cambiar una fórmula. Sin embargo, esta tabla de consulta se convierte en un cuello de botella, ya que cada consulta debe comprobar primero el directorio, lo que añade latencia. Si el directorio falla, toda la base de datos se vuelve inaccesible.

La fragmentación geográfica asigna datos a servidores específicos en función de la ubicación física de un usuario. Por ejemplo, los datos de los usuarios de Francia se almacenan en servidores de la UE, mientras que los de los usuarios de EE. UU. se almacenan en servidores de Norteamérica. Esto reduce significativamente la latencia (velocidad) para los usuarios y ayuda a las empresas a cumplir las leyes de residencia de datos, como el RGPD.

A veces se denomina partición funcional y consiste en dividir los datos por función en lugar de por fila. Por ejemplo, puedes colocar todas las tablas "Perfil de usuario" en el servidor A y todas las tablas "Subida de fotos" en el servidor B. Aunque esto organiza los datos de forma lógica, es funcionalmente similar a una arquitectura de datos de microservicios y no resuelve el problema si una función específica (como Fotos) crece demasiado para un solo servidor.

La fragmentación es un tipo específico de partición horizontal en la que los fragmentos de datos se distribuyen en servidores completamente diferentes. De esta forma, se resuelven tanto los límites de capacidad de hardware (almacenamiento) como los cuellos de botella de rendimiento de escritura, ya que diferentes servidores pueden procesar escrituras simultáneamente.

• Fragmentación manual: en un entorno de fragmentación manual, el desarrollador o el administrador de la base de datos es el responsable de definir las claves de fragmentación, crear la infraestructura de cada fragmento y escribir la lógica para enrutar las consultas. Esto te permite controlar al detalle dónde se almacenan los datos. Sin embargo, esto requiere un mantenimiento considerable. Si un fragmento se hace demasiado grande, debes volver a fragmentar los datos manualmente, lo que implica mover millones de filas a nuevos servidores intentando minimizar el periodo de inactividad de la aplicación.
• Fragmentación automática: la fragmentación automática, que suele encontrarse en bases de datos NoSQL como Bigtable o en bases de datos SQL distribuidas como Spanner, gestiona la distribución de datos y tráfico automáticamente. El sistema monitoriza el tamaño de los datos y la carga de cada servidor. Si un fragmento específico se convierte en un "punto caliente" o crece demasiado, el motor de la base de datos lo divide automáticamente y mueve los datos a un servidor menos congestionado. De esta forma, se reduce la carga operativa de tu equipo y se asegura un rendimiento uniforme a medida que tu aplicación se escala.

La creación de particiones consiste en dividir una tabla grande en partes más pequeñas y fáciles de gestionar (por ejemplo, dividir una tabla de registros por meses), pero manteniéndolas en la misma instancia de servidor. Esto resuelve los problemas de almacenamiento, ya que facilita el archivado o la eliminación de datos antiguos sin que afecte al resto de la tabla. Sin embargo, no soluciona los problemas del servidor. Como todas las particiones siguen residiendo en una sola máquina, siguen compartiendo la misma CPU y RAM, lo que significa que la partición no puede ayudar si el servidor alcanza sus límites de rendimiento.

La replicación es el proceso de copiar toda la base de datos en varios servidores. Esta puede ser una buena opción para la disponibilidad de lectura, ya que si un servidor falla, otro puede tomar el relevo. Sin embargo, no ayuda a escalar las escrituras, ya que cada dato escrito debe copiarse en cada réplica, lo que limita la velocidad de escritura a la capacidad de una sola máquina.

Igualmente importante es que la mayoría de los modelos de replicación solo permiten un editor (el nodo principal) a la vez. Si intentas permitir que varios servidores acepten escrituras simultáneamente, corres el riesgo de que se produzcan conflictos de escritura, en los que dos servidores intentan actualizar el mismo registro con información diferente. Resolver estos conflictos es técnicamente difícil y puede provocar la pérdida o la incoherencia de los datos si no se gestionan mediante un sistema distribuido sofisticado.

Una base de datos distribuida, como Spanner, ofrece las ventajas de la fragmentación sin la sobrecarga manual. Estos sistemas están diseñados para funcionar en un clúster de máquinas desde el principio. Se encargan automáticamente de la distribución, el reequilibrio y la replicación de los datos de forma transparente. Algunos de estos sistemas tienen varios escritores y gestionan automáticamente los conflictos de escritura. Esto te permite escalar horizontalmente sin perder la coherencia de una base de datos relacional tradicional.