Introducción: Multi-Live en diferentes lugares, como su nombre lo indica, es brindar servicios al exterior al mismo tiempo en múltiples sitios en diferentes lugares. La principal diferencia con la recuperación de desastres tradicional es que todos los sitios en Multi-Live brindan servicios al mismo tiempo. En los negocios cada vez más complejos y los requisitos de recuperación ante desastres cada vez más estrictos de la actualidad, cómo implementar soluciones nativas de la nube para múltiples actividades en diferentes lugares se ha convertido en un desafío que deben enfrentar las empresas medianas y grandes. En la XI Conferencia de Tecnología de Base de Datos de China (DTCC2020), el experto senior en bases de datos de Alibaba Cloud, Zhang Xin, compartió la solución de los múltiples medios de vida nativos de Alibaba Cloud.
Resumen: Multi-living en diferentes lugares, como su nombre indica, es proporcionar servicios a múltiples sitios en diferentes lugares al mismo tiempo. La principal diferencia con la recuperación de desastres tradicional es que todos los sitios en "Multi-living" brindan servicios externos al mismo tiempo. En los negocios cada vez más complejos y los requisitos de recuperación ante desastres cada vez más estrictos de la actualidad, cómo implementar soluciones nativas de la nube para múltiples actividades en diferentes lugares se ha convertido en un desafío que deben enfrentar las empresas medianas y grandes. En la XI Conferencia de Tecnología de Base de Datos de China (DTCC2020), el experto senior en bases de datos de Alibaba Cloud, Zhang Xin, compartió la solución de los múltiples medios de vida nativos de Alibaba Cloud.
El contenido de este artículo está organizado en base a grabaciones de voz y PPT.
Introducción de invitado:
Zhang Xin (apodo: Six Gold), experto senior en bases de datos de Alibaba Cloud, solía ser un DBA para respaldar los sistemas centrales internos de Alibaba, incluidas transacciones, publicidad, etc. En los últimos dos años, se mudó al mercado de la nube patentada y se lo proporcionó a grandes clientes gubernamentales y empresariales. Soluciones de bases de datos.
Este intercambio se dividirá principalmente en tres aspectos:
- Análisis de la arquitectura de tolerancia a desastres
- Solución Multi-Live de Alibaba Cloud
- Caso de cliente
1. Análisis de la arquitectura de tolerancia a desastres
La necesidad de tolerancia a los desastres
Vivir más en lugares diferentes en sí mismo comienza con la tolerancia a los desastres, así que primero presente la necesidad de la tolerancia a los desastres. El sistema de producción puede encontrar tres tipos de fallas. La primera son fallas a nivel de host, como una carga excesiva de un solo punto, corrupción de datos, etc .; la segunda son fallas a nivel de sala de computadoras, como fallas en el suministro de energía, fallas en la red de la sala de computadoras, etc. Fallos regionales, como desastres naturales. Para los tres tipos de fallas anteriores, es obvio que las fallas a nivel regional tienen el mayor impacto, pero la probabilidad de ocurrencia es la más baja, pero para las fallas a nivel de host, la probabilidad de ocurrencia no es necesariamente baja y el impacto es pequeño. Alibaba ha resuelto sus propios tipos de fallas a lo largo de los años y descubrió que con el aumento de la complejidad del sistema empresarial actual, un solo punto de falla también puede tener un impacto global, y cuando la complejidad alcanza un cierto nivel, si ocurre un solo punto de falla La investigación y la recuperación serán muy difíciles, por lo que la tolerancia a desastres se ha convertido en una opción necesaria para la construcción de información empresarial.
Análisis de la industria de recuperación ante desastres
Desde el punto de vista del análisis de la industria, el mercado de recuperación ante desastres es bastante impresionante. Según informes autorizados, la cuota de mercado global de recuperación ante desastres alcanzará los 11.590 millones de dólares estadounidenses en 2020, y la base de clientes es muy amplia, como gobierno, finanzas, energía, Internet, comunicaciones, etc. Básicamente, siempre que haya un sistema de información, existe la necesidad de recuperación ante desastres. Alibaba Cloud cuenta actualmente con 100.000 usuarios empresariales y 400.000 instancias de bases de datos, todas las cuales requieren garantías de tolerancia a desastres. A nivel nacional, también existen requisitos de cumplimiento estrictos, especialmente ahora que los grandes clientes gubernamentales y empresariales deben consultar la "Especificación de recuperación y recuperación de desastres del sistema de información" GB / T 20988 para la construcción de recuperación de desastres.
Evolución de la arquitectura de tolerancia a desastres
La evolución de la arquitectura de tolerancia a desastres se divide principalmente en varias etapas. La recuperación ante desastres en la misma ciudad es la más simple, es decir, hay un IDC en la misma área y el negocio está desplegado, y se despliega un sistema de respaldo de sala de computadoras y una base de datos durante la recuperación ante desastres para lograr una sincronización de datos asíncrona o síncrona en el medio, y el tráfico empresarial se concentra en un lado y en el otro Solo para la preparación para desastres. Más tarde, evolucionó gradualmente a intra-ciudad dual-activa. Tomó prestadas las ventajas de dos centros de datos en la misma ciudad que la distancia geográfica es relativamente cercana y el retraso de la red es corto. Los servicios se pueden implementar en ambos extremos porque la distancia física es corta y los retrasos aceptables. . Después de eso, habrá remoto dual-activo, es decir, el centro de dos puntos tres y el centro de dos puntos cuatro derivado de él. Lo principal es agregar un centro de recuperación de desastres sobre la base de la misma ciudad de doble activo. Este centro de recuperación de desastres no recibe en condiciones normales. Para el tráfico, cambiará solo cuando ocurra una falla regional.
Solución tradicional de recuperación ante desastres
Reorganizar la solución tradicional de recuperación ante desastres. Para la recuperación ante desastres dentro de la ciudad o la doble activa dentro de la ciudad, la ventaja es que la implementación es simple y el costo de acceso es muy bajo; la desventaja es que solo brinda protección dentro de la ciudad, que solo puede alcanzar el nivel 1 en GB / T 20988 Habilidad, por lo que para grandes clientes, este programa no se puede seleccionar. Para el modo de espera en frío remoto, la ventaja es también una implementación simple, menos intrusiones comerciales y la capacidad de recuperación ante desastres del despliegue remoto es relativamente mayor, que puede llegar a 2 a 5; la desventaja es que el costo de la redundancia de la unidad de espera en frío es mayor. , Lo que resulta en una cierta cantidad de desperdicio de recursos Además, debido a que la unidad de recuperación de desastres no recibe tráfico durante todo el año, se desconoce si el conmutador está disponible cuando ocurre una falla. Para los tres centros en dos lugares, en realidad es una combinación de doble activo en la misma ciudad y espera en frío en lugares diferentes. La ventaja es la ventaja de los dos esquemas anteriores. La desventaja es que el costo del centro de espera en frío se desperdicia y el fracaso a nivel regional no se atreve a continuar. Cambiar.
2. La solución de Alibaba Cloud para múltiples medios de vida
Arquitectura Multi-Live de Alibaba Cloud
La figura anterior muestra la arquitectura general de Alibaba Cloud Multi-Activity en diferentes lugares. De hecho, la esencia de múltiples actividades en diferentes lugares se logra mediante el aislamiento del tráfico de arriba hacia abajo de los servicios. Alibaba Cloud divide toda la arquitectura multiactiva remota en tres capas. La primera capa es la capa de acceso. Para lograr la actividad remota activa-activa, primero debe formular una estrategia de distribución para la empresa, como asignar el tráfico de acuerdo con las dimensiones geográficas o de usuario. Una vez definida la estrategia de distribución, La división del tráfico se puede lograr en la capa de acceso y el tráfico que pertenece a esta unidad puede continuar transmitiéndose de forma transparente hacia abajo y, si no pertenece, se transferirá a la unidad correcta. La segunda capa es la capa de servicio, que es el sistema de negocios que brinda servicios al mundo exterior y se divide en tres tipos: servicio unificado, servicio centralizado y servicio ordinario según las diferentes capacidades de prestación. La tercera capa es la capa de datos. Lo que esta capa debe resolver es la sincronización bidireccional entre dominios y las capacidades anti-circulación que la base de datos debe tener, y debe garantizar la calidad de los datos cuando se corta el flujo.
Alibaba Cloud ha detallado la solución de arquitectura multiactiva para dos escenarios comerciales, OLTP y OLAP, y luego los presenta uno por uno.
Arquitectura multiactiva de negocios OLTP
Para las empresas OLTP, Alibaba Cloud proporciona una arquitectura multiactiva correspondiente, que contiene varios elementos clave. En primer lugar, la configuración multiactiva, principalmente a través de MSHA para una configuración multiactiva única, que es responsable de formular estrategias de división de tráfico y decidir qué bases de datos deben ser multiactivas. En segundo lugar, el control de flujo multiactivo lo realiza principalmente MSFE de acuerdo con las reglas establecidas y es responsable de la identificación, distribución y corrección del flujo. En tercer lugar, la sincronización de datos de múltiples vidas se logra principalmente a través de DTS. DTS en sí es una herramienta de sincronización de datos. Agrega muchas funciones nuevas para escenarios de múltiples vidas, como anticirculación, optimización de red y enlace de corte de flujo. En cuarto lugar, el conmutador de recuperación ante desastres multiactivo también se implementa a través de MSHA, que es principalmente responsable de impulsar las especificaciones de cada capa y realizar una verificación global del estado antes del conmutador multiactivo. En quinto lugar, la operación y el mantenimiento del escenario multiactivo se realiza a través de DMS. En el escenario multiactivo, los cambios de DDL y la operación y el mantenimiento de datos tienen problemas de doble escritura y retrasos de sincronización. Por lo tanto, las estrategias para implementar cambios de DDL y DML son diferentes. Capacidades adaptadas a múltiples escenarios en vivo.
Arquitectura multiactiva empresarial OLAP
La arquitectura multiactiva empresarial OLAP no es muy diferente de OLTP, y los elementos son básicamente los mismos. La única diferencia es que la sincronización de datos bidireccional se implementa en la parte inferior de la arquitectura multiactiva empresarial OLTP. En la arquitectura multiactiva empresarial OLAP, no se recomienda este tipo de trabajo. . Hay dos razones principales. Primero, el costo de ancho de banda de la sincronización de datos entre regiones es muy alto. Si OLTP ha sincronizado los datos, intente sincronizar en la nube en lugar de la sincronización OLAP; en segundo lugar, es necesario garantizar la coherencia de los datos. , Se sincroniza una vez en OLTP, si necesita sincronizarse una vez en OLAP, será más difícil garantizar la coherencia de los datos. Por lo tanto, Alibaba Cloud recomienda no realizar la sincronización de datos en OLAP, sino hacer todo en OLTP, y las capacidades de sincronización de datos se pueden complementar en la nube.
Arquitectura típica de doble activo: cuatro zonas de doble región
La figura anterior muestra una arquitectura típica de doble activo, que se divide en dos regiones. Cada región tiene dos zonas de disponibilidad. Primero, tiene tolerancia a desastres de nivel de zona de disponibilidad. Si se produce una falla a nivel de región, Utilice la tolerancia a los desastres. Bajo esta arquitectura, MSFE y sistemas comerciales específicos se implementan en todas las zonas de disponibilidad, con alta disponibilidad de nivel de zona de disponibilidad en la nube. La base de datos se puede implementar en modo activo y en espera en AZ1 y AZ2, AZ3 y AZ4, y la capa inferior puede realizar una sincronización bidireccional a través de DTS. Los datos son redundantes en cuatro copias, la redundancia empresarial alcanza el 200% y la redundancia de cada AZ alcanza el 50%, pero cuando el tráfico se realiza realmente, solo se puede realizar el 25% de cada AZ y el negocio se puede implementar por sí mismo. Para traspasos no planificados, se puede lograr un RTO a nivel de minutos.
Diferentes tipos de servicios en múltiples trabajos
Como se mencionó anteriormente, la capa de servicio se divide en tres tipos de servicios. El primer tipo es el servicio unificado, que es el tipo principal de servicio bajo la arquitectura multiactiva. Por ejemplo, la modificación de la información de los compradores de Taobao es un servicio unificado típico. El ID de usuario de la casa se utiliza para desviar el tráfico. En esta dimensión, se pueden realizar llamadas cerradas dentro de la unidad, sin depender de los datos de los pares, y la sincronización de datos subyacentes solo garantiza que los datos de los pares estén completos cuando se cambian los datos y pueden completar los datos. Sí, la empresa puede funcionar directamente después del cambio. El segundo es el servicio centralizado, principalmente para escenarios en los que la configuración global o el negocio tienen fuertes requisitos centrales de lectura y escritura, como la deducción de inventario. No se permite deducir el mismo inventario en varios lugares al mismo tiempo. Este escenario definitivamente accederá a la base de datos central. La capa inferior sincroniza los datos mediante sincronización unidireccional. Este tipo de servicio no proporciona múltiples medios de vida, sino capacidades de tolerancia a desastres. El tercer tipo es el servicio ordinario, cuyo objetivo es que si el negocio se divide según una determinada dimensión, es posible que algunos servicios periféricos acoplados no se dividan según la misma dimensión. Este tipo de negocio puede elegir servicios ordinarios, como las transacciones de Taobao según la compra La identificación de la casa está dividida, por lo que los vendedores no se pueden dividir según esta dimensión. Los servicios ordinarios pueden tolerar retrasos de sincronización, es decir, eventualmente consistentes, pero no pueden aceptar retrasos de acceso, por lo que están orientados principalmente a servicios de lectura y no se recomiendan para escenarios de escritura.
Sincronización de datos entre nubes
Los tres tipos de servicios anteriores tienen diferentes métodos de sincronización de datos en la parte inferior, por lo que se proporcionan dos métodos de sincronización de datos entre nubes. El primero es el tipo COPY de método de sincronización de datos, que es principalmente para servicios centralizados y servicios ordinarios. Los datos se sincronizan unidireccionalmente y la unidad solo se puede leer pero no escribir. La configuración de la tarea de sincronización se realiza a través del método de liberación de lista blanca + DDL. El segundo es el método de sincronización de datos tipo UNIT, que está orientado principalmente a servicios unitizados y servicios ordinarios. Los datos se sincronizan bidireccionalmente, y cada unidad puede leer y escribir. En este momento, es necesario resolver el problema anti-loop mediante tablas de transacciones, etc., y mediante la Secuencia global evitar el conficto.
Anti-circulación y secuencia
Las bases de datos de Alibaba Cloud PolarDB y RDS han implementado las dos capacidades de anti-loop y secuencia. En la parte anti-loop, hay principalmente dos formas. La primera es el método de tabla de transacciones, es decir, cuando el negocio se escribe en la base de datos, es decir, se envía la transacción y se genera el Binlog. Después de que el DTS tome el Binlog y se complete el análisis, se encontrará la dirección Cuando se escribe la base de datos de la unidad de destino, se generará un registro personalizado en la tabla de transacciones, de modo que la transacción que aterriza en la unidad realmente tendrá un pequeño Evento adicional además de la lógica comercial original. Después de analizar el DTS del final de destino, encontrará que hay una operación de transacción adicional en Binlog, y sabrá que esta operación es de DTS, no del sistema empresarial, por lo que puede filtrar la operación y colocar el bucle de datos. El segundo método es a través de THREAD_ID, que es una función de optimización personalizada por el kernel AliSQL. El THREAD_ID del kernel MySQL nativo se cambia de 8 bytes a 5 bytes. Por lo tanto, la conexión de generación de servicios solo puede estar entre 0x00000 y 0xFFFFF, y el bit alto es Está reservado para conexiones DTS, por lo que la base de datos central puede distinguir entre los dos tipos de conexiones. Binlog registrará todos los THREAD_IDs, por lo que DTS también puede analizar claramente si la operación proviene de la empresa o del DTS. Si proviene de la empresa, se sincronizará. Si proviene de la DTS, Interrumpa para lograr la función anti-circulación. El primer método es algo intrusivo para el negocio y el segundo es una capacidad completamente nativa, que no tiene mucho impacto en los usuarios ni en el kernel.
Para la función de secuencia, en realidad es escribir datos en ambos lados al mismo tiempo, y es necesario asegurarse de que los datos no entren en conflicto. Por lo tanto, Alibaba Cloud ha creado una capacidad de secuencia única a nivel mundial para PolarDB-X y ha agregado un identificador al DDL nativo para controlar el número de unidades actuales y el índice de cada unidad. Con base en la tabla creada de esta manera, el tamaño del paso interno es 100.000 y el número de unidades es 2, por ejemplo, el resultado se muestra en la figura anterior, para lograr la capacidad de la secuencia global.
Protección de datos en múltiples escenarios en vivo
En el escenario multiactivo, la mayor diferencia con el nativo es que no hay necesidad de prestar atención a la disponibilidad, pero hay más problemas de calidad de los datos. Este problema puede no ocurrir fácilmente en el escenario de un solo centro de datos, pero en el escenario multiactivo porque la empresa requiere escritura doble , Por lo que es propenso a conflictos en la calidad de los datos. En el análisis final, todos los problemas de calidad de los datos se deben a la doble escritura de datos, por lo que es necesario formular ciertas medidas de protección para este escenario. Alibaba Cloud ha formulado medidas de protección de unidades tridimensionales. La primera es el estado diario, que proporciona los métodos correspondientes para la capa de acceso, la capa de aplicación y la capa de datos. Las múltiples reglas de derivación activas para múltiples operaciones de escritura se utilizan para la verificación de la lógica de enrutamiento. Para el tráfico unitario, el tráfico se transfiere a la capa de acceso y la capa de aplicación, pero si está en la capa de datos, se bloquea directamente. El segundo es el estado de cambio, principalmente para cambios de operación y mantenimiento de datos, como la corrección de datos por lotes. Alibaba Cloud ofrece la capacidad de verificar de antemano y complementar después. En el DMS, verifique los cambios de antemano para las tareas de cambio de datos en escenarios multiactivos. Si Si el retardo de sincronización es demasiado grande, se bloqueará, lo que reduce la probabilidad de que los datos se escriban por duplicado. Al mismo tiempo, los datos se mantienen consistentes al verificar antes y después del cambio. El tercero es el estado de flujo de corte, que es una estrategia de protección utilizada en el proceso de múltiples flujos de datos en vivo, incluida la prohibición absoluta de escritura, la prohibición de escritura retardada, la sincronización de coincidencia de espejo frontal y las funciones de verificación retardada.
Proceso de flujo múltiple
En el caso de múltiples transmisiones en vivo, primero se activa la función de coincidencia de espejo frontal. En general, se cree que los datos escritos por la empresa en el escenario multiactivo son más importantes que los datos que están sincronizados. Por lo tanto, es necesario asegurarse de que los datos escritos por la empresa no se sobrescriban con los datos sincronizados. Por lo tanto, si hay un retraso en la sincronización de datos durante el proceso de conmutación, con el fin de Si los datos comerciales no se sobrescriben, debe sacar la imagen frontal en Binlog y ponerla en SQL para su ejecución. Una vez habilitada la función de coincidencia del espejo frontal, se emitirán las nuevas reglas de distribución del tráfico en cada capa. Una vez emitida la regla, se habilitará la acción de prohibición absoluta de escritura. Durante este proceso, no se puede ejecutar todo el tráfico de usuarios que participa en el flujo de corte. . En el proceso de prohibición de escritura, primero es necesario juzgar si todas las reglas de tres capas han convergido con éxito y, en segundo lugar, es necesario juzgar si las reglas de cada nodo en cada capa han convergido con éxito. El objetivo final es mantener la coherencia de las reglas en todos los servidores, a fin de garantizar que no se produzca una doble escritura. . Una vez que se cumplen las condiciones anteriores, se levanta la prohibición absoluta de escritura y se habilita la prohibición de escritura retardada, que puede configurar el usuario. Cuando se completa la sincronización de datos, la prohibición de escritura y la coincidencia de espejo anterior se eliminan, y el proceso de corte de flujo ahora está completo.
Resumen del valor de vivir en diferentes lugares
Simplemente resuma el valor de vivir más en diferentes lugares. En primer lugar, Duoju en sí es para la recuperación de desastres, pero ahora no es como colocar una unidad de recuperación de desastres como la recuperación de desastres tradicional. Ahora el negocio es la recuperación ante desastres, y el sistema empresarial y el sistema de recuperación ante desastres están estrechamente conectados. En segundo lugar, se garantiza la continuidad del negocio, proporcionando alta disponibilidad para el negocio. En tercer lugar, brinda apoyo para el rápido desarrollo de las empresas. En el escenario multiactivo, muchas unidades atómicas se dividen y los recursos relacionados pueden asignarse racionalmente de acuerdo con las unidades atómicas para lograr resultados óptimos y, en última instancia, tener la capacidad de expandirse horizontalmente entre regiones. En cuarto lugar, el tráfico está efectivamente aislado. La solución multiactiva remota basada en Alibaba Cloud puede implementar el tráfico de manera muy flexible. Las especificaciones se pueden establecer de acuerdo con diferentes dimensiones, o establecer de acuerdo con diferentes proporciones de peso, para lograr una implementación flexible del tamaño del tráfico y lograr Realice pruebas técnicas de riesgo controlable en la unidad más pequeña. En quinto lugar, reduzca los costos y aumente la eficiencia. Las soluciones tradicionales de recuperación ante desastres no pueden superar el problema del costo de redundancia del 200%, mientras que las soluciones de tres y cuatro activos pueden lograr costos de redundancia inferiores al 200%.
Dificultades para que los usuarios implementen múltiples actividades en diferentes lugares por sí mismos
Los usuarios deben enfrentar muchas dificultades para implementar múltiples actividades en diferentes lugares por sí mismos, como alta dificultad en la gestión del tráfico, complicadas estrategias de sincronización de datos, difícil aseguramiento de la calidad de los datos para la conmutación de tolerancia a desastres y dificultad en la gestión y control unificados de múltiples centros de datos. La precipitación de capacidad es la fuerza impulsora de las soluciones a nivel de producto. Basado en la solución de actividad múltiple remota de Alibaba Cloud, los usuarios solo necesitan comprender cómo dividir el tráfico.
Ventajas de la solución nativa en la nube de Alibaba
En la actualidad, hay muy pocos proveedores que puedan lograr múltiples actividades a nivel de producto en diferentes lugares. Después de 8 años de acumulación y precipitación, Alibaba Cloud tiene muchas ventajas en la solución nativa de la nube para múltiples actividades en diferentes lugares.
En tercer lugar, el caso de varios clientes en vivo en diferentes lugares.
Caso de cliente: un sistema central de impuestos
El programa remoto multiactividad de un determinado sistema fiscal también se implementa de acuerdo con una arquitectura de tres niveles. En la capa de acceso, admite la división del tráfico en dos dimensiones, a saber, provincia y número de archivo de persona física. En la capa de servicio, los productos CSB se utilizan para implementar la invocación entre nubes de servicios comunes. En la capa de datos, la sincronización de datos de diferentes niveles de tolerancia a desastres se implementa para diferentes tipos de servicios. Al final, logró una capacidad de conmutación de segundo nivel, multiactividad bidimensional, y alcanzó el efecto de nivel 6 estándar nacional. Debido a que se basa en una conexión de dos unidades, tiene una ventaja en el costo y tiene la capacidad de aumentar la escala de grises.
Caso de cliente: un sistema de servicio al cliente de operador
El sistema de servicio al cliente de un operador se ha dado cuenta de la capacidad de dividir el tráfico por provincia, es decir, el acceso a los dos centros en el norte y el sur de acuerdo con la distribución geográfica del DNS. La capa de acceso realiza juicios y correcciones de errores de acuerdo con las reglas de enrutamiento, y el sistema original del cliente se adapta y modifica en la capa empresarial , Realización del servicio de sincronización de los centros duales. En la capa de datos, la sincronización de datos bidireccional se logra a través de PolarDB-X y DTS. Al final, varios servicios del sistema de servicio al cliente del operador se dividieron por región. En múltiples ejercicios de recuperación de desastres, fue posible completar la conmutación de segundo nivel y garantizar una pérdida de datos cero. Además, dado que dos unidades transportan tráfico de servicio normalmente, el costo también se reduce.
Haga clic aquí para descargar la presentación PPT
Lectura relacionada
[Contiene descarga de PPT de productos secos] DTCC 2020 | Alibaba Cloud Ye Zhengsheng: Base de datos 2025
https://developer.aliyun.com/article/780725
[Contiene descarga de PPT de productos secos] DTCC 2020 | Aliyun Zhao Diankui: ruta de migración sin problemas de PolarDB a Oracle
https://developer.aliyun.com/article/780749
[Contiene descarga de PPT de productos secos] DTCC 2020 | Alibaba Cloud Zhu Jie: La última tendencia de desarrollo tecnológico de NoSQL
https://developer.aliyun.com/article/780746
[Contiene descarga de PPT de productos secos] DTCC 2020 | Alibaba Cloud Wang Tao: Práctica en la nube de la base de datos de comercio electrónico de Alibaba
https://developer.aliyun.com/article/781001
DTCC 2020 | Alibaba Cloud Liang High School: Práctica de optimización automática global de DAS basada en la carga de trabajo
https://developer.aliyun.com/article/781036
[Contiene descarga de PPT de productos secos] DTCC 2020 | Aliyun Chengshi: Gestión de bases de datos en la era nativa de la nube
https://developer.aliyun.com/article/780992
[Contiene descarga de PPT de productos secos] DTCC 2020 | Alibaba Cloud Ji Jiannan: Interpretación de tecnologías clave para el análisis en línea para ingresar a la era de Fast Data
https://developer.aliyun.com/article/780747
Enlace original: https://developer.aliyun.com/article/781031?
Declaración de derechos de autor: El contenido de este artículo es aportado voluntariamente por usuarios registrados de nombre real de Alibaba Cloud. Los derechos de autor pertenecen al autor original. La Comunidad de desarrolladores de Alibaba Cloud no posee sus derechos de autor y no asume las responsabilidades legales correspondientes. Consulte el "Acuerdo de servicio al usuario de la comunidad de desarrolladores de Alibaba Cloud" y las "Directrices de protección de propiedad intelectual de la comunidad de desarrolladores de Alibaba Cloud" para conocer las reglas específicas. Si encuentra sospecha de plagio en esta comunidad, complete el formulario de reclamo por infracción para informarlo. Una vez verificado, esta comunidad eliminará inmediatamente el contenido presunto infractor.