stringtranslate.com

Shard (arquitectura de base de datos)

Un fragmento de base de datos , o simplemente un fragmento , es una partición horizontal de datos en una base de datos o un motor de búsqueda . Cada fragmento se almacena en una instancia de servidor de base de datos independiente para distribuir la carga.

Algunos datos de una base de datos permanecen presentes en todos los fragmentos, [a] pero otros aparecen solo en un único fragmento. Cada fragmento (o servidor) actúa como la única fuente para este subconjunto de datos. [1]

Arquitectura de base de datos

La partición horizontal es un principio de diseño de bases de datos según el cual las filas de una tabla de base de datos se mantienen por separado, en lugar de dividirse en columnas (que es lo que hacen la normalización y la partición vertical , en diferentes grados). Cada partición forma parte de un fragmento, que a su vez puede estar ubicado en un servidor de base de datos o ubicación física independiente.

El método de particionamiento horizontal tiene numerosas ventajas. Dado que las tablas se dividen y distribuyen en varios servidores, se reduce el número total de filas de cada tabla en cada base de datos. Esto reduce el tamaño del índice , lo que generalmente mejora el rendimiento de la búsqueda. Un fragmento de base de datos se puede colocar en un hardware separado y varios fragmentos se pueden colocar en varias máquinas. Esto permite una distribución de la base de datos en una gran cantidad de máquinas, lo que mejora enormemente el rendimiento. Además, si el fragmento de base de datos se basa en alguna segmentación del mundo real de los datos (por ejemplo, clientes europeos frente a clientes estadounidenses), entonces puede ser posible inferir la membresía apropiada del fragmento de manera fácil y automática, y consultar solo el fragmento relevante. [2]

En la práctica, la fragmentación es compleja. Aunque se ha realizado durante mucho tiempo mediante codificación manual (especialmente cuando las filas tienen una agrupación obvia, como en el ejemplo anterior), esto suele ser inflexible. Existe el deseo de admitir la fragmentación automáticamente, tanto en términos de agregar soporte de código para ella como para identificar candidatos que se fragmentarán por separado. El hash consistente es una técnica que se utiliza en la fragmentación para distribuir grandes cargas entre varios servicios y servidores más pequeños. [3]

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

En comparación con la partición horizontal

La partición horizontal divide una o más tablas por fila, 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, sólida e implícita de identificar en qué partición se encontrará una fila en particular, sin necesidad de buscar primero en el índice, por ejemplo, el ejemplo clásico de las tablas ' CustomersEast' y ' CustomersWest', donde su código postal ya indica dónde se encontrarán.

La fragmentación va más allá de esto. Particiona las tablas problemáticas de la misma manera, pero lo hace en varias instancias del esquema. La ventaja obvia sería que la carga de búsqueda para la tabla particionada grande ahora se puede dividir en varios servidores (lógicos o físicos), no solo en varios índices en el mismo servidor lógico.

Dividir fragmentos en varias instancias aisladas requiere algo más que una simple partición horizontal. Las ganancias esperadas en eficiencia se perderían si la consulta de la base de datos requiriera consultar varias instancias solo para recuperar una tabla de dimensiones simple . Más allá de la partición, la fragmentación divide tablas particionables grandes en los servidores, mientras que las tablas más pequeñas se replican como unidades completas. [ Aclaración necesaria ]

Esta es también la razón por la que la fragmentación está relacionada con una arquitectura de nada compartido : una vez fragmentada, cada fragmento puede vivir en una instancia de esquema lógico/servidor de base de datos físico/ centro de datos / continente totalmente independiente . No hay necesidad continua de conservar el acceso compartido (entre fragmentos) a las otras tablas no particionadas en otros fragmentos. [ cita requerida ]

Esto facilita la replicación entre varios servidores (la partición horizontal simple no lo hace). También es útil para la distribución mundial de aplicaciones, donde los enlaces de comunicaciones entre centros de datos de otro modo serían un cuello de botella. [ cita requerida ]

También se requiere algún mecanismo de notificación y replicación entre instancias de esquema, de modo que las tablas no particionadas permanezcan tan sincronizadas como lo exige la aplicación. Esta es una elección compleja en la arquitectura de los sistemas fragmentados: los enfoques varían desde hacer que sean efectivamente de solo lectura (las actualizaciones son poco frecuentes y se realizan por lotes), hasta tablas replicadas dinámicamente (a costa de reducir algunos de los beneficios de distribución de la fragmentación) y muchas opciones intermedias. [ cita requerida ]

Implementaciones

Desventajas

La fragmentación de una tabla de base de datos antes de que se haya optimizado localmente provoca una complejidad prematura. La fragmentación se debe utilizar solo cuando todas las demás opciones de optimización son inadecuadas. [ ¿según quién? ] La complejidad introducida por la fragmentación de la base de datos provoca los siguientes problemas potenciales: [ cita requerida ]

Etimología

En un contexto de base de datos, la mayoría reconoce que el término "fragmento" probablemente se deriva de una de dos fuentes: "Un sistema para datos replicados de alta disponibilidad" de Computer Corporation of America , [28] que utilizó hardware redundante para facilitar la replicación de datos (en oposición a la partición horizontal); o el videojuego MMORPG Ultima Online de 1997 aclamado por la crítica , que estableció 8 récords mundiales Guinness y fue designado por Time como uno de los 100 mejores videojuegos producidos de todos los tiempos. [29] [30]

Richard Garriott , creador de Ultima Online , recuerda que el término se acuñó durante la fase de producción cuando intentaron crear un sistema de ecología virtual autorregulado, mediante el cual los jugadores pueden aprovechar el nuevo acceso a Internet (una tecnología revolucionaria en ese momento) para interactuar y recolectar recursos del juego. [30] Aunque la ecología virtual funcionó como se esperaba durante las pruebas internas, su equilibrio natural falló "casi instantáneamente" debido a que los jugadores mataron a toda la vida silvestre viva en el área jugable más rápido de lo que podía operar el sistema de generación. El equipo de producción de Garriott intentó mitigar este problema separando la base de jugadores global en sesiones separadas y reescribiendo 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. Sin embargo, el fuerte ascenso del juego a la aclamación crítica también significó que el nuevo sistema de ecología virtual del multiverso también se vio rápidamente abrumado. Después de varios meses de pruebas, el equipo de Garriott decidió abandonar la característica por completo y despojó al juego de su funcionalidad. [30]

Hoy en día, el término "fragmento" se refiere a la implementación y uso de hardware redundante en sistemas de bases de datos. [ cita requerida ]

Véase también

Notas

  1. ^ Normalmente, datos "de apoyo", como tablas de dimensiones

Referencias

  1. ^ Sadalage, Pramod J.; Fowler, Martin (2012). "4: Modelos de distribución". NoSQL Distilled . Pearson Education. ISBN 978-0321826626.
  2. ^ Rahul Roy (28 de julio de 2008). "Shard: un diseño de base de datos".
  3. ^ Ries, Eric. "Fragmentación para startups".
  4. ^ Wang, Gang; Shi, Zhijie Jerry; Nixon, Mark; Han, Song (21 de octubre de 2019). "SoK". Actas de la 1.ª Conferencia de la ACM sobre avances en tecnologías financieras . págs. 41–61. doi :10.1145/3318041.3355457. ISBN 9781450367325.S2CID204749727  .​
  5. ^ Yu, Mingchao; Sahraei, Saeid; Nixon, Mark; Han, Song (18 de julio de 2020). "SoK: Sharding on Blockchain". Actas de la 1.ª Conferencia de la ACM sobre avances en tecnologías financieras . FC 2020: Criptografía financiera y seguridad de datos . págs. 114–134. doi :10.1145/3318041.3355457. ISBN . 9781450367325.S2CID204749727  .​
  6. ^ "Apache HBase – Página de inicio de Apache HBase™". hbase.apache.org .
  7. ^ "Presentación de la versión preliminar de Elastic Scale para Azure SQL Database". azure.microsoft.com . 2 de octubre de 2014.
  8. ^ "Centro de ayuda de Alibaba Cloud - Definición de la nube y explicación de los servicios basados ​​en la nube - Alibaba Cloud". www.alibabacloud.com .
  9. ^ "Se centra en bases de datos en línea a gran escala: Alibaba Cloud". www.alibabacloud.com .
  10. ^ "Asignación de fragmentos de índice | Guía de Elasticsearch [7.13] | Elastic". www.elastic.co .
  11. ^ "Documentación de IBM".
  12. ^ "Fragmentos de hibernación". 8 de febrero de 2007.
  13. ^ "Hibernate Shards". Archivado desde el original el 16 de diciembre de 2008. Consultado el 30 de marzo de 2011 .
  14. ^ "Nuevas consultas de cuadrícula para Informix".
  15. ^ "Soporte NoSQL en Informix (almacenamiento JSON, API Mongo DB)". 24 de septiembre de 2013.
  16. ^ "Araña". Base de conocimientos de MariaDB . Consultado el 20 de diciembre de 2022 .
  17. ^ "Lanzamiento de la versión de julio de 2015 de MonetDB". 31 de agosto de 2015.
  18. ^ "Características y beneficios del clúster MySQL". 23 de noviembre de 2012.
  19. ^ "Guía de inicio rápido de fragmentación de MySQL Fabric".
  20. ^ "Oracle Sharding". Oracle . 2018-05-24 . Consultado el 2021-07-10 .
  21. ^ "Búsqueda distribuida - SOLR - Apache Software Foundation". cwiki.apache.org .
  22. ^ Corbett, James C; Dean, Jeffrey; Epstein, Michael; Fikes, Andrew; Frost, Christopher; Furman, JJ; Ghemawat, Sanjay; Gubarev, Andrey; Heiser, Christopher; Hochschild, Peter; Hsieh, Wilson; Kanthak, Sebastian; Kogan, Eugene; Li, Hongyi; Lloyd, Alexander; Melnik, Sergey; Mwaura, David; Nagle, David; Quinlan, Sean; Rao, Rajesh; Rolig, Lindsay; Saito, Yasushi; Szymaniak, Michal; Taylor, Christopher; Wang, Ruth; Woodford, Dale. "Spanner: la base de datos distribuida globalmente de Google" (PDF) . Actas de OSDI 2012 . Consultado el 24 de febrero de 2014 .
  23. ^ "sqlalchemy/sqlalchemy". 9 de julio de 2021 – vía GitHub.
  24. ^ "Opciones de particionamiento y fragmentación para SQL Server y SQL Azure". infoq.com .
  25. ^ "Una criptomoneda más rápida y eficiente". MIT News . 24 de enero de 2019 . Consultado el 30 de enero de 2019 .
  26. ^ "Vitess". vitess.io .
  27. ^ "Esfera de fragmentación". shardingsphere.apache.org .
  28. ^ Sarin, DeWitt y Rosenberg, Descripción general de SHARD: un sistema para datos replicados de alta disponibilidad , Informe técnico CCA-88-01, Computer Corporation of America, mayo de 1988
  29. ^ Koster, Raph (8 de enero de 2009). "¿La "fragmentación" de bases de datos proviene de UO?". Sitio web de Raph Koster . Consultado el 17 de enero de 2015 .
  30. ^ abc "Ultima Online: La ecología virtual | Historias de guerra". Vídeos de Ars Technica . 21 de diciembre de 2017.

Enlaces externos