examples - what is a distributed database
¿Qué es sharding y por qué es importante? (5)
Creo que entiendo que sharding vuelva a poner los datos recortados (los fragmentos) en una forma fácil de tratar con el agregado que tenga 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 Shard de algún tipo. Ambas respuestas respondieron el qué pero no el porqué 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? ¿La fragmentación es más importante en aplicaciones a gran escala o se aplica a las de menor escala?
¿La fragmentación es más importante en aplicaciones a gran escala o se aplica a las de menor escala?
El sharding es una preocupación si y solo si sus necesidades escalan más allá de lo que puede servir un solo servidor de base de datos. Es una herramienta genial si tiene datos ampliables 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 con la fragmentación. Es una técnica avanzada con una aplicabilidad muy limitada.
Además, el futuro probablemente sea algo divertido y emocionante, como una "nube" masiva de objetos que borre todas las posibles limitaciones de rendimiento, ¿no? :)
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 determine 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 a su nivel de aplicación.
Sharding es solo otro nombre para "particionamiento horizontal" de una base de datos. Es posible que desee buscar ese término para hacerlo más claro.
De la 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 (en cuanto a 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 diferente. La ventaja es que se reduce el número de filas en cada tabla (esto reduce el tamaño del índice, por lo tanto, mejora el rendimiento de la búsqueda). Si la fragmentación se basa en algún aspecto del mundo real de los datos (por ejemplo, clientes europeos frente a clientes estadounidenses), entonces es posible inferir la membresía de fragmento apropiada de forma fácil y automática, y consultar solo el fragmento relevante.
Más información sobre sharding:
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 exista duplicación para la copia de seguridad / redundancia) con todas las operaciones CRUD realizadas solo en esa base de datos. Es posible que no le guste la terminología utilizada, pero esto representa una manera diferente de organizar una base de datos lógica en partes más pequeñas.
Actualización: No romperás MVC. La capa de acceso a los datos determinará de forma transparente el trabajo de determinar el fragmento correcto donde almacenar los datos. Allí tendría que determinar el fragmento correcto en función de los criterios que utilizó para fragmentar su base de datos. (Debido a que debe fragmentar manualmente la base de datos en algunos fragmentos diferentes en función de algunos aspectos concretos de su aplicación). A continuación, debe tener cuidado al cargar y almacenar los datos de / en la base de datos para usar el fragmento correcto.
Tal vez este ejemplo con código Java lo aclare un poco (se trata del proyecto Hibernate Shards ), cómo esto funcionaría en un escenario del mundo real.
Para abordar el " why sharding ": se trata principalmente de aplicaciones a gran escala, con muchos datos. En primer lugar, ayuda a minimizar los tiempos de respuesta para consultas de bases de datos. En segundo lugar, puede utilizar máquinas más baratas y de "gama más baja" para alojar sus datos, en lugar de un gran servidor, que quizás ya no sea suficiente.
Sharding fue originalmente creado por los ingenieros de Google y se puede ver que se usa bastante cuando se escriben aplicaciones en Google App Engine. Debido a que existen limitaciones duras en cuanto a la cantidad de recursos que pueden usar sus consultas y debido a que las consultas tienen limitaciones estrictas, la fragmentación no solo se fomenta sino que la arquitectura casi impone su cumplimiento.
Se puede usar otro lugar sharding para reducir la contención en las entidades de datos. Es especialmente importante cuando se construyen sistemas escalables que se vigilen aquellos datos que se escriben con frecuencia porque siempre son el cuello de botella. Una buena solución es eliminar esa entidad específica y escribir en copias múltiples, luego leer el total. Un ejemplo de este "contador detallado GAE: http://code.google.com/appengine/articles/sharding_counters.html
Si tiene consultas a un DBMS para el cual la localidad es bastante restringida (por ejemplo, un usuario solo activa selecciona con ''where username = $ my_username''), tiene sentido poner todos los nombres de usuario comenzando con AM en un servidor y todos desde NZ en el otro. Con esto, te acercas a la escala lineal para algunas consultas.
Para resumir: Sharding es básicamente el proceso de distribución de tablas en diferentes servidores con el fin de equilibrar la carga en ambos por igual.
Por supuesto, es mucho más complicado en realidad. :)