La forma FOREIGN KEY Las restricciones se implementan en MySQL (o, más bien, en el motor de almacenamiento InnoDB) interfieren con las operaciones DDL en línea. Obtenga más información en esta publicación de blog de Vitess.

Limitado a un solo ámbito de servidor MySQL, FOREIGN KEY las restricciones son imposibles de mantener una vez que sus datos crecen y se dividen en múltiples servidores de bases de datos. Esto suele suceder cuando introduce particiones/fragmentaciones funcionales y/o fragmentaciones horizontales.

Esto me llevó a pensar:haz FOREIGN KEY restricciones afectan la escalabilidad en general? y si es así, ¿cómo?

Creo que es importante darse cuenta de que las uniones de tablas SQL son bastante costosas, pero que yo sepa, ¿no se vio muy afectado por la integridad referencial? Ahora, si estamos haciendo algo como el análisis de datos, obviamente no necesitamos integridad referencial, ya que solo queremos volcar nuestros datos en una sola tabla, pero PlanetScale y Vitess se jactan de ser utilizados por grandes aplicaciones web. como YouTube.

Esto me llevó a estar confundido sobre por qué dejarían caer la FOREIGN KEY restricción ya que las bases de datos como CockroachDB y Spanner aún mantienen la integridad referencial además de ser escalables.

¿Qué es la integridad referencial y por qué es importante?

Comencemos con lo básico, en caso de que seas nuevo. Supongo que la mayoría de las personas que leen esta publicación tienen una idea clara de lo que están hablando, pero lo explicaré como una formalidad. En palabras simples, una FOREIGN KEY La restricción es una clave de base de datos que podemos usar para crear relaciones entre dos tablas diferentes haciendo referencia a una columna o un conjunto de columnas. La integridad referencial simplemente se refiere al estado de la base de datos en el que todos los valores de todas las claves son válidos.

¿Por qué es importante?

Ahora que tenemos una idea de lo que son, pasemos a la segunda parte:¿por qué son importantes?

La integridad referencial es importante ya que le impide introducir nuevos errores en su base de datos. Es una función que suelen proporcionar las bases de datos relacionales que impide que los usuarios o las aplicaciones introduzcan datos incoherentes en la base de datos. Esto conduce a una mejor calidad de los datos, un desarrollo más rápido, muchos menos errores y coherencia en toda su aplicación.

¿Por qué Vitess no lo tiene?

Entonces, para comprender por qué Vitess no puede admitir la integridad referencial, debemos sumergirnos en la arquitectura de la base de datos. Vitess es una base de datos SQL no ACID fragmentada, no una verdadera base de datos ACID SQL distribuida.

Ahora, debes estar preguntándote cuáles son esos términos. Déjame desglosarlos:ACID es un acrónimo de atomicidad, consistencia, aislamiento y durabilidad.

Aquí, la atomicidad se refiere a una acción que se completa o falla por completo, sin finalización parcial de una transacción. La consistencia se refiere a que la transacción deja la base de datos en un estado válido. El aislamiento simplemente significa que dos transacciones se ejecutan sin ninguna interferencia entre sí, y la durabilidad significa que se guardan los cambios de la transacción.

Un fragmento es una partición horizontal de datos en una base de datos, y cada fragmento se mantiene en una instancia de servidor de base de datos separada para distribuir la carga. Entonces, cuando nos referimos a una base de datos fragmentada, estamos hablando de algo como esto. Ahora, como dije antes, Vitess es una base de datos SQL fragmentada que no es ACID, lo que básicamente significa que NO garantiza las propiedades ACID de las transacciones.

¿Por qué dejarlo?

Bueno, el problema comienza cuando tiene una base de datos MySQL con un esquema bien definido, y su servicio se vuelve popular con el problema de demasiadas lecturas en la base de datos. Lo que la mayoría de la gente hace aquí es almacenar en caché las consultas que se ejecutan con frecuencia, pero las lecturas ya no son ACIDic.

Junto con demasiadas lecturas, tener una cantidad excesiva de escrituras en su base de datos es un problema grave que muchos pueden enfrentar. Digamos que estamos listos para incendiar nuestros bolsillos:podemos escalar verticalmente, agregando más RAM, un procesador de 16 núcleos y un montón de unidades de estado sólido realmente rápidas.

Por supuesto, todavía tenemos el problema de las uniones de tablas SQL que aumentan en complejidad, por lo que comienza a desnormalizar para evitar uniones entre tablas.

Di una charla en el Prisma Meetup hace un tiempo, donde expliqué los fundamentos del diseño de una base de datos relacional. Un tema que cubrí aquí fue la desnormalización. Si está interesado, asegúrese de consultarlo.

Pero la desnormalización es básicamente el proceso en el que agrega datos redundantes a las tablas de su base de datos, lo que mejora el rendimiento en el costo del espacio en disco, ya que ya no usa la potencia de la CPU para las uniones. Si bien la desnormalización mejora la velocidad de las lecturas, es importante darse cuenta de que hace que las escrituras sean más lentas.

Sin embargo, a pesar de todo esto, nuestra base de datos sigue siendo lenta, por lo que trasladamos los cálculos de la base de datos al cliente, por ejemplo, generando un UUID o asignando una fecha.

Incluso después de todo esto, las consultas seguirán siendo lentas, por lo que mantenemos listo el resultado de los datos más consultados en un proceso conocido como materialización de la base de datos. Ahora, las lecturas pueden ser más rápidas, pero las escrituras son cada vez más lentas. La única situación lógica ahora es eliminar los índices secundarios.

Entonces, en este punto, nuestra base de datos tiene

• No hay propiedades de ACID debido al almacenamiento en caché
• Sin esquema normalizado
• Sin disparadores
• Sin cálculos de base de datos
• Sin índices secundarios

Esto allanó el camino para las bases de datos Vitess y NoSQL, ya que las empresas tenían problemas para escalar su base de datos. Por la forma en que se diseñó, no pudieron mantener la consistencia de los datos, una propiedad de ACID, cuando las transacciones abarcaban varios fragmentos diferentes. La integridad referencial tiene que ver con la consistencia cuando los datos se extienden a través de múltiples fragmentos, por lo tanto, tiene sentido que no puedan admitirlo bien.

Podemos profundizar en la estructura de las bases de datos NoSQL sin FOREIGN KEY restricciones y problemas que enfrentaremos al adoptar ese modelo, pero ese es el tema para otra publicación.

No es solo Vitess, ha sido una práctica estándar para las bases de datos fragmentadas para evitar la integridad referencial, ya que simplemente no hay otra opción. En términos del modelo ACID, su documentación establece que garantizan la atomicidad pero no el aislamiento, e incluso llegan a decir: