Requisito previo: el teorema CAP En el sistema distribuido debe haber oído hablar del término teorema CAP. El teorema CAP establece que es imposible lograr las tres propiedades en sus almacenes de datos. Aquí TODAS las tres propiedades se refieren a C = Coherencia, A = Disponibilidad y P = Tolerancia de partición. De acuerdo con este teorema, solo es posible lograr cualquiera de dos a la vez. Si hay 1000 requests/mes se pueden gestionar pero 1 millón de requests/mes será un poco difícil. Aquí, en el diagrama, podemos tener n configuraciones de base de datos diferentes. Todas las operaciones de escritura se realizan en la base de datos Maestra y todas las operaciones de lectura en la base de datos Esclava. Pero los datos del maestro deben replicarse en las bases de datos esclavas, lo que ocurre de forma asíncrona. Inconsistencia:cuando algún usuario intenta leer datos justo después de escribirlos (incluso antes de que se hayan replicado en el esclavo) se denomina incoherencia. El usuario podría pensar en esto como un error o algo así. Sharding: Por lo tanto, para superar esta desventaja de la inconsistencia tenemos otro método conocido como Sharding. En esto, en lugar de una relación Maestro-Esclavo, aquí todas las bases de datos son Maestros, es decir, todas las bases de datos comparten las mismas responsabilidades. Por ejemplo, en la siguiente ilustración tenemos 3 instancias de bases de datos. Puntos a tener en cuenta aquí: Los datos se dividen en n segmentos separados (aquí, 3). El sistema escala las operaciones de lectura y escritura n veces (si hay n bases de datos).
Desventajas de este método:Si una instancia en particular tendrá una carga más pesada, digamos DB-1, entonces se vuelve difícil de escalar. Ahora, ¿cómo escalar? Tendremos que dividir la instancia de carga en, digamos, dos instancias para compartir la carga. Sería necesario eliminar esa base de datos en particular, luego dividirla nuevamente y luego volver a cambiarla. Este es un proceso tedioso, siempre necesita ser monitoreado. Se requerirían uniones SQL en fragmentos b/w. Aprendamos sobre cada una de las siguientes propiedades al considerar el siguiente sistema donde tenemos dos instancias de Datos, ambas bases de datos maestras. Consistencia – Como se discutió anteriormente, si los datos se actualizan en una instancia de la base de datos pero antes de que se repliquen en la consulta del usuario de otra instancia, si la información que obtiene el usuario son sus datos anteriores, significa que su sistema es inconsistente. Si el usuario obtiene el mismo valor actualizado, se dice que el sistema es consistente. Disponibilidad: incluso si una o más de sus máquinas fallan, su sistema debería estar siempre disponible, lo que significa que si uno o más servidores de bases de datos fallan, su sistema en su conjunto debería poder realizar operaciones de lectura y escritura. Por lo tanto, no debe haber tiempo de inactividad. Tolerancia de partición: incluso si se pierde la conexión entre los servidores de la base de datos, el sistema debería seguir funcionando.
Publicación traducida automáticamente
Artículo escrito por smriti_rout y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA