1 ¿Qué es una base de datos distribuida?
Hasta el momento no existe una organización autorizada para definir, ¿quién es la organización autorizada? ¡No hay consenso!
El auge de la base de datos distribuida representado por TiDB dota a la base de datos relacional de un cierto grado de características distribuidas. En estas bases de datos distribuidas, la fragmentación de datos y las transacciones distribuidas serán sus funciones básicas integradas. Los desarrolladores de negocios solo necesitan usar la interfaz JDBC proporcionada por el marco, al igual que usar una base de datos relacional tradicional como MySOL. ShardingSphere es un middleware de base de datos distribuido, que no solo proporciona soluciones estandarizadas de fragmentación de datos, sino que también implementa transacciones distribuidas y funciones de gobierno de base de datos.
estándar de facto
Cuando un producto tecnológico domina el mercado, naturalmente se convierte en el estándar de facto para su clase. Para la base de datos relacional, Oracle es el estándar de facto, porque cuando todos los productos de base de datos lanzan nuevas versiones, tienen que comparar sus propias funciones con Oracle.
Como software básico emergente, la base de datos distribuida aún no ha ocupado la posición de "estándar de facto". No hay referencia, hagámoslo nosotros mismos y definamos juntos el concepto de base de datos distribuida.
De afuera hacia adentro, de afuera hacia adentro es la ley general para que las personas entiendan las cosas, así que observemos desde dos perspectivas, la de adentro y la de afuera.
2 Perspectiva externa: características externas
Qué características tiene la base de datos distribuida y qué puntos débiles puede resolver.
Los sistemas de aplicaciones comerciales se clasifican por tipo de transacción:
-
Transacción en línea (OLTP)
Procesamiento orientado a transacciones, la cantidad de datos para una sola transacción es pequeña, pero los resultados deben darse en un corto período de tiempo. Los escenarios típicos incluyen compras, pagos, transferencias, etc.
-
Análisis en línea (OLAP)
Por lo general, es una operación basada en un gran conjunto de datos. Los escenarios típicos incluyen la generación de facturas anuales personales y estados financieros corporativos.
Es difícil tener un producto que satisfaga plenamente a ambos, por lo que en la era de la BD única han evolucionado dos sistemas técnicos diferentes, es decir, dos tipos diferentes de BD relacionales. Después de evolucionar a una arquitectura distribuida, los dos también adoptan estrategias completamente diferentes en el diseño de la arquitectura, lo cual es difícil de explicar claramente bajo un solo marco.
En primer lugar, céntrese en analizar la base de datos distribuida en el escenario de OLTP. La "base de datos" mencionada en este tutorial tiene como valor predeterminado "base de datos relacional", y la base de datos distribuida también hace referencia a la base de datos distribuida que admite el modelo relacional. Es decir, NoSQL no se discute En general, la base de datos relacional tiene una mayor versatilidad porque admite SQL y proporciona transacciones ACID, y no puede ser reemplazada por NoSQL en una gama más amplia de escenarios. El desarrollo de NoSQL ha sido probado durante más de diez años.
El objetivo de la base de datos distribuida es integrar las ventajas de la base de datos relacional tradicional y la base de datos NoSQL, y ha logrado buenos resultados.
3 definiciones
3.1 Base de datos relacional OLTP
Usar solo "escenario OLTP" como atributo obviamente no es lo suficientemente preciso. Echemos un vistazo más de cerca a las características técnicas específicas de los escenarios OLTP.
Los escenarios OLTP suelen tener tres características:
- Escriba más y lea menos , en referencia al número de solicitudes. Además, la complejidad de las operaciones de lectura es baja y, por lo general, no implica el cálculo resumido de grandes conjuntos de datos.
- Latencia baja , los usuarios tienen una tolerancia baja a la latencia, generalmente dentro de los 500 milisegundos, un poco más, es decir, segundos, y una latencia de más de 5 segundos suele ser inaceptable;
- Alta concurrencia , la cantidad de concurrencia aumenta con el volumen de negocios y no hay un límite superior teórico.
¿Podemos llegar a tal conclusión? La base de datos distribuida es una base de datos que sirve escenarios OLTP con más escrituras y menos lecturas, baja latencia y alta simultaneidad .
3.2 Concurrencia masiva
Puede decir que hay un problema con esta definición. Por ejemplo, las bases de datos relacionales como MySQL y Oracle también sirven escenarios OLTP, pero no son bases de datos distribuidas.
En comparación con la base de datos relacional tradicional, la mayor diferencia de la base de datos distribuida es que la capacidad de procesamiento concurrente de la base de datos distribuida es mucho mayor que la del primero.
La base de datos relacional tradicional suele ser un modo independiente y la carga principal se ejecuta en una máquina. La capacidad de procesamiento concurrente de la base de datos está relacionada linealmente con la configuración de recursos de una sola máquina, por lo que el límite superior de la capacidad de procesamiento concurrente también está limitado por el límite superior de la configuración de una sola máquina. Este método de ampliar el rendimiento mediante la mejora de la configuración de recursos de una sola máquina se denomina expansión vertical (Scale Up).
En una máquina, ¿puede simplemente incluir más CPU y memoria para mejorar el rendimiento? Por supuesto que no es tan fácil. Por lo tanto, el aumento en el límite superior de la configuración independiente de la máquina física es relativamente lento. Es decir, dentro de un cierto período de tiempo, siempre habrá un techo de rendimiento para las bases de datos que dependen de la expansión vertical. Una de las razones por las que muchos bancos compran minicomputadoras o mainframes es que estas máquinas pueden instalar más CPU y memoria que los servidores x86, lo que puede empujar el techo más alto.
La base de datos distribuida es diferente. Sobre la base de mantener las características de la base de datos relacional, aumenta la cantidad de máquinas a través de la expansión horizontal y proporciona una concurrencia mucho mayor que la base de datos única. Esta cantidad de concurrencia casi no está limitada por el rendimiento de una sola máquina. Llamo a este nivel de concurrencia "concurrencia masiva".
¿Qué tan grande es la "concurrencia masiva"?
Sin figuras autorizadas. Aunque teóricamente es posible encontrar una de las mejores máquinas del mundo para probarla, considerando factores comerciales, este número no tendrá ningún valor práctico. Sin embargo, puedo dar un valor empírico, el límite inferior de esta "concurrencia masiva" es de aproximadamente 10 000 TPS.
Definición de la versión 2.0: la base de datos distribuida es una base de datos relacional que ofrece más escrituras y menos lecturas, baja latencia y escenarios OLTP simultáneos masivos .
3.3 + alta confiabilidad
La versión 2.0 todavía tiene problemas. ¿No hay necesidad de usar una base de datos distribuida si no hay una demanda concurrente masiva? No, debe considerar la alta confiabilidad de DB.
En general, la confiabilidad está relacionada con la tasa de fallas de los dispositivos de hardware.
A diferencia de los bancos, muchas empresas de Internet y pequeñas y medianas empresas suelen utilizar servidores x86. El servidor x86 tiene muchas ventajas, pero la tasa de fallas será relativamente alta y la tasa de fallas anual es de alrededor del 5%.
Algunos de los datos más confiables provienen del artículo de Google Failure Trends in a Large Disk Drive Population , que examina en detalle los escenarios de falla para los discos de dispositivos de propósito general. Proporciona un gráfico estadístico de la tasa anual de fallas del disco, como se muestra a continuación:
Se puede ver que la tasa de daño del disco superará el 2 % en los primeros tres meses, y este número aumentará a alrededor del 8 % en el segundo año.
Se podría decir que este número no es muy alto.
Pero debes saber que para los sistemas de aplicación clave en la industria financiera, generalmente se requiere tener 5 nueves de confiabilidad (99.999%), es decir, el tiempo de interrupción del servicio del sistema en un año no puede exceder los 5.26 minutos ( 365 *24 *60 *(1-99,999%) ≈ 5,26 ).
Además, no solo la industria financiera, ya que las personas confían en Internet, cada vez más sistemas tendrán requisitos de confiabilidad tan altos.
Con base en estas dos cifras, podemos imaginar que si su empresa tiene cuatro o cinco sistemas comerciales clave y una docena de servidores de base de datos, la cantidad de discos debe superar los 100, ¿verdad? Luego, estimamos de manera conservadora que, según la tasa de daño del 2%, habrá 2 daños en el disco en un año. Para lograr la confiabilidad de 5 nueves, solo tiene 5,26 minutos. ¿Puede manejar una falla en el disco? Esto es casi imposible de hacer, tal vez solo corriste a la sala de computadoras y se acabó el tiempo.
Supongo que sugeriría RAID (matriz redundante de discos independientes) para mejorar la confiabilidad del disco. De hecho, esta es una forma, pero también traerá pérdida de rendimiento y pérdida de espacio de almacenamiento. El mecanismo de copia de la base de datos distribuida puede equilibrar mejor la relación entre confiabilidad, rendimiento y utilización del espacio que RAID. El mecanismo de copia consiste en almacenar un dato en varias máquinas al mismo tiempo para formar varias copias físicas.
Volviendo al tema de la base de datos, la confiabilidad es un poco más complicada e incluye dos métricas, el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). RTO se refiere al tiempo que lleva la recuperación de fallas, que se puede equiparar con la confiabilidad; RPO se refiere a la cantidad de datos perdidos después de que se restablece el servicio.
La base de datos almacena datos importantes, y la base de datos en la industria financiera está aún más relacionada con la seguridad de los activos del cliente, y no se puede tolerar ninguna pérdida de datos. Por lo tanto, la alta confiabilidad de DB significa que el RPO es igual a 0 y el RTO es inferior a 5 minutos.
Tradicionalmente, los bancos han logrado este objetivo a través de una combinación de dos enfoques.
La primera es comprar minicomputadoras y mainframes, porque su estabilidad es mejor que la de los servidores x86.
El segundo es introducir soluciones de almacenamiento profesional, como el software de duplicación remota Symmetrix de EMC (Symmetrix Remote Data Facility, SRDF). La base de datos adopta el modo activo/en espera y guarda los archivos de la base de datos e inicia sesión en el almacenamiento compartido de gama alta, lo que hace que la base de datos sea casi sin estado. Una vez que hay un problema con la biblioteca principal, la biblioteca en espera se inicia y carga los archivos almacenados en el almacenamiento compartido y continúa brindando servicios. De esta forma, el RPO puede ser cero y el RTO puede ser relativamente pequeño.
Sin embargo, esta solución se basa en software y hardware dedicados, que no solo son costosos, sino que también tienen un sistema técnico cerrado. En el contexto de ir a IOE (minicomputadora IBM, Oracle DB y dispositivos de almacenamiento EMC), debemos encontrar otra forma. La base de datos distribuida es una buena alternativa, se basa en el mecanismo de copia de seguridad mutua y conmutación automática entre nodos, lo que reduce el impacto de un único punto de falla en el servidor x86 en el sistema general y brinda una alta garantía de confiabilidad.
Lo emocionante es que este mecanismo de manejo de punto único de falla puede incluso extenderse al nivel de la sala de computadoras, a través del despliegue a larga distancia en las salas de computadoras. De esta manera, incluso si falla toda la sala de computadoras, el sistema aún puede funcionar normalmente y la base de datos nunca se apagará.
3.0, la base de datos distribuida es una base de datos relacional altamente confiable que sirve más escrituras y menos lecturas, baja latencia y escenarios OLTP simultáneos masivos .
3.4 Almacenamiento masivo
Aunque una sola base de datos puede expandir su capacidad de almacenamiento al depender de dispositivos de almacenamiento externos, este método no es inherentemente una capacidad de base de datos. Ahora, con la ayuda de la arquitectura distribuida de escalamiento horizontal, se pueden obtener potentes capacidades de almacenamiento a través del disco local de la máquina física, lo que hace que el almacenamiento masivo sea una configuración estándar para las bases de datos distribuidas.
Al final, obtuvimos una definición de la última versión 4.0. Distributed DB es una base de datos relacional con capacidad de almacenamiento de datos masiva y alta confiabilidad, que sirve para escenarios OLTP masivamente concurrentes, de baja latencia y escritura-más-menos .
4 Perspectiva interior: Composición interna
Tener las mismas características externas y eficacia no es necesariamente lo mismo.
La "teoría heliocéntrica" refutó la "teoría geocéntrica" al usar 34 círculos para explicar la trayectoria de los cuerpos celestes; más de 100 años después, Kepler solo usó 7 elipses para lograr el mismo efecto, destruyendo por completo la "teoría geocéntrica". Desde Copérnico hasta Kepler, el efecto es similar, pero el grado de simplicidad es bastante diferente, lo que representa un gran progreso científico.
Por tanto, después de hablar de las características externas, también debemos observar desde la perspectiva interna.
Para hacer frente al almacenamiento masivo y la concurrencia masiva, muchas soluciones tienen un efecto similar a la definición V4. Pero exponen demasiada complejidad interna al usuario. Las soluciones con demasiadas restricciones de usuario, un proceso de uso demasiado complicado y una cohesión insuficiente no pueden llamarse productos maduros. Al mismo tiempo, la opinión general de la industria no los considera bases de datos distribuidas.
Mira las categorías:
4.1 Componente de cliente + base de datos única
Establezca reglas de particionamiento y enrutamiento de datos a través de una capa lógica independiente para realizar la administración preliminar de bases de datos individuales, permitir que las aplicaciones se conecten a varias bases de datos individuales y lograr la concurrencia y la expansión de las capacidades de almacenamiento. Como parte del sistema de aplicación, penetra profundamente en el negocio.
Un producto típico de este componente de cliente es Sharding-JDBC.
4.2 Middleware de proxy + base de datos única
Administra reglas de datos y reglas de enrutamiento en forma de middleware independiente, existe como un proceso independiente y está aislado de la capa de aplicación comercial y de la base de datos única, lo que reduce el impacto en las aplicaciones. Con el desarrollo del middleware proxy, también se derivarán algunas capacidades de procesamiento de transacciones distribuidas.
Un producto típico de este tipo de middleware es MyCat.
4.3 Arquitectura unificada + base de datos única
La arquitectura unificada es una reconstrucción completa del sistema de aplicaciones empresariales. El sistema de aplicaciones se divide en varias instancias y se configura una única base de datos independiente para permitir que cada instancia administre un cierto rango de datos. Por ejemplo, para el sistema de préstamos bancarios, se puede construir una instancia de aplicación independiente para cada sucursal para administrar los respectivos usuarios de la sucursal.Cuando ocurre un negocio entre sucursales, las características ACID de la transacción están garantizadas por el código de la capa de aplicación a través del componente de transacción distribuida.
De acuerdo con diferentes modelos de transacciones distribuidas, el sistema de aplicación necesita cooperar con la transformación y, en consecuencia, la complejidad también aumenta. Por ejemplo, bajo el modelo TCC, las aplicaciones deben poder proporcionar operaciones idempotentes.
Antes del surgimiento de la base de datos distribuida, algunas empresas líderes en Internet usaban este estilo arquitectónico.El sistema de aplicación de esta solución requiere la mayor transformación y la implementación más difícil.
La característica común es que el sistema de aplicación aún puede percibir la base de datos única. Por el contrario, la base de datos converge los detalles técnicos en el producto y se enfrenta a las aplicaciones comerciales como un todo.
¿Cómo es la arquitectura interna de la base de datos distribuida? ¿Cuál es la diferencia entre éste y estos tres esquemas? Espere con ansias la siguiente parte de la serie de tutoriales.
5 Aurora de Amazonas
Obviamente es diferente a la BD distribuida mencionada aquí ¿Conoces Aurora o productos similares? ¿Cuál es la diferencia con la base de datos distribuida en este artículo? ¿Por qué hay tal diferencia?
¿Por qué Aurora no es una base de datos distribuida? La separación de almacenamiento y computación de Aurora hace que el servicio de almacenamiento en la nube de Amazon sea más eficiente y fácil de usar. Es relativamente exitoso en NewSQL.
características
Aurora propone una nueva arquitectura monolítica para reducir la E/S de la red y el bloqueo síncrono Lógicamente, se puede considerar como una enorme base de datos monolítica, que utiliza distribución para soportar la tolerancia a fallas y un alto rendimiento. :
-
El método de fragmentación de Aurora consiste en dividir la capacidad total de la base de datos en segmentos de datos de tamaño fijo y almacenar datos en cada segmento. Cada segmento es un grupo de máquinas (seis) y creo que es compatible con la fragmentación.
-
Escribir más, leer menos y baja latencia. Esto es en lo que se centra Aurora. Se logra a través del registro en la base de datos y el soporte asíncrono.
-
Almacenamiento masivo y máquinas de montón confiables (por supuesto, estas máquinas deben ser administradas por un centro de control, que no se menciona en el documento)
-
Alta confiabilidad es confiar en cada segmento de datos para datos redundantes a seis máquinas en tres zonas de disponibilidad
-
Y también es una base de datos relacional
Sin embargo, Aurora se caracteriza por el almacenamiento compartido, la expansión vertical de los nodos informáticos, la expansión horizontal de los nodos de almacenamiento y el impacto del rendimiento de escritura en los recursos de una sola máquina.
mecanismo de votación
También se utiliza Aurora, 6 copias, y más de la mitad de ellas confirman que la escritura es exitosa. Pero sin fragmentación, no puede escribir más, y definitivamente no se distribuye.
No escriba demasiado (¡importante!), los escenarios aplicables son muy diferentes, por lo que este es un criterio importante. Pero debido a que Aurora se basa en almacenamiento compartido, no es descabellado decir que se distribuye. Establecer estándares es solo para aclarar las ideas de aprendizaje.
La diferencia entre la aplicación de Aurora y el almacenamiento distribuido en escenarios reales
Aurora sigue siendo una base de datos relacional, y un sistema de almacenamiento distribuido tiene una amplia gama, como un sistema de clave-valor distribuido como HBase. Hay una gran diferencia en la función entre los dos.
Productos como AWS aurora, Ali polarDB, Tencent CynosDB y Taurus de Huawei tienen arquitecturas similares: separación de computación y almacenamiento. Todos los nodos informáticos acceden a los mismos datos en los nodos de almacenamiento, que también se puede decir que es una arquitectura distribuida. La limitación de esta arquitectura es que la escritura no se puede escalar horizontalmente, lo cual es suficiente para muchas aplicaciones de pequeña escala, por lo que no afecta su éxito comercial.
¿PolarDB de Ali es una base de datos distribuida? ¿Qué esquema utiliza?
PolarDB es similar a Aurora en arquitectura, con separación de almacenamiento y computación, expansión vertical de nodos de computación y expansión horizontal de nodos de almacenamiento. Significa que su capacidad de escritura tiene un límite superior, pero debido a la simplificación del almacenamiento de registros y otras optimizaciones, su capacidad de un solo punto es mucho más fuerte que la de MySQL ordinario.
6 Resumen
Paso a paso, describa las seis características externas de la base de datos distribuida: escriba más y lea menos, baja latencia, concurrencia masiva, almacenamiento masivo, alta confiabilidad, base de datos relacional.
También existen algunas soluciones similares a las capacidades de DB distribuidas, su desventaja es que todas necesitan ser modificadas al sistema de la aplicación y el grado de intrusión en la aplicación es más profundo, su ventaja es que pueden aprovechar al máximo la estabilidad y fiabilidad del único DB Estas características han sido probadas innumerables veces.
El nombre de Distributed DB se estira un poco.
"Distributed DB" se puede descomponer literalmente en dos partes: "distributed" y "DB", lo que significa que es un producto interdisciplinario y su base teórica proviene de dos campos. Esto también hace eco de los dos caminos diferentes del desarrollo de productos.Algunos productos parten de sistemas de almacenamiento distribuido y luego aumentan las capacidades de la base de datos relacional; otros productos parten de una sola base de datos y agregan elementos de tecnología distribuida. Con el desarrollo de DB distribuido hacia aplicaciones industriales, impulsado por la demanda externa, estas dos ideas de desarrollo muestran una tendencia de mayor integración.
7 preguntas frecuentes
① ¿Escribir más y leer menos no debería agregarse a la definición de base de datos distribuida?
El servicio de base de datos distribuida escribe más y lee menos aplicaciones. Creo que la distribución se puede aplicar independientemente de escribir más y leer más. La clave es que un solo cuerpo no puede soportar tantas solicitudes (independientemente de la lectura y la escritura), por lo que una alta concurrencia es suficiente. Escriba más y lea menos ¿No debería agregarse la definición de base de datos distribuida?
El énfasis en escribir más y leer menos se debe a que:
- La carga de la operación de escritura solo puede ser el nodo principal de la única base de datos y no se puede transferir
- Sin embargo, si la operación de lectura no requiere una alta consistencia, se puede transferir al nodo en espera, e incluso se puede garantizar la consistencia bajo ciertas condiciones. Es decir, una sola base de datos puede resolver el problema de una gran carga de lectura a través de un maestro y varias copias de seguridad sin introducir una base de datos distribuida.
Sobre una base distribuida, los dbms en la nube prestan más atención a la expansión independiente después de la separación de la informática y el almacenamiento, e incluso a la expansión y contracción dinámicas. Es autodirigido y es más fácil de vender. Esto también ha causado muchos problemas. Las bases de datos tipo Aurora proponen la idea de que el registro es una base de datos para reducir la presión de escritura. Snowflake reduce los cuellos de botella de la red al establecer una capa intermedia de intercambio distribuido.
② Subtabla de base de datos DB VS distribuida
Base de datos relacional distribuida, ¿parece que el cliente o la solución de middleware se usa directamente como un componente de función del servidor de base de datos, y la subbase de datos y la tabla se automatizan más?
La mayor diferencia es:
- La experiencia de uso de la base de datos distribuida es muy similar a la de la base de datos relacional, sin necesidad de un control adicional de la aplicación, lo que reduce en gran medida la dificultad del desarrollo del código empresarial.
- Sin embargo, el esquema de la subbase de datos y la subtabla no admite bien las transacciones distribuidas y las consultas entre nodos.
③ ¿Cómo se dice MyCat?
Con el desarrollo de la base de datos distribuida, el mercado de middleware como MyCat será cada vez más pequeño. Por supuesto, sus escenarios de uso también pueden convertirse en soporte para bases de datos heterogéneas, como Presto.
④ Se dice que las solicitudes de datos de aplicaciones de Internet "leer más y escribir menos"
Por lo tanto, existen métodos de expansión para resolver el problema de "lectura", como la separación de la lectura y la escritura de un maestro a varios esclavos y el almacenamiento en caché de datos completos. Si se menciona el mismo indicador, ¿significa que la base de datos distribuida no es adecuada para aplicaciones de Internet?
De hecho, Internet puede satisfacer "más lecturas y menos escrituras" a través de un maestro, pero solo si los requisitos de coherencia de lectura son bajos. En escenarios financieros, muchas operaciones de lectura aún no se pueden ejecutar en la base de datos en espera porque la consistencia no cumple con los requisitos. Por lo tanto, no es posible generalizar Internet, pero sí distinguir entre escenarios.
⑤ En el escenario de transacción, la compensación de transacción o la reproducción de datos realizada por el código de transacción junto con la base de datos distribuida
Si el código de transacción necesita cooperar para realizar la compensación y la reproducción, esto probablemente significa que no es una base de datos distribuida. Antes de que la base de datos distribuida madurara, había muchos códigos de aplicación que cooperaban con la base de datos única. Este tipo de código de aplicación también se extraerá para formar un marco independiente, como Ali SOFA.
⑥ ¿Cómo aterriza Newsql?
Por ejemplo, Bank of Beijing y China Everbright Bank lanzaron TiDB, y Oceanbase también aterrizó en Bank of Nanjing.
⑦ ¿BigTable es especial (middleware proxy + base de datos única (sistema de archivos distribuido))?
Después de todo, depende de Chubby como capa intermedia, pero la adquisición de datos se completa directamente al interactuar con el sistema de archivos.
BigTable es un sistema KV distribuido, no una base de datos distribuida. Porque la base de datos distribuida mencionada aquí es una base de datos relacional implementada por una arquitectura distribuida. Por supuesto, se basa en un sistema de archivos distribuidos en la parte inferior, por lo que parece estar dividido en dos capas, pero la función y la base de datos son muy diferentes. Se recomienda prestar atención a la base de datos distribuida estilo PGXC.
⑧ Productos de bases de datos relacionales distribuidos basados en escenarios de uso de OLAP
Las bases de datos de arquitectura MPP más típicas, como Greenplum y GaussDB 200 de Huawei, utilizan PostgreSQL en sus núcleos. y Vertica. OLAP ya no enfatiza el soporte de transacciones.Si los requisitos para la actualización de datos se debilitan, se pueden incluir muchos productos ecológicos de big data, como Clickhouse, Hive on spark e incluso Kylin puede considerarse como DB distribuido OLAP generalizado.