No divida más bases de datos y tablas, ¡pruebe TiDB!

¿Qué es NewSQL?
Problemas con SQL tradicional
- Actualizar el hardware del servidor
- fragmentación de datos
El problema con NoSQL
- ventaja
- defecto
Nuevas características de SQL
Características clave de NewSQL
Comparación de tres tipos de SQL
¿Cómo surgió TiDB?
TiDB Community Edition y Enterprise Edition
Características principales de TIDB
- Expansión elástica horizontal
- Soporte de transacciones distribuidas
- Alta disponibilidad de grado financiero
- HTAP en tiempo real
- Base de datos distribuida nativa en la nube
- Altamente compatible con MySQL
OLTP y OLAP (autoaprendizaje)
- OLTP (procesamiento de transacciones en línea)
- OLAP (procesamiento analítico en línea)
- comparación de características
- Diferencia de ángulo de diseño
Arquitectura general de TiDB
Ventajas de TiDB
Componentes de TiDB
- Servidor TiDB
- Servidor PD (controlador de ubicación)
- Servidor TiKV
- tichispa
- TiFlash
Estructura general de TiKV
- Dividir y fusionar regiones
- Programación de regiones
- transacción distribuida
Arquitectura de alta disponibilidad
- Alta disponibilidad de TiDB
- PD alta disponibilidad
- Alta disponibilidad TiKV
Escenario de aplicación
- Fragmentación y fusión de MySQL
- Reemplazo directo para MySQL
- base de datos
- como módulo para otros sistemas
Aplicaciones
Comparación de compatibilidad entre TiDB y MySQL
Funciones de MySql no compatibles con TiDB
ID de incremento automático
Limitaciones de SELECT
vista
Diferencias en la configuración predeterminada
- conjunto de caracteres
- colación
- Distingue mayúsculas y minúsculas
- explicación de parámetros
- actualización de campo de tipo de marca de tiempo
- explicación de parámetros
- soporte de clave externa

TiDB es una base de datos NewSQL distribuida. Admite expansión elástica horizontal, transacciones ACID, SQL estándar, sintaxis MySQL y protocolo MySQL, y tiene funciones de alta disponibilidad con una sólida consistencia de datos.Es una base de datos híbrida que no solo es adecuada para escenarios OLTP sino también para escenarios OLAP.

TiDB es una base de datos relacional distribuida de código abierto diseñada y desarrollada de forma independiente por PingCAP. Es un producto de base de datos distribuida integrado que admite tanto el procesamiento de transacciones en línea como el procesamiento analítico en línea (Hybrid Transactional and Analytical Processing, HTAP). Características importantes como capacidad, nivel de alta disponibilidad, HTAP en tiempo real, base de datos distribuida nativa de la nube, compatibilidad con el protocolo MySQL 5.7 y ecología MySQL. El objetivo es proporcionar a los usuarios soluciones integrales OLTP (procesamiento transaccional en línea), OLAP (procesamiento analítico en línea) y HTAP. TiDB es adecuado para varios escenarios de aplicaciones, como alta disponibilidad, altos requisitos de consistencia sólida y gran escala de datos.

¿Qué es NewSQL?

La base de datos se ha desarrollado durante 3 generaciones:

SQL, una base de datos relacional tradicional como MySQL
noSQL, como MongoDB, Redis
nuevoSQL

Problemas con SQL tradicional

Internet comenzó a desarrollarse rápidamente a principios de este siglo. La escala de usuarios y el volumen de datos de las aplicaciones de Internet están aumentando, y se requieren 7X24 horas en línea.

Las bases de datos relacionales tradicionales se han convertido en un cuello de botella en este entorno, y suele haber dos soluciones:

Actualizar el hardware del servidor

Aunque se ha mejorado el rendimiento, siempre hay un techo.

fragmentación de datos

Usar una estructura de clúster distribuida

Fragmentar datos en una base de datos de un solo punto y almacenarlos en un clúster distribuido compuesto por máquinas baratas tiene una mejor escalabilidad, pero también trae nuevos problemas.

Los datos que solían estar en una biblioteca ahora abarcan múltiples bibliotecas. El sistema de aplicación no puede operar en múltiples bibliotecas por sí mismo y necesita usar un middleware de fragmentación de bases de datos.

El middleware de fragmentación está bien para operaciones de datos simples, pero es un dolor de cabeza cuando se trata de uniones de bases de datos cruzadas y transacciones de bases de datos cruzadas.

El problema con NoSQL

Más tarde apareció noSQL, que abandonó la fuerte garantía de transacción y el modelo relacional del SQL tradicional, y se centró en la alta disponibilidad y escalabilidad de la base de datos.

ventaja

Alta disponibilidad y escalabilidad, partición automática, fácil expansión
No se garantiza una gran consistencia y el rendimiento mejora considerablemente
Extremadamente flexible sin las limitaciones del modelo relacional

defecto

No se garantiza una consistencia fuerte y no es un problema para las aplicaciones ordinarias, pero todavía hay muchas aplicaciones de nivel empresarial como finanzas que requieren una consistencia fuerte.
No admite sentencias SQL, y la compatibilidad es un gran problema.Diferentes bases de datos NoSQL tienen sus propias API para operar datos, lo cual es más complicado.

Nuevas características de SQL

NewSQL proporciona la misma escalabilidad que noSQL y todavía se basa en el modelo relacional. También conserva el SQL extremadamente maduro como lenguaje de consulta y garantiza las características de transacción ACID.

En pocas palabras, NewSQL integra la poderosa escalabilidad de NoSQL en las bases de datos relacionales tradicionales.

No existe una arquitectura distribuida en los genes de diseño de la arquitectura SQL tradicional, pero NewSQL nació en la era de la nube y es inherentemente una arquitectura distribuida.

Características clave de NewSQL

Compatibilidad con SQL para consultas complejas y análisis de big data.
Admite transacciones ACID, admite nivel de aislamiento.
El escalado elástico, la expansión y la contracción de la capacidad son completamente transparentes para la capa empresarial.
Alta disponibilidad y recuperación automática ante desastres.

Comparación de tres tipos de SQL

imagen

¿Cómo surgió TiDB?

El autor del famoso servicio de almacenamiento en caché distribuido de código abierto Codis, cofundador y CTO de PingCAP, Huang Dongxu, ingeniero senior de infraestructura, es bueno en el diseño e implementación de sistemas de almacenamiento distribuido, y es un maestro técnico de los fanáticos del código abierto. Incluso cuando Internet es tan próspera hoy, en el área borrosa e incierta de la base de datos, todavía está tratando de encontrar una dirección de práctica determinista. Preste atención al número z oficial: columna de tecnología code ape, palabras clave de respuesta: 1111 ¡Obtenga el manual interno de optimización del rendimiento de Java de Ali!

Hasta finales de 2012 vio los dos artículos publicados por Google, como un prisma, refractando la luz en su propio corazón. Estos dos documentos describen F1/Spanner, una base de datos relacional masiva utilizada internamente por Google, que resuelve los problemas de las bases de datos relacionales, la expansión elástica y la distribución global, y se utiliza en la producción a gran escala. “Si esto se puede realizar, será subversivo para el campo del almacenamiento de datos.” Huang Dongxu estaba entusiasmado con el surgimiento de la solución perfecta, y TiDB de PingCAP nació sobre esta base.

TiDB Community Edition y Enterprise Edition

TiDB se divide en edición comunitaria y edición empresarial. La edición empresarial proporciona servicios y soporte de seguridad por una tarifa.

imagen

Características principales de TIDB

Expansión elástica horizontal

La expansión horizontal de TiDB se puede realizar simplemente agregando nuevos nodos, y el rendimiento o el almacenamiento se pueden expandir a pedido para hacer frente fácilmente a escenarios de datos masivos y de alta concurrencia.

Gracias al diseño de la arquitectura separada de computación y almacenamiento de TiDB, la expansión o reducción en línea de la computación y el almacenamiento se puede realizar bajo demanda, y el proceso de expansión o reducción es transparente para el personal de operación y mantenimiento de la aplicación.

Soporte de transacciones distribuidas

TiDB 100% admite transacciones ACID estándar

Alta disponibilidad de grado financiero

En comparación con el esquema de replicación maestro-esclavo (MS) tradicional, el protocolo de elección mayoritaria basado en Raft puede proporcionar una garantía sólida de consistencia de datos del 100% a nivel financiero y puede realizar una recuperación automática de fallas sin perder la mayoría de las copias (conmutación por falla automática), sin manual intervención

Los datos se almacenan en varias copias y las copias de datos se sincronizan con el registro de transacciones a través del protocolo Multi-Raft. La mayoría de las transacciones solo se pueden enviar después de una escritura exitosa, lo que garantiza una sólida consistencia de los datos y la disponibilidad de los datos no se verá afectada. cuando falla un pequeño número de copias. Las políticas como la ubicación geográfica y el número de réplicas se pueden configurar a pedido para cumplir con los requisitos de los diferentes niveles de recuperación ante desastres.

HTAP en tiempo real

Como una base de datos de almacenamiento en fila OLTP típica, TiDB también tiene un rendimiento OLAP potente. Con TiSpark, puede proporcionar una solución HTAP integral. Un almacenamiento puede manejar OLTP y OLAP al mismo tiempo sin el proceso ETL tradicional y engorroso.

Proporciona dos motores de almacenamiento: el motor de almacenamiento en filas TiKV y el motor de almacenamiento en columnas TiFlash TiFlash copia los datos de TiKV en tiempo real a través del protocolo Multi-Raft Learner para garantizar una sólida coherencia de datos entre el motor de almacenamiento en filas TiKV y el motor de almacenamiento en columnas TiFlash. TiKV y TiFlash se pueden implementar en diferentes máquinas según sea necesario para resolver el problema del aislamiento de recursos HTAP.

Base de datos distribuida nativa en la nube

TiDB es una base de datos diseñada para la nube. Está profundamente acoplada con Kubernetes y admite nubes públicas, nubes privadas y nubes híbridas, lo que hace que la implementación, la configuración y el mantenimiento sean muy simples. El objetivo de diseño de TiDB es un 100 % de escenarios OLTP y un 80 % de escenarios OLAP. Se pueden realizar análisis OLAP más complejos a través del proyecto TiSpark. TiDB no es intrusivo para el negocio y puede reemplazar con gracia el middleware de base de datos tradicional, la subbase de datos y la subtabla de la base de datos y otras soluciones de fragmentación. Al mismo tiempo, también permite que el personal de desarrollo y mantenimiento se concentre en el desarrollo comercial sin prestar atención a los detalles de la escala de la base de datos, lo que mejora en gran medida la productividad de la investigación y el desarrollo.

Altamente compatible con MySQL

Compatible con el protocolo MySQL 5.7, las funciones comunes de MySQL y el ecosistema MySQL, las aplicaciones se pueden migrar de MySQL a TiDB sin o con una pequeña cantidad de modificación de código.

Se proporcionan herramientas de migración de datos enriquecidos para ayudar a las aplicaciones a completar la migración de datos de manera conveniente. En la mayoría de los casos, es fácil migrar de MySQL a TiDB sin modificar el código, y el clúster de MySQL después de la división de tablas y subbases de datos también se puede migrar en tiempo real. a través de herramientas TiDB.

OLTP y OLAP (autoaprendizaje)

OLTP (procesamiento de transacciones en línea)

OLTP (Procesamiento de transacciones en línea) es el procesamiento de transacciones en línea. OLTP es la aplicación principal de las bases de datos relacionales tradicionales. Es principalmente para el procesamiento de transacciones básicas y diarias. Los registros se agregan, eliminan, modifican y verifican en tiempo real, como depositar y retirar una suma en un banco El pago es una transacción comercial

El procesamiento de transacciones en línea es un sistema muy transaccional. Generalmente es un sistema en línea de alta disponibilidad. Se enfoca principalmente en transacciones pequeñas y consultas pequeñas. Al evaluar su sistema, generalmente depende de la cantidad de Transacciones y Ejecutar SQL ejecutadas por segundo. . En tal sistema, una sola base de datos a menudo procesa cientos o miles de Transacciones por segundo, y el volumen de ejecución de las declaraciones Select es de miles o incluso decenas de miles por segundo. Los sistemas OLTP típicos incluyen sistemas de comercio electrónico, bancos, valores, etc., como la base de datos comercial de eBay en los Estados Unidos, que es una base de datos OLTP muy típica.

OLAP (procesamiento analítico en línea)

OLAP (procesamiento analítico en línea) es el núcleo del almacén de datos. Admite operaciones de análisis complejas, se centra en el apoyo a la toma de decisiones y proporciona resultados de consulta intuitivos y fáciles de entender. Una aplicación típica es un sistema complejo de informes dinámicos

En tal sistema, el volumen de ejecución de la declaración no es el estándar de evaluación, porque el tiempo de ejecución de una declaración puede ser muy largo y la lectura de datos también es muy grande. Por lo tanto, en un sistema de este tipo, el estándar de evaluación suele ser el rendimiento (ancho de banda) del subsistema de disco, como cuántos MB/s de tráfico se pueden lograr.

comparación de características

Comparación de las características de OLTP y OLAP

—	OLTP	OLAP
tiempo real	OLTP tiene altos requisitos en tiempo real, y las bases de datos OLTP están diseñadas para permitir que las aplicaciones transaccionales escriban solo los datos necesarios para procesar una sola transacción lo más rápido posible.	Los requisitos en tiempo real de OLAP no son muy altos y muchas aplicaciones actualizan los datos todos los días como máximo.
la cantidad de datos	La cantidad de datos OLTP no es muy grande, generalmente solo lee/escribe docenas de registros y maneja transacciones simples	OLAP tiene una gran cantidad de datos, porque OLAP admite consultas dinámicas, por lo que es posible que los usuarios deban recopilar una gran cantidad de datos para obtener la información que desean saber, como análisis de series temporales, etc., por lo que la cantidad de datos procesados es grande.
orientación al usuario y al sistema	OLTP está orientado al cliente para el procesamiento de consultas y transacciones	OLAP está orientado al mercado para el análisis de datos
Diseño de base de datos	OLTP adopta el modelo ER entidad-relación y el diseño de base de datos orientado a la aplicación	OLAP con esquema de estrella o copo de nieve y diseño de base de datos orientado a temas

Diferencia de ángulo de diseño

—	OLTP	OLAP
usuario	operadores, gerencia inferior	tomadores de decisiones, altos directivos
Función	Operaciones diarias	decisión de análisis
el trabajo principal	agregar, eliminar, cambiar	Preguntar
diseño de base de datos	orientado a la aplicación	orientado al tema
datos	actual, últimos detalles, bidimensional, discreto	histórico, agregado, multidimensionalmente integrado, unificado
acceso	Leer/escribir docenas de registros	leer millones de registros
empleador	asuntos simples	consulta compleja
Número de usuario	miles	cientos
Tamaño de la base de datos	100 MB-GB	100GB-TB

Arquitectura general de TiDB

Ventajas de TiDB

En comparación con las bases de datos independientes tradicionales, TiDB tiene las siguientes ventajas:

Arquitectura puramente distribuida, con buena escalabilidad, admite expansión y contracción flexibles
Admite SQL, expone el protocolo de red de MySQL al mundo exterior, es compatible con la mayoría de las sintaxis de MySQL y puede reemplazar directamente a MySQL en la mayoría de los escenarios.
La alta disponibilidad es compatible de forma predeterminada. En el caso de que falle una pequeña cantidad de réplicas, la propia base de datos puede realizar automáticamente la reparación de datos y la conmutación por error, lo cual es transparente para la empresa.
Admite transacciones ACID y es compatible con algunos escenarios con fuertes requisitos de consistencia, como transferencias bancarias
Tiene una rica ecología de cadena de herramientas, que cubre la migración de datos, la sincronización, la copia de seguridad y otros escenarios.

Componentes de TiDB

Para obtener una comprensión profunda de las funciones de expansión horizontal y alta disponibilidad de TiDB, primero debe comprender la arquitectura general de TiDB. El clúster TiDB incluye principalmente tres componentes principales: TiDB Server, PD Server y TiKV Server Además, hay un componente TiSpark para resolver las necesidades complejas de OLAP de los usuarios. Preste atención al número z oficial: columna de tecnología code ape, palabras clave de respuesta: 1111 ¡Obtenga el manual interno de optimización del rendimiento de Java de Ali!

En términos de diseño del kernel, la base de datos distribuida de TiDB divide la arquitectura general en múltiples módulos, y cada módulo se comunica entre sí para formar un sistema TiDB completo. El diagrama de arquitectura correspondiente es el siguiente:

imagen

arquitectura

Servidor TiDB

TiDB Server es responsable de recibir solicitudes SQL, procesar la lógica relacionada con SQL, encontrar la dirección TiKV para almacenar los datos necesarios para el cálculo a través de PD, interactuar con TiKV para obtener datos y, finalmente, devolver el resultado. TiDB Server no tiene estado, no almacena datos en sí mismo, solo es responsable de la informática, se puede expandir horizontalmente de forma indefinida y puede proporcionar una dirección de acceso unificada externamente a través de componentes de equilibrio de carga (como LVS, HAProxy o F5).

Servidor PD (controlador de ubicación)

Placement Driver (conocido como PD) es el módulo de gestión de todo el clúster. Tiene tres tareas principales:

Una es almacenar la metainformación del clúster (en qué nodo TiKV se almacena una clave);
El segundo es programar y equilibrar la carga del clúster TiKV (como la migración de datos, la migración del líder del grupo Raft, etc.);
El tercero es asignar una identificación de transacción incremental y única globalmente.

PD garantiza la seguridad de los datos a través del protocolo Raft. El servidor líder de Raft es responsable de manejar todas las operaciones y los servidores PD restantes solo se utilizan para garantizar una alta disponibilidad. Se recomienda implementar un número impar de nodos PD

Servidor TiKV

TiKV Server es responsable de almacenar datos.Desde el exterior, TiKV es un motor de almacenamiento de valor clave distribuido que proporciona transacciones. La unidad básica para el almacenamiento de datos es la región, y cada región es responsable de almacenar los datos de un rango de claves (el intervalo cerrado por la izquierda y abierto por la derecha desde StartKey hasta EndKey), y cada nodo TiKV es responsable de varias regiones. TiKV utiliza el protocolo Raft para la replicación a fin de mantener la coherencia de los datos y la recuperación ante desastres. Las réplicas se administran en unidades de regiones, y varias regiones en diferentes nodos forman un grupo de balsa, que son réplicas entre sí. El equilibrio de carga de datos entre varios TiKV está programado por PD, que también está programado en unidades de Regiones.

tichispa

TiSpark, como componente principal de TiDB para resolver las necesidades complejas de OLAP de los usuarios, ejecuta Spark SQL directamente en la capa de almacenamiento de TiDB y, al mismo tiempo, integra las ventajas de los clústeres distribuidos de TiKV y se integra en la ecología de la comunidad de big data. Hasta ahora, TiDB puede soportar tanto OLTP como OLAP a través de un sistema, eliminando el problema de la sincronización de datos de usuario.

TiFlash

TiFlash es un tipo especial de nodo de almacenamiento. A diferencia de los nodos ordinarios de TiKV, dentro de TiFlash, los datos se almacenan en forma de columnas y su función principal es acelerar los escenarios analíticos.

Estructura general de TiKV

A diferencia del método tradicional de copia de seguridad de nodo completo, TiKV divide los datos en segmentos aproximadamente iguales (en lo sucesivo denominados colectivamente Regiones) de acuerdo con el rango de la clave. Cada segmento tiene varias copias (generalmente 3), una de las cuales es líder, proporcionar servicios de lectura y escritura. TiKV programa estas regiones y réplicas a través de PD para garantizar que los datos y las cargas de lectura y escritura se distribuyan uniformemente en cada TiKV. Este diseño garantiza la utilización completa de todo el recurso del clúster y se puede escalar horizontalmente a medida que aumenta la cantidad de máquinas.

imagen

Dividir y fusionar regiones

Cuando el tamaño de una región supera cierto límite (144 MB de forma predeterminada), TiKV la dividirá en dos o más regiones para garantizar que los tamaños de cada región sean más o menos similares, lo que es más propicio para la decisión de programación de PD. De manera similar, cuando una región se vuelve más pequeña debido a una gran cantidad de solicitudes de eliminación, TiKV fusionará dos regiones adyacentes más pequeñas en una sola.

Programación de regiones

La coherencia de datos se mantiene entre la región y la réplica a través del protocolo Raft. Cualquier solicitud de escritura solo se puede escribir en el líder y debe escribirse en la mayoría de las réplicas (la configuración predeterminada es 3 réplicas, es decir, todas las solicitudes debe escribirse con éxito en al menos dos réplicas) devolverá el éxito de escritura del cliente.

Cuando PD necesita programar una copia de una región de un nodo TiKV a otro, PD primero agregará una copia de alumno (datos de líder de copia) para este grupo de balsa en el nodo de destino. Cuando el progreso de la copia del alumno alcanza aproximadamente el nivel de la copia del líder, el líder lo cambiará a un seguidor y luego eliminará la copia del seguidor del nodo de operación, completando así una programación de la copia de la región.

El principio de programación de la copia de Líder es similar, pero después de que la copia de Aprendiz del nodo de destino se convierte en una copia de Seguidor, se ejecuta nuevamente una Transferencia de Líder, de modo que el Seguidor inicia una elección para convertirse en el nuevo Líder, y luego el nuevo Líder es responsable de eliminar la copia anterior de Leader.

transacción distribuida

TiKV admite transacciones distribuidas. Los usuarios (o TiDB) pueden escribir varios valores clave a la vez sin importar si estos valores clave están en el mismo segmento de datos (Región). TiKV garantiza estas solicitudes de lectura y escritura a través de dos restricciones ACID de confirmación de fase.

Arquitectura de alta disponibilidad

La alta disponibilidad es otra característica importante de TiDB.Los tres componentes de TiDB/TiKV/PD pueden tolerar fallas en algunas instancias sin afectar la disponibilidad de todo el clúster. A continuación, se describe la disponibilidad de estos tres componentes, las consecuencias de una falla de instancia única y cómo recuperarse.

Alta disponibilidad de TiDB

TiDB no tiene estado. Se recomienda implementar al menos dos instancias, y el front-end proporciona servicios externos a través del componente de equilibrio de carga. Cuando una sola instancia falla, afectará la sesión en curso en esta instancia.Desde el punto de vista de la aplicación, habrá una sola solicitud fallida y el servicio se puede seguir obteniendo después de volver a conectar. Después de que falla una sola instancia, se puede reiniciar o implementar una nueva instancia.

PD alta disponibilidad

PD es un clúster que mantiene la consistencia de los datos a través del protocolo Raft. Cuando una sola instancia falla, si la instancia no es líder de Raft, el servicio no se verá afectado en absoluto; si la instancia es líder de Raft, una nueva instancia de Raft líder será reelegido, para restaurar automáticamente el servicio. PD no puede prestar servicios externos durante el proceso electoral, y este tiempo es de unos 3 segundos. Se recomienda implementar al menos tres instancias de PD. Después de que falle una sola instancia, reiníciela o agregue una nueva instancia.

Alta disponibilidad TiKV

TiKV es un clúster que mantiene la coherencia de los datos a través del protocolo Raft (la cantidad de copias es configurable y se guardan tres copias de forma predeterminada) y utiliza PD para la programación del equilibrio de carga. Cuando falla un solo nodo, afectará a todas las regiones almacenadas en este nodo. Para el nodo Líder en la Región, el servicio será interrumpido y esperará la reelección, para el nodo Seguidor en la Región, el servicio no se verá afectado. Cuando un nodo TiKV falla y no se puede recuperar dentro de un período de tiempo (10 minutos de forma predeterminada), PD migrará los datos que contiene a otros nodos TiKV.

Escenario de aplicación

Fragmentación y fusión de MySQL

imagen

El primer tipo de escenario en el que se aplica TiDB es la fragmentación y fusión de MySQL. Para las empresas que ya usan MySQL, las subbases de datos, las tablas, los fragmentos y el middleware son métodos comúnmente utilizados.Con el aumento de fragmentos, la consulta entre fragmentos es un gran problema. TiDB es compatible con el protocolo de acceso MySQL en la capa empresarial. PingCAP ha creado una herramienta de sincronización de datos: Syncer, que puede usar TiDB de Dongxu Huang como esclavo de MySQL y conectar TiDB como biblioteca esclava de la base de datos existente detrás de la biblioteca principal de MySQL. Esta capa conecta los datos y puede realizar directamente consultas complejas de SQL en tiempo real entre bases de datos, entre tablas y entre empresas. Huang Dongxu mencionó: "En el pasado, las bases de datos tenían un maestro y varios esclavos. Con TiDB, se puede invertir para lograr varios maestros y un esclavo".

Reemplazo directo para MySQL

imagen

El segundo tipo de escenario es reemplazar directamente MySQL con TiDB. Si su arquitectura de TI no considera el problema de la subbase de datos y la subtabla al comienzo de la construcción, y todos usan MySQL, con el rápido crecimiento de los negocios, hay cada vez más escenarios OLTP masivos y de alta concurrencia. resolver los inconvenientes de la arquitectura?

En una base de datos TiDB, no es necesario dividir todos los escenarios comerciales en bases de datos y tablas, y todo el trabajo distribuido lo realiza la capa de la base de datos. TiDB es compatible con el protocolo MySQL, por lo que puede reemplazar directamente a MySQL, y básicamente funciona de inmediato. No hay necesidad de preocuparse por la gran carga de trabajo y los complicados costos de mantenimiento que conlleva el esquema tradicional de división de tablas y bases de datos. La interfaz de usuario permite que los técnicos regulares puedan realizar el mantenimiento y la administración de manera eficiente. Además, TiDB tiene una capacidad similar a la de NoSQL y puede mejorar la capacidad de soporte comercial del sistema a través de la expansión horizontal cuando la cantidad de datos y el tráfico de acceso continúan creciendo y el retraso de respuesta es estable.

base de datos

imagen

TiDB en sí mismo es un sistema distribuido, y el tercer escenario de uso es usar TiDB como almacén de datos. TPC-H es un conjunto de prueba en el campo del análisis de datos. El rendimiento de TiDB 2.0 en escenarios OLAP ha mejorado mucho. Algunas consultas complejas que solo se pueden ejecutar en el almacén de datos se pueden ejecutar en TiDB 2.0, y el tiempo puede básicamente ser controlado en 10 segundos. Por supuesto, debido a que el alcance de OLAP es muy amplio, el SQL de TiDB también es incierto. Por esta razón, PingCAP tiene TiSpark de código abierto. TiSpark es un complemento de Spark. Los usuarios pueden usar Spark SQL directamente para realizar análisis de big data en TiKV en tiempo real.

como módulo para otros sistemas

imagen

TiDB es un proyecto tradicional que separa el almacenamiento y la computación. Su capa clave-valor subyacente se puede usar sola como un reemplazo de HBase y admite transacciones de filas cruzadas. TiDB proporciona dos interfaces API externas, una es ACID Transaction API, que se utiliza para admitir transacciones entre filas; la otra es Raw API, que puede realizar transacciones de una sola fila a cambio de una mejora general del rendimiento, pero no proporciona ACID para transacciones cruzadas. -soporte de transacciones de fila. Los usuarios pueden elegir entre las dos API según sus propias necesidades. Por ejemplo, algunos usuarios han implementado directamente el protocolo Redis además de TiKV, reemplazando TiKV con algunos escenarios de Redis con requisitos de gran capacidad y baja latencia.

Aplicaciones

imagen

Comparación de compatibilidad entre TiDB y MySQL

TiDB admite el protocolo de transporte MySQL y la mayor parte de su sintaxis. Esto significa que sus clientes y conectores MySQL existentes seguirán funcionando. En la mayoría de los casos, sus aplicaciones existentes se pueden migrar a TiDB sin modificar el código.
La versión oficial actual del servidor TiDB es MySQL 5.7 . La mayoría de las herramientas de operación y mantenimiento de MySQL (como PHPMyAdmin, Navicat, MySQL Workbench, etc.), así como las herramientas de respaldo y recuperación (como mysqldump, Mydumper/myloader) se pueden usar directamente.
Sin embargo, debido a que algunas funciones no se pueden implementar bien en un entorno distribuido, por el momento no se admiten o su rendimiento es diferente al de MySQL.
Parte de la sintaxis de MySQL se puede analizar y pasar en TiDB, pero no se realizará ningún procesamiento posterior Por ejemplo, el motor en la instrucción Create Table se analiza y se ignora.

Funciones de MySql no compatibles con TiDB

procedimientos almacenados y funciones
desencadenar
evento
función personalizada
Restricciones de clave externa
Mesas temporales
Índices y funciones de texto completo/espaciales
no ascii- latin1//// juego de caracteres binary_ utf8_utf8mb4
esquema SIS
Optimizador de seguimiento de MySQL
Funciones XML
Protocolo X
Puntos de guardado
permisos de nivel de columna
XA Sintaxis (TiDB usa confirmación de dos fases internamente, pero no se expone a través de la interfaz SQL)
CREATE TABLE tblName AS SELECT stmt gramática
CHECK TABLE gramática
CHECKSUM TABLE gramática
GET_LOCK y RELEASE_LOCK funciones

ID de incremento automático

Solo se garantiza que la columna de incremento automático de TiDB sea única, y también se puede garantizar que se incremente automáticamente en un solo servidor TiDB, pero no se garantiza que se incremente automáticamente en varios servidores TiDB, y la continuidad de Los valores asignados automáticamente no están garantizados. Se recomienda no combinar los valores predeterminados con los personalizados. Los valores se mezclan y se pueden recibir Duplicated Error mensajes de error .

tidb_allow_remove_auto_inc TiDB puede habilitar o deshabilitar el atributo que permite la eliminación de columnas a través de variables del sistema AUTO_INCREMENT . La sintaxis para eliminar un atributo de columna es: alter table modify o alter table change.

TiDB no admite AUTO_INCREMENT el atributo de agregar columnas y no se puede restaurar después de eliminar este atributo.

Limitaciones de SELECT

SELECT ... INTO @变量 Sintaxis no admitida .
SELECT ... GROUP BY ... WITH ROLLUP Sintaxis no admitida .
SELECT .. GROUP BY expr Los resultados devueltos en TiDB no son consistentes con MySQL 5.7. El resultado para MySQL 5.7 es equivalente a GROUP BY expr ORDER BY expr. Sin embargo, los resultados devueltos por esta sintaxis en TiDB no prometen ningún orden, lo cual es consistente con el comportamiento de MySQL 8.0.

vista

TiDB actualmente no admite operaciones de escritura como ACTUALIZAR, INSERTAR y ELIMINAR en las vistas .

Diferencias en la configuración predeterminada

conjunto de caracteres

Valor predeterminado de TiDB: utf8mb4.
Valor predeterminado de MySQL 5.7: latin1.
Valor predeterminado de MySQL 8.0: utf8mb4.

colación

utf8mb4 Conjunto de caracteres predeterminado en TiDB : utf8mb4_bin.
utf8mb4 Conjunto de caracteres predeterminado en MySQL 5.7 : utf8mb4_general_ci.
utf8mb4 Conjunto de caracteres predeterminado en MySQL 8.0 : utf8mb4_0900_ai_ci.

Distingue mayúsculas y minúsculas

Acerca lower_case_table_namesde la configuración

Valor predeterminado de TiDB: 2y solo admite la configuración de este valor 2.
Los valores predeterminados de MySQL son los siguientes:
- En el sistema Linux, el valor es 0
En sistemas Windows este valor es 1
En el sistema macOS, el valor es 2

explicación de parámetros

lower_case_table_names=0 los nombres de las tablas se almacenan con el tamaño dado y las comparaciones distinguen entre mayúsculas y minúsculas
lower_case_table_names = 1 El nombre de la tabla se almacena en minúsculas en el disco, pero no distingue entre mayúsculas y minúsculas al comparar
lower_case_table_names=2 nombres de tablas se almacenan en el caso dado pero se comparan en minúsculas

actualización de campo de tipo de marca de tiempo

De forma predeterminada, cuando se actualiza la fila de datos donde se encuentra el campo de tipo de marca de tiempo, el campo se actualizará automáticamente a la hora actual y el parámetro explicit_defaults_for_timestamp controla este comportamiento.

Valor predeterminado de TiDB: ONy solo admite la configuración de este valor ON.
Valor predeterminado de MySQL 5.7: OFF.
Valor predeterminado de MySQL 8.0: ON.

explicación de parámetros

explicit_defaults_for_timestamp=off, cuando se actualiza la fila de datos, el campo de tipo de marca de tiempo se actualiza a la hora actual
explicit_defaults_for_timestamp=on, cuando se actualiza la fila de datos, el campo de tipo de marca de tiempo no se actualizará a la hora actual.

soporte de clave externa

Valor predeterminado de TiDB: OFFy solo admite la configuración de este valor OFF.
Valor predeterminado de MySQL 5.7: ON.