Bienvenido al sitio web oficial de OceanBase para obtener más información: https://www.oceanbase.com/
El 25 de marzo, se llevó a cabo la primera Conferencia de Desarrolladores de OceanBase en Beijing. El arquitecto jefe de OceanBase, Yang Zhifeng (nombre floral: Bamboo Weng), compartió la "Integración distribuida independiente de OceanBase" y presentó el concepto y el pensamiento de la distribución independiente de OceanBase . la arquitectura integrada y su valor para el negocio.
La siguiente es la transcripción del discurso:
El tema de mi discurso de hoy es "Integración distribuida independiente de OceanBase", principalmente para explicar por qué OceanBase necesita hacer una integración distribuida independiente. Hoy compartiré los siguientes tres aspectos:
En primer lugar, ¿qué es la integración distribuida independiente?
En segundo lugar, ¿cómo obtener un rendimiento equivalente al de una base de datos independiente cuando se implementa en una máquina independiente?
Finalmente, ¿cómo lograr un alto rendimiento y una baja latencia en la implementación distribuida?
¿Qué es la integración distribuida independiente?
Todos pueden tener una comprensión diferente de "integración distribuida autónoma" y tener muchas dudas. De hecho, la integración distribuida autónoma no es un concepto que surgió repentinamente de OceanBase, sino que se basa en tres razones.
Primero, la iteración del producto. OceanBase ha sido desarrollado por sí mismo desde 2010. En el proceso de salir de Ant Group para servir a la industria financiera, y ahora ir a la nube para atender a más clientes en la industria de Internet, según los comentarios de los clientes, nuestros productos están en constante evolución y mejorando.
En segundo lugar, el desarrollo continuo de las tendencias de hardware. Cuando se diseñó originalmente OceanBase 1.0, usamos máquinas ordinarias de 16 núcleos en el clúster interno de Ant Group. Más tarde, con el desarrollo de la tecnología de hardware, nuestras máquinas principales tenían más de 96 núcleos y el rendimiento de un solo servidor Ha sido una gran mejora
En tercer lugar, el desarrollo de la tecnología en la nube. En los últimos años, el desarrollo de la tecnología en la nube ha avanzado a pasos agigantados. Cuando se acababa de establecer OceanBase, la tecnología en la nube acababa de surgir y ahora la infraestructura de la nube está al alcance de su mano. El desarrollo de la tecnología va acompañado del desarrollo de la arquitectura OceanBase, y la tecnología de OceanBase ha pasado por tres iteraciones de versiones principales.
▋ De 0.1 a 4.0, la historia de desarrollo de OceanBase
La primera versión es la versión 0.5. Aunque fue una versión de hace más de diez años, en realidad es una arquitectura completamente distribuida. En ese momento, OceanBase separó la capa SQL del motor de almacenamiento. Lo anterior es un conjunto de servicios SQL sin estado. el siguiente es un clúster de almacenamiento compuesto por ChunkServer y UpdateServer, y lo que está expuesto al exterior es la API de la tabla. En ese momento, debido a que acabábamos de comenzar a implementar la base de datos, hicimos algunas restricciones: no había escritura multipunto, por lo que las transacciones distribuidas no se admitían en ese momento.
Cuando OceanBase evolucionó de 0.5 a 1.0, tuvimos un sentimiento profundo: la base de datos independiente tradicional adopta un diseño estrechamente acoplado, y el almacenamiento y la computación se unen. Más tarde, debido a NoSQL, muchas personas piensan que la capa de almacenamiento debe estar aislada. Por separado, Open, OceanBase siguió esa idea de diseño en unas pocas décimas de una versión, así que la separamos, pero después de la separación, causó problemas muy grandes.
El problema es que está bien hacer NoSQL, pero no es tan simple hacer una base de datos relacional.Si tiene requisitos de latencia, el método débilmente acoplado conducirá a una gran sobrecarga en eficiencia. Entonces, desde OceanBase 1.0, hemos estado reconsiderando este problema, convirtiendo la transacción de almacenamiento SQL en una arquitectura estrechamente acoplada, es decir, una arquitectura completamente distribuida, combinando los tres servidores originales en un nodo OBServer y procesando la transacción de almacenamiento SQL al mismo tiempo. Al mismo tiempo, dividimos la granularidad de alta disponibilidad de la granularidad de alta disponibilidad a nivel de máquina original en varias zonas, todas las cuales se beneficiaron de nuestra práctica de escenarios en Ant Group.
Cuando OceanBase se desarrolló a la versión 2.0, OceanBase pasó de Ant Group a clientes externos. Durante este proceso, los clientes informaron: "OceanBase solo es compatible con MySQL, lo cual es muy bueno, pero tenemos muchos sistemas heredados. Cámbielo completamente a use MySQL o hágalo de forma abierta", por lo que OceanBase introdujo características importantes en 2.0, y es compatible con Oracle además de la capacidad de múltiples inquilinos, pero su arquitectura general es diferente de 1.0 De manera similar, en la versión 4.0, han entrado en una nueva etapa de integración distribuida independiente.
▋ Tres significados de integración distribuida autónoma
Ahora, permítanme definir formalmente qué es la integración distribuida independiente de OceanBase. La integración distribuida independiente tiene tres niveles de significado.
En el primer nivel, OceanBase existe en forma de programa, que se puede implementar en forma de implementación de una sola máquina o de varias máquinas. Esto no es muy fácil de hacer Solo cuando tomamos la integración distribuida independiente como un objetivo podemos realizar tal forma.
El segundo nivel, nuestra llamada integración distribuida independiente, en realidad tiene un concepto de inquilinos. Incluso si implementa un clúster de OceanBase distribuido, si un arrendatario está en una sola máquina, lo consideramos una sola máquina.
La distribución independiente de tercer nivel se puede convertir dinámicamente. Entre las dos formas, OceanBase se puede cambiar a voluntad y se puede ajustar dinámicamente de manera flexible. Una sola máquina puede convertirse en un sistema distribuido y un sistema distribuido puede convertirse en una sola máquina. También se puede hacer a nivel de arrendatario y de clúster. nivel.
Aunque habrá muchos desafíos en otros aspectos, el mayor desafío de la conmutación es obviamente el rendimiento, por lo que a continuación compartiré cómo OceanBase puede lograr una base de datos independiente bajo la arquitectura integrada distribuida independiente cuando se implementa en un lugar independiente. , podemos lograr un mayor rendimiento y una latencia más baja que otras bases de datos distribuidas al tiempo que garantizamos la escalabilidad durante la implementación distribuida.
▋ Integración distribuida independiente, que combina diferentes etapas de desarrollo de las empresas
En primer lugar, observe el valor del negocio. Para muchas empresas, hay un proceso de pequeño a grande, o hay un pequeño negocio dentro de una gran empresa. El negocio comienza desde pequeño y crece. Un día, cierto negocio puede aparecer repentinamente. Vamos, pero al principio, no necesitábamos tantos recursos. Esperamos que los usuarios puedan disfrutar de las ventajas que brindan las bases de datos distribuidas, y no hay muchas dificultades para usarlas. Una base de datos puede resolver múltiples etapas de desarrollo. de empresas demanda.
OceanBase admite oficialmente la implementación independiente. Si tiene requisitos para la separación de lectura y escritura, puede usar la capacidad de la biblioteca maestra en espera de OceanBase, al igual que la base de datos maestra en espera de MySQL tradicional, sin ninguna diferencia; Para problemas de datos, especialmente para la recuperación remota de desastres, puede actualizar dinámicamente desde las bases de datos principal y de reserva al modelo de tres copias de OceanBase; si cree que el modelo de tres copias y de alta disponibilidad no se puede dominar en esta etapa, o no es muy importante para usted, entonces OceanBase en realidad tiene una gran capacidad de escalar la expansión vertical en modo independiente, por lo que no hacemos bases de datos distribuidas independientemente del rendimiento independiente.
Cuando una empresa o negocio se desarrolla en un escenario a gran escala, hay muchas cuestiones a considerar. Por ejemplo, hay muchas empresas. Dentro de Ant Group, puede imaginar que hay muchas empresas, e incluso decenas de miles de máquinas están usando OceanBase. En este momento, si solo tiene un equipo de DBA de 10 gente, ¿cómo se gestionan 10.000 MySQL?, este es un reto muy grande, por lo que nuestra arquitectura multiusuario y toda la arquitectura distribuida nos permite controlar la cantidad de clústeres dentro de un rango razonable, y hay muchos métodos automáticos de operación y mantenimiento en cada grupo, permítanos Un buen DBA realmente puede dormir profundamente, y muchos requisitos no funcionales se plantean en este momento.
Por ejemplo, una base de datos distribuida es excelente, pero es posible que no la necesite en esta etapa. Pero quiero decir: "Con la arquitectura integrada distribuida independiente de OceanBase, nadie tendrá que preocuparse, puede elegir las características que necesita cuando las necesita". Por otro lado, si introduzco una base de datos distribuida y le vendo tres copias y muchas otras capacidades que no necesita, eso no es lo que queremos, y este es también el valor central de nuestra base de datos independiente.
Cómo lograr un rendimiento equivalente al de una base de datos independiente cuando se implementa en un servidor independiente
▋ El diseño en capas excesivo simplifica la implementación, pero sacrifica el rendimiento
Pensando en este problema a la inversa, si tengo una base de datos distribuida, el lado izquierdo es una forma típica de otras bases de datos distribuidas, separa los nodos de almacenamiento de los nodos de cómputo y se comunican entre sí a través de la red, para que puedan ser independientes. para hacer la expansión. Por supuesto, una base de datos distribuida no es tan simple como la fragmentación. La base de datos es muy importante como nodo central del procesamiento de transacciones. La base de datos debe garantizar la consistencia global y la atomicidad de los datos, por lo que muchas bases de datos presentarán un administrador de transacciones global de este tipo. módulo.
OceanBase también tiene un módulo similar, al que llamamos servicio global de marca de tiempo, y sus funciones son similares.Como en la imagen de arriba a la derecha, se instalan tres nodos en una sola máquina.
Mucha gente dice que podemos hacer este tipo de "integración distribuida independiente", pero implica una gran sobrecarga, porque muchos protocolos involucrados en el procesamiento distribuido son sobrecarga para una sola máquina. Entre varios componentes, si se comunica a través de RPC, habrá una gran cantidad de sobrecarga adicional Además, el protocolo RPC debe diseñarse especialmente, por lo que al diseñar este protocolo de comunicación, no puede realizar muchos procesamientos rápidos y flexibles, como llamadas a funciones.
Además, hay un significado oculto, es decir, desde la perspectiva de la investigación y el desarrollo de nuestra base de datos, si comienza con la distribución, no pensará en la situación de una sola máquina en el proceso de implementación real, que es comprensible para todos. .
▋ Integración distribuida en una sola máquina de OceanBase
Echemos un vistazo a la arquitectura general de la integración distribuida independiente de OceanBase. Es muy simple decirlo: cada máquina tiene su propio módulo de transacción de almacenamiento SQL independiente. No hay diferencia, la comunicación entre las máquinas se realiza a través de la red.
La arquitectura de la figura anterior tiene varias características: primero, cada nodo tiene un solo proceso, OceanBase no tiene tantas distinciones de funciones y todo el almacenamiento de transacciones SQL es memoria compartida dentro de un solo proceso; segundo, no hay RPC para un solo -trabajo de máquina, Y para bases de datos independientes, con el fin de mejorar la escalabilidad vertical, OceanBase también admite el paralelismo dentro de un sistema independiente. En un nivel más profundo, OceanBase tendrá en cuenta tanto el sistema independiente como el distribuido en el diseño de cada componente. .
En tal diseño, cada uno de nuestros diseños funcionales debe considerar cómo hacerlo mejor en una sola máquina y cómo hacerlo mejor cuando se distribuye, por lo que nuestro diseño tendrá estas dos dimensiones.
Primero, mire los dos significados de independiente. Primero, hay un OBServer en cada Zona, por lo que incluso si hay muchas unidades de recursos en una Zona, es decir, Unidad, si su arrendatario es una sola Unidad, es equivalente al independiente mencionado aquí.
Para mejorar la escalabilidad vertical en una sola máquina, OceanBase logrará una optimización extrema en el motor SQL, el motor de transacciones y el motor de almacenamiento: primero, el paralelismo se puede realizar en una sola máquina; segundo, en el motor de transacciones, estamos haciendo alto procesamiento simultáneo de transacciones El tiempo hará técnicas de presentación de grupo. También en el motor de almacenamiento, nuestro motor de almacenamiento es un motor de almacenamiento cuasi-memoria. Al escribir, solo necesita almacenarse en la memoria. No necesita escribirse en un bloque de datos como un árbol B+ tradicional. Una sola máquina también admite mucho paralelismo en el nivel de E/S.
Verá que los primeros MySQL le dieron un clúster de 96 núcleos y era imposible ejecutar la CPU a plena capacidad Este es el rendimiento de la escalabilidad vertical.
▋ OceanBase 4.0 VS MySQL 8.0
La figura anterior muestra la comparación de rendimiento entre OceanBase 4.0 y MySQL 8.0 En los seis escenarios, el rendimiento de OceanBase 4.0 y MySQL 8.0 es equivalente.
La imagen de arriba es nuestra prueba de escalabilidad vertical. También bajo los seis escenarios de carga de Sysbench, desde máquinas de 4 núcleos hasta máquinas de 64 núcleos, todos pueden ver que OceanBase tiene una escalabilidad vertical muy buena y duplica el número de núcleos, el rendimiento de OceanBase se duplica
Cómo lograr un alto rendimiento y una baja latencia en la implementación distribuida
Para el negocio de OLTP, todo el mundo está preocupado por el índice de retraso cuando se utiliza una base de datos distribuida, entonces, ¿puede el índice de retraso de una sola operación ser el mismo que el de una base de datos independiente? Esto es lo que OceanBase se enfoca en optimizar. La razón básica es: no importa en qué tipo de centro de datos se encuentre, se necesitan 0,5 milisegundos para realizar una RPC, y esta vez no se puede ignorar.
▋ El rendimiento distribuido requiere alto rendimiento y baja latencia
La siguiente figura muestra el rendimiento de la base de datos independiente y las dos bases de datos distribuidas bajo cierta carga, a medida que aumenta la proporción de transacciones distribuidas, y el verde es la base de datos independiente.
Con el aumento de ciertas transacciones distribuidas, por ejemplo, para TPC-C, es decir, el aumento de las transacciones entre almacenes no es diferente al de los datos independientes. Si hay dos tipos de bases de datos, el objetivo de diseño de OceanBase es convertirse en la curva de rendimiento de DB1 a continuación. Con el aumento de las transacciones distribuidas, debe haber una sobrecarga, pero cuando no tengo transacciones distribuidas, el rendimiento de DB2 es mucho peor. que MySQL, esta no es la base de datos distribuida que queremos diseñar.
En este momento, hay dos formas de hacerlo. La primera es reducir la proporción de transacciones distribuidas y consultas distribuidas. Como dijo el CTO Yang Chuanhui: "De hecho, para muchas transacciones en línea y transacciones globales, su proporción a menudo no es tan como todo el mundo piensa. En un escenario típico de TPC-C, la consulta de transacciones entre almacenes en TPC-C es solo el 10 % " ). A la hora de hacer transacciones online, los estudiantes de DBA tienen muy claro su negocio, y no todo tiene que pagar gastos generales distribuidos, para lograr este efecto hemos trabajado mucho, el más importante de ellos es la autoadaptación en 4.0 flujo de registro.
OceanBase ha realizado muchas estrategias autoadaptativas para automatizar el balanceo de carga basado en el diseño de la tabla y organiza automáticamente los datos para reducir la proporción de transacciones distribuidas y consultas distribuidas. Si estas medidas automatizadas no logran este objetivo, los usuarios también pueden usar la partición funciones de tabla y grupo de tablas que proporcionamos para controlar y reducir las transacciones distribuidas.
¿Qué sucede si no se pueden cumplir los requisitos anteriores? Debemos avanzar para reducir la sobrecarga general de las transacciones distribuidas y las consultas distribuidas.Esta OceanBase tiene muchos diseños únicos.
▋ ¿Por qué OceanBase se distribuye de manera eficiente y económica?
Volviendo a la arquitectura integrada distribuida independiente, echemos un vistazo a cómo funciona en un escenario distribuido bajo esta arquitectura.
Para el diseño en capas anterior, si la capa de SQL, la capa de almacenamiento y la capa de transacciones son diseños en capas, no importa cómo opere, no hay percepción entre este SQL y las transacciones locales, y todo es global. Sí, no hay diferencia en el Capa SQL si los datos de la transacción son locales o remotos. Este no es el caso con OceanBase, distinguimos explícitamente la diferencia entre los dos, por lo que la capa SQL de OceanBase puede acceder directamente a la capa de almacenamiento de otra máquina. Si necesito acceder a la capa de almacenamiento de otra máquina, hago RPC, si el almacenamiento al que accedo es local, no necesito hacer RPC.
Hay varias granularidades diferentes en el diseño general. En esencia, hemos hecho un diseño más refinado. El refinamiento significa que la distribución de una sola máquina no es un concepto simple, sino una sola máquina con múltiples granularidades. En nuestra opinión, hay cuatro Granularidad básica :
Primero, los inquilinos. ¿Es un inquilino distribuido o un inquilino independiente?
Segundo, conversación. OceanBase utilizará el protocolo de enrutamiento Proxy para hacer que algo se distribuya en muchas otras bases de datos, y se convertirá en algo independiente en OceanBase. Lo más típico es que enrutaremos este SQL al nodo donde se encuentra el almacenamiento según las características del SQL, de forma que aunque parezca que está distribuido como un todo, la ejecución de ese SQL se convertirá en ejecución local.
Tercero, negocios. A nivel de transacción, si OceanBase solo opera una partición en un flujo de registro dentro de una sola transacción, el protocolo para el envío de transacciones distribuidas también es diferente del protocolo para máquinas independientes.
Cuarto, SQL. Si se trata de una ejecución de SQL independiente y una ejecución que requiere acceso remoto a SQL, tenemos dos rutas de ejecución independientes. Sobre esta base, para que la ejecución distribuida sea más eficiente, todo nuestro motor SQL tendrá una estrategia adaptativa al realizar la ejecución en serie en OLTP.
Nuestro diseño siempre ha sido un todo. Para LSM-Tree, la fusión es una tarea en segundo plano que requiere muchos recursos, pero en un escenario de implementación distribuida, hemos inventado un método inteligente: hacer que la fusión de cada máquina y sus servicios se puedan escalonar , lo llamamos "fusión rotativa", es decir, si una copia proporciona servicios, no se fusionará primero, y dejaré que la copia del seguidor haga la fusión, de modo que la fusión LSM-Tree en segundo plano no tenga ningún efecto en las operaciones en primer plano No hay efecto en esta máquina.
▋ ¿Cómo mejora el rendimiento de las consultas distribuidas un motor de ejecución adaptativa distribuido en una sola máquina?
Si no tengo forma de optimizar el negocio para reducir SQL distribuido, ¿cómo puedo implementar la parte de SQL distribuido? El motor de ejecución adaptable de SQL general de OceanBase se divide en ejecución en serie y ejecución en paralelo.
La ejecución paralela se puede realizar en paralelo en una sola máquina, lo que es ventajoso en comparación con algunas bases de datos de fuente abierta de una sola máquina. Las primeras versiones de MySQL no pueden lograr el paralelismo en una sola máquina, y se pueden usar varias máquinas. Si la CPU de una máquina es no es suficiente, puedo usar todo el grupo de CPU para la ejecución en paralelo. Para la ejecución en serie, distinguimos explícitamente si es un acceso con una gran cantidad de datos o un acceso con una pequeña cantidad de datos.
Si es un acceso con una pequeña cantidad de datos, llevaremos los datos a la máquina local para su ejecución; si es un acceso con una gran cantidad de datos, enviaremos todo el plan de ejecución de SQL a esa máquina para el filtrado de datos. Todo el proceso es El optimizador elige adaptativamente.
▋ Considere los protocolos de procesamiento de transacciones independientes y distribuidos para mejorar el rendimiento de las transacciones
Por último, las transacciones son muy difíciles de realizar con optimización distribuida.OceanBase tiene muchas patentes innovadoras sobre motores de transacciones. Aquí presento dos puntos. La siguiente figura muestra el proceso de ejecución y envío de una transacción distribuida. La transacción como un todo se divide en dos operaciones clave: "inicio de transacción" y "compromiso de transacción" .
Primero, en la etapa de "inicio de la transacción", el lado izquierdo es el típico proceso de confirmación de dos fases de otras bases de datos distribuidas. Al iniciar una transacción, para lograr el aislamiento de múltiples versiones, la lectura y la escritura no se afectan entre sí. En el escenario MVCC, necesita obtener una instantánea global, es decir, qué transacciones están operando actualmente y qué transacciones han enviado instantáneas. Para muchas bases de datos distribuidas, esta operación de instantánea es muy costosa.
OceanBase se ha optimizado en esta etapa. En muchos escenarios, OceanBase no necesita acceder al servicio de marca de tiempo global. Implementamos de manera innovadora algunas optimizaciones para los servicios GTS, haciendo que esta parte de la sobrecarga sea escalable. La prueba es la prueba TPC-C, TPC-C tiene 1500 nodos, 1500 máquinas procesan más de 20 millones de transacciones por segundo (las transacciones no son SQL), pero solo hay un nodo de servicio GTS, parece que este GTS no es fácil para expandir, de hecho lo optimizamos para que sea fácil de expandir.
En segundo lugar, en la etapa de "confirmación de transacciones”, para el protocolo de confirmación, puede ver el protocolo de confirmación de dos etapas a la izquierda. El protocolo de confirmación tradicional de dos etapas necesita escribir registros de cuatro etapas, y los participantes deben escribir el registro. de la transacción también debe registrarse en el coordinador, de modo que la confirmación de dos fases sea segura en el escenario de recuperación ante desastres.
OceanBase ha realizado un diseño muy innovador en el compromiso de dos fases. Los participantes de OceanBase tienen tres copias y están altamente disponibles, por lo que no nos preocupamos por la pérdida de datos de los nodos del coordinador, por lo que no mantenemos registros en el participantes, lo que ahorra dos registros. En segundo lugar, devolveremos el éxito a la aplicación en la primera etapa. Esta es una optimización única nuestra, que reduce el viaje de ida y vuelta general una vez. Entonces, en general, incluso en el escenario de transacciones distribuidas, las transacciones distribuidas de OceanBase tienen grandes ventajas sobre otras bases de datos distribuidas.
Finalmente, se adjunta la comparación de rendimiento entre OceanBase y varias bases de datos distribuidas comunes en el mercado bajo subprocesos Sysbench 500. Esta es la mejor presentación de "Cuál es la baja latencia de OceanBase" en un escenario completamente distribuido , y mi compartir está aquí. , ¡gracias a todos!
Bienvenido al sitio web oficial de OceanBase para obtener más información: https://www.oceanbase.com/