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

Si bien las funciones hash ayudan a distribuir los datos de manera coherente, solo garantizan una distribución uniforme si la clave de fragmentación tiene una alta cardinalidad y un bajo sesgo de frecuencia. Si eliges una clave de fragmentación con un valor común, como un "apellido" en el que "Smith" aparece 1,000 veces más que "Pyne", la función hash enviará todos los registros de "Smith" al mismo fragmento. Esto crea un "fragmento activo" a pesar de que se usa una fórmula matemática.

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

Los datos se asignan en función de los rangos de valores. Por ejemplo, podrías colocar los IDs de usuario del 1 al 1,000 en el servidor A y del 1,001 al 2,000 en el servidor B. Esto es muy intuitivo y excelente 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 estará inactivo.

Esta estrategia usa una tabla de búsqueda (un directorio) que rastrea exactamente qué fragmento contiene qué datos. Ofrece la mayor flexibilidad porque puedes mover datos entre fragmentos sin cambiar una fórmula. Sin embargo, esta tabla de búsqueda se convierte en un cuello de botella, ya que cada consulta debe verificar el directorio primero, lo que agrega latencia. Si falla el directorio, 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 con las leyes de residencia de datos como el RGPD.

A veces llamada partición funcional, esto implica dividir los datos por atributo en lugar de por fila. Por ejemplo, puedes colocar todas las tablas de "Perfil de usuario" en el servidor A y todas las tablas de "Carga de fotos" en el servidor B. Si bien 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 el que las piezas de datos se distribuyen en servidores completamente diferentes. Esto resuelve los límites de capacidad de hardware (almacenamiento) y 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 responsable de definir las claves de fragmento, crear la infraestructura para cada fragmento y escribir la lógica para enrutar las consultas. Esto te brinda un control detallado sobre la ubicación exacta de los datos. Sin embargo, requiere un mantenimiento significativo. Si una partición se vuelve demasiado grande, debes volver a particionar los datos de forma manual, lo que implica mover millones de filas a servidores nuevos mientras intentas minimizar el tiempo 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 bases de datos SQL distribuidas como Spanner, controla la distribución de datos y tráfico automáticamente. El sistema supervisa el tamaño de los datos y la carga en cada servidor. Si una partición específica se convierte en un "punto activo" o crece demasiado, el motor de base de datos divide automáticamente la partición y mueve los datos a un servidor menos congestionado. Esto reduce la carga operativa de tu equipo y ayuda a garantizar un rendimiento coherente a medida que se escala tu aplicación.

La partición implica dividir una tabla grande en partes más pequeñas y fáciles de administrar (como dividir una tabla de registros por mes), pero mantenerlas en la misma instancia de servidor. Esto resuelve los problemas de almacenamiento, ya que facilita el archivo o el borrado de datos antiguos sin afectar al resto de la tabla. Sin embargo, no soluciona los problemas del servidor. Como todas las particiones aún residen 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; si un servidor falla, otro puede tomar el control. Sin embargo, no ayuda con el escalamiento de escritura, 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, la mayoría de los modelos de replicación solo permiten un "escritor" (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 coherencia de los datos si no se maneja con un sistema distribuido sofisticado.

Una base de datos distribuida, como Spanner, proporciona los beneficios 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. Manejan automáticamente la distribución, el reequilibrio y la replicación de datos de forma transparente. Algunos de estos sistemas tienen varios escritores y manejan automáticamente los conflictos de escritura. Esto te permite escalar horizontalmente mientras mantienes la coherencia de una base de datos relacional tradicional.