¿Qué es el fragmentación y por qué es importante?

Creo que entiendo que fragmentar es volver a colocar sus datos cortados (los fragmentos) en un agregado fácil de manejar que tiene sentido en el contexto. ¿Es esto correcto?

Actualización : supongo que estoy luchando aquí. En mi opinión, el nivel de aplicación no debería tener ningún negocio para determinar dónde se deben almacenar los datos. En el mejor de los casos, debería ser un cliente de fragmentos de algún tipo. Ambas respuestas respondieron al qué, pero no al por qué, es un aspecto importante. ¿Qué implicaciones tiene fuera de las obvias ganancias de rendimiento? ¿Son estas ganancias suficientes para compensar la violación de MVC? ¿El sharding es más importante en aplicaciones de gran escala o se aplica a las de menor escala?

Sharding es solo otro nombre para "particionamiento horizontal" de una base de datos. Es posible que desee buscar ese término para aclararlo.

De Wikipedia :

La partición horizontal es un principio de diseño mediante el cual las filas de una tabla de base de datos se mantienen por separado, en lugar de dividirse por columnas (como en el caso de la normalización). Cada partición forma parte de un fragmento, que a su vez puede ubicarse en un servidor de base de datos o ubicación física por separado. La ventaja es que se reduce el número de filas en cada tabla (esto reduce el tamaño del índice y, por lo tanto, mejora el rendimiento de búsqueda). Si el fragmento se basa en algún aspecto de los datos del mundo real (p. Ej., Clientes europeos frente a clientes estadounidenses), entonces es posible inferir la membresía del fragmento apropiado de manera fácil y automática, y consultar solo el fragmento relevante.

Alguna información más sobre el fragmentación:

En primer lugar, cada servidor de base de datos es idéntico y tiene la misma estructura de tabla. En segundo lugar, los registros de datos se dividen lógicamente en una base de datos fragmentada. A diferencia de la base de datos particionada, cada registro de datos completo existe en un solo fragmento (a menos que haya reflejo para respaldo / redundancia) con todas las operaciones CRUD realizadas solo en esa base de datos. Puede que no le guste la terminología utilizada, pero esto representa una forma diferente de organizar una base de datos lógica en partes más pequeñas.

Actualización: No romperás MVC. El trabajo de determinar el fragmento correcto donde almacenar los datos sería realizado de manera transparente por su capa de acceso a datos. Allí tendría que determinar el fragmento correcto en función de los criterios que utilizó para fragmentar su base de datos. (Como debe fragmentar manualmente la base de datos en algunos fragmentos diferentes en función de algunos aspectos concretos de su aplicación.) Luego debe tener cuidado al cargar y almacenar los datos desde / en la base de datos para utilizar el fragmento correcto.

Tal vez este ejemplo con código Java lo hace algo más claro (se trata del proyecto Hibernate Shards ), cómo funcionaría esto en un escenario del mundo real.

Para abordar el " why sharding": es principalmente solo para aplicaciones a gran escala, con muchos datos. Primero, ayuda a minimizar los tiempos de respuesta para las consultas de la base de datos. En segundo lugar, puede usar máquinas más baratas y de "gama baja" para alojar sus datos, en lugar de un gran servidor, lo que podría no ser suficiente.

Si tiene consultas a un DBMS para el cual la localidad está bastante restringida (por ejemplo, un usuario solo dispara selecciones con un 'donde nombre de usuario = $ mi_nombredeusuario') tiene sentido poner todos los nombres de usuario que comienzan con AM en un servidor y todos desde NZ en el otro. De este modo, se obtiene una escala lineal para algunas consultas.

Larga historia corta : Sharding es básicamente el proceso de distribuir tablas en diferentes servidores para equilibrar la carga en ambos por igual.

Por supuesto, es mucho más complicado en realidad. :)

Sharding es una partición de base de datos horizontal (en sentido de fila ) en oposición a una partición vertical (en sentido de columna ) que es Normalización . Separa bases de datos muy grandes en partes más pequeñas, más rápidas y más fáciles de administrar llamadas fragmentos de datos. Es un mecanismo para lograr sistemas distribuidos.

¿Por qué necesitamos sistemas distribuidos?

• Aumento de la disponibilidad.
• Expansión más fácil.
• Economía: cuesta menos crear una red de computadoras más pequeñas con el poder de una sola computadora grande.

Puede leer más aquí: Ventajas de la base de datos distribuida

¿Cómo los fragmentos ayudan a lograr un sistema distribuido?

Puede particionar un índice de búsqueda en N particiones y cargar cada índice en un servidor separado. Si consulta un servidor, obtendrá 1 / Nth de los resultados. Por lo tanto, para obtener un conjunto completo de resultados, un sistema de búsqueda distribuido típico utiliza un agregador que acumulará los resultados de cada servidor y los combinará. Un agregador también distribuye consultas en cada servidor. Este programa agregador se llama MapReduce en terminología de big data. En otras palabras, Sistemas distribuidos = Sharding + MapReduce (aunque también hay otras cosas).

Una representación visual a continuación.

¿El fragmentación es más importante en aplicaciones de gran escala o se aplica a las de menor escala?

El fragmentación es una preocupación si y solo si sus necesidades escalan más allá de lo que puede servir un único servidor de base de datos. Es una herramienta excelente si tiene datos definidos y tiene requisitos de escalabilidad y rendimiento increíblemente altos. Supongo que en mis 12 años completos he sido un profesional del software, me he encontrado con una situación que podría haberse beneficiado de la fragmentación. Es una técnica avanzada con una aplicabilidad muy limitada.

Además, el futuro probablemente será algo divertido y emocionante como una "nube" de objetos masivos que borra todas las limitaciones potenciales de rendimiento, ¿verdad? :)

Sharding fue originalmente acuñado por ingenieros de Google y puedes ver que se usó bastante cuando escribiste aplicaciones en Google App Engine. Dado que existen grandes limitaciones en la cantidad de recursos que pueden usar sus consultas y debido a que las consultas tienen limitaciones estrictas, la arquitectura no solo fomenta el fragmentación, sino que casi lo impone.

Otro lugar en el que se puede usar el fragmentación es para reducir la contención en las entidades de datos. Al construir sistemas escalables, es especialmente importante tener cuidado con los datos que se escriben con frecuencia porque siempre son el cuello de botella. Una buena solución es dividir esa entidad específica y escribir en copias de varios archivos, luego leer el total. Un ejemplo de este "contador fragmentado wrt GAE: http://code.google.com/appengine/articles/sharding_counters.html

Sharding hace más que solo particionar horizontalmente. Según el artículo de Wikipedia ,

La partición horizontal divide una o más tablas por fila, generalmente dentro de una sola 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 clásico ejemplo de las tablas 'CustomersEast' y 'CustomersWest', donde su código postal ya indica dónde se encontrarán.

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

También,

Dividir fragmentos en varias instancias aisladas requiere 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 la consulta de ambas instancias, solo para recuperar una tabla de dimensiones simple. Más allá del particionamiento, el fragmentación divide grandes tablas particionables en los servidores, mientras que las tablas más pequeñas se replican como unidades completas

En mi opinión, el nivel de aplicación no debería tener ningún negocio para determinar dónde se deben almacenar los datos

Esta es una buena regla, pero como la mayoría de las cosas no siempre es correcta.

Cuando haces tu arquitectura comienzas con responsabilidades y colaboraciones. Una vez que determina su arquitectura funcional, debe equilibrar las fuerzas no funcionales.

Si una de estas fuerzas no funcionales es la escalabilidad masiva, debe adaptar su arquitectura para satisfacer esta fuerza, incluso si eso significa que su abstracción de almacenamiento de datos ahora se filtra en su nivel de aplicación.