Fragmento (arquitectura de base de datos)

Un fragmento de base de datos , o simplemente un fragmento , es una partición horizontal de datos dentro de una base de datos o motor de búsqueda . Cada fragmento puede estar alojado en una instancia de servidor de base de datos independiente para distribuirse entre varios servidores.

Algunos datos de una base de datos pueden permanecer presentes en todos los fragmentos, ^{[ a ]} mientras que otros datos se almacenan en un solo fragmento. En tales casos, cada fragmento actúa como la única fuente para su subconjunto de datos. ^{[ 1 ]}

El particionamiento horizontal es un principio de diseño de bases de datos mediante el cual las filas de una tabla se almacenan por separado, en lugar de dividirse en columnas (como en la normalización y el particionamiento vertical , en distintos grados). Cada partición forma parte de un fragmento, que a su vez puede estar ubicado en un servidor de base de datos independiente o en una ubicación física distinta.

La partición horizontal de datos ofrece numerosas ventajas. Al dividirse las tablas y distribuirse en varios servidores, se reduce el número total de filas en cada tabla de cada base de datos. Esto disminuye el tamaño del índice , lo que generalmente mejora el rendimiento de las búsquedas. Un fragmento de la base de datos puede ubicarse en hardware independiente, y varios fragmentos pueden ubicarse en varias máquinas. Esto permite distribuir una base de datos entre un gran número de máquinas, lo que puede mejorar significativamente el rendimiento. Además, si el fragmento de la base de datos se basa en alguna segmentación real de los datos (por ejemplo,  clientes europeos frente a clientes estadounidenses), es posible inferir la pertenencia al fragmento adecuado de forma fácil y automática, y consultar solo el fragmento relevante. ^{[ 2 ]}

En la práctica, el particionamiento es complejo. Si bien se ha implementado durante mucho tiempo mediante codificación manual (especialmente cuando las filas presentan una agrupación evidente, como en el ejemplo de región de clientes mencionado anteriormente), este enfoque suele ser inflexible. Existe el deseo de automatizar el particionamiento, tanto mediante la incorporación de código que lo respalde como mediante la identificación de candidatos para particionarse por separado. El hash consistente es una técnica utilizada en el particionamiento para distribuir grandes cargas entre múltiples servicios y servidores más pequeños. ^{[ 3 ]}

Cuando se utiliza la computación distribuida para separar la carga entre varios servidores (ya sea por razones de rendimiento o fiabilidad), un enfoque de fragmentación también puede resultar útil. En la década de 2010, la fragmentación de la capacidad de ejecución , así como la fragmentación de datos más tradicional , surgieron como un enfoque potencial para abordar los desafíos de rendimiento y escalabilidad en las cadenas de bloques . ^{[ 4 ] [ 5 ]}

Trabajos académicos recientes han propuesto protocolos como Cerberus para abordar la atomicidad entre fragmentos mediante el entrelazado del consenso a través de múltiples fragmentos, lo que permite que las transacciones afecten a múltiples particiones simultáneamente sin requerir un bloqueo global. ^{[ 6 ]}

El particionamiento horizontal divide una o más tablas por filas, generalmente dentro de una única instancia de un esquema y un servidor de base de datos. Puede ofrecer una ventaja al reducir el tamaño del índice (y, por lo tanto, el esfuerzo de búsqueda), siempre que exista una forma obvia, robusta e implícita de identificar en qué partición se encontrará una fila en particular, sin tener que buscar primero en el índice; por ejemplo, el caso clásico de las tablas ' CustomersEast' y ' ', donde un código postal ya indica dónde se encontrará una fila.CustomersWest

El particionamiento amplía este enfoque. Divide la tabla o tablas relevantes de la misma manera, pero lo hace entre varias instancias del esquema. Una ventaja es que la carga de búsqueda para la tabla particionada de gran tamaño se puede distribuir entre varios servidores (lógicos o físicos), en lugar de solo entre varios índices en un mismo servidor lógico.

La división de fragmentos en múltiples instancias aisladas requiere más que una simple partición horizontal. Las ganancias esperadas en eficiencia se verían reducidas si para consultar la base de datos fuera necesario acceder a múltiples instancias solo para recuperar una tabla de dimensiones simple . Por lo tanto, más allá de la partición, el sharding implica distribuir tablas grandes y particionables entre servidores, mientras que las tablas más pequeñas se replican completamente en cada servidor. ^{[ 7 ]}

Esta es también la razón por la que el sharding está relacionado con una arquitectura sin recursos compartidos : una vez shardeado, cada fragmento puede residir en una instancia de esquema lógico, un servidor de base de datos físico, un centro de datos o una región geográfica separados. El sharding tiene como objetivo minimizar la necesidad de acceso entre fragmentos mediante la partición de datos en fragmentos independientes. ^{[ 8 ]}

Esto facilita la replicación en múltiples servidores (el particionamiento horizontal simple no lo hace). También es útil para la distribución mundial de aplicaciones, donde los enlaces de comunicación entre centros de datos podrían convertirse en un cuello de botella. ^{[ 9 ]}

También se requiere algún mecanismo de notificación y replicación entre las instancias del esquema, de modo que las tablas no particionadas permanezcan tan sincronizadas como lo requiera la aplicación. Esta es una decisión arquitectónica compleja en sistemas fragmentados: los enfoques van desde hacer que estas tablas sean efectivamente de solo lectura (con actualizaciones poco frecuentes y por lotes), hasta tablas replicadas dinámicamente (a costa de reducir algunos de los beneficios de distribución del fragmentado), y muchas opciones intermedias. ^{[ 10 ]}

• Altibase proporciona una arquitectura de particionamiento combinada (del lado del cliente y del servidor) transparente para las aplicaciones cliente.
• Apache HBase admite el particionamiento automático. ^{[ 11 ]}
• Las herramientas de Azure SQL Database Elastic Database admiten el particionamiento para permitir el escalado horizontal y vertical del nivel de datos de una aplicación. ^{[ 12 ]}
• ClickHouse , un sistema de gestión de bases de datos OLAP de código abierto, admite el particionamiento (sharding).
• Couchbase admite la fragmentación automática y transparente.
• CUBRID admite la fragmentación desde la versión 9.0.
• La función de particionamiento de datos de Db2 (MPP) , una función de particionamiento de base de datos sin recursos compartidos, se ejecuta en nodos separados.
• DRDS (Servicio de base de datos relacional distribuida) de Alibaba Cloud admite la fragmentación de bases de datos y tablas, ^{[ 13 ]} y se ha utilizado para eventos a gran escala como el Día de los Solteros . ^{[ 14 ]}
• Elasticsearch , un servidor de búsqueda empresarial, admite el sharding. ^{[ 15 ]}
• eXtreme Scale es un almacén de datos clave/valor en memoria entre procesos (un almacén de datos NoSQL ) que utiliza el particionamiento para lograr escalabilidad entre procesos tanto para datos como para el procesamiento paralelo al estilo MapReduce . ^{[ 16 ]}
• Hibernate admite el sharding, pero ha tenido poco desarrollo desde 2007. ^{[ 17 ] [ 18 ]}
• IBM Informix ha sido compatible con el particionamiento desde la versión 12.1 xC1 como parte de la tecnología MACH11. Informix 12.10 xC2 añadió compatibilidad total con los controladores de MongoDB, lo que permite una combinación de tablas relacionales regulares y colecciones NoSQL, manteniendo las propiedades de particionamiento, conmutación por error y ACID. ^{[ 19 ] [ 20 ]}
• Kdb+ admite la fragmentación desde la versión 2.0.
• MariaDB Spider, un motor de almacenamiento, admite federación de tablas, fragmentación, transacciones XA y fuentes de datos ODBC. Se ha incluido en el servidor MariaDB desde la versión 10.0.4. ^{[ 21 ]}
• MonetDB , un almacén de columnas de código abierto , introdujo el particionamiento de solo lectura en su versión de julio de 2015. ^{[ 22 ]}
• MongoDB ha admitido el sharding desde la versión 1.6. ^{[ 23 ]}
• MySQL Cluster admite la fragmentación automática y transparente en nodos estándar, lo que permite escalar las consultas de lectura y escritura sin necesidad de realizar cambios en la aplicación. ^{[ 24 ]}
• MySQL Fabric (parte de las utilidades de MySQL) admite el sharding. ^{[ 25 ]}
• Fragmentos de Oracle Database desde la versión 12c Release 2 y en una sola línea: Combinación de las ventajas del fragmentado con las capacidades bien conocidas de Oracle Database multimodelo lista para empresas. ^{[ 26 ]}
• Oracle NoSQL Database admite la fragmentación automática y la expansión elástica y en línea de los clústeres.
• OrientDB admite la fragmentación desde la versión 1.7.
• Solr , una plataforma de búsqueda empresarial, admite el sharding. ^{[ 27 ]}
• ScyllaDB utiliza la fragmentación por núcleo dentro de un servidor y en todos los nodos de un clúster.
• Spanner , una base de datos distribuida desarrollada por Google, se fragmenta en múltiples máquinas de estado Paxos para escalar a un gran número de máquinas, centros de datos y filas. ^{[ 28 ]}
• SQLAlchemy ORM , un mapeador de datos para los fragmentos del lenguaje de programación Python . ^{[ 29 ]}
• SQL Server ha admitido la fragmentación desde SQL Server 2005 mediante el uso de herramientas de terceros. ^{[ 30 ]}
• Teradata comercializa un sistema de gestión de bases de datos masivamente paralelas como un almacén de datos .
• Vault , un diseño de criptomoneda , utiliza el sharding para reducir los datos necesarios para unirse a la red y verificar las transacciones, mejorando la escalabilidad. ^{[ 31 ]}
• Vitess , un sistema de agrupación de bases de datos de código abierto, admite la fragmentación para MySQL y es un proyecto de la Cloud Native Computing Foundation . ^{[ 32 ]}
• ShardingSphere es un sistema de agrupación de bases de datos que proporciona fragmentación de datos, transacciones distribuidas y gestión de bases de datos distribuidas, y es un proyecto de la Apache Software Foundation (ASF). ^{[ 33 ]}

La fragmentación de una tabla de base de datos antes de su optimización local puede introducir una complejidad innecesaria. Generalmente, se recomienda la fragmentación cuando otras estrategias de optimización han resultado insuficientes. ^{[ 34 ]} La complejidad adicional de la fragmentación de bases de datos puede generar varios problemas potenciales. ^{[ 35 ]}

• Complejidad de SQL: Es posible que los desarrolladores necesiten escribir consultas SQL más complejas para manejar la lógica de fragmentación.
• Requisitos de software adicionales: El software que particiona, equilibra, coordina y mantiene la integridad de los datos puede fallar o introducir errores.
• Punto único de fallo : La corrupción o el fallo de una partición debido a problemas de red, hardware o sistema puede afectar a la integridad de todo el conjunto de datos.
• Complejidad del servidor de conmutación por error : Los servidores de conmutación por error deben mantener copias de todas las particiones de la base de datos.
• Complejidad de las copias de seguridad : Las copias de seguridad de la base de datos de cada fragmento deben coordinarse con las copias de seguridad de los demás fragmentos.
• Complejidad operativa: Tareas como agregar o eliminar índices, modificar columnas o alterar el esquema se vuelven más difíciles en un entorno fragmentado.

En el contexto de las bases de datos, se cree que el término "shard" deriva de una de dos fuentes: "A System for Highly Available Replicated Data" de Computer Corporation of America , ^{[ 36 ]} que utilizaba hardware redundante para facilitar la replicación de datos en lugar de la partición horizontal, o el MMORPG Ultima Online de 1997. ^{[ 37 ] [ 38 ]}

Richard Garriott , creador de Ultima Online , recordó que el término se originó durante la producción del juego, específicamente al crear un sistema ecológico virtual autorregulado. Los jugadores podían interactuar y recolectar recursos del juego a través de internet, lo que alteraba el equilibrio del sistema. ^{[ 38 ]} Para solucionar esto, el equipo de desarrollo dividió la base global de jugadores en múltiples sesiones e introdujo parte de la conexión ficticia de Ultima Online con el final de Ultima I: The First Age of Darkness , donde la derrota de su antagonista Mondain también condujo a la creación de "fragmentos" del multiverso . Esta modificación proporcionó al equipo de Garriott la base ficticia necesaria para justificar la creación de copias del entorno virtual. La característica se eliminó posteriormente tras varios meses de pruebas. ^{[ 38 ]}

• Índice de rango de bloques
• Arquitectura sin elementos compartidos

• Fragmentación de datos JSON de Informix