¿Por qué es necesario dividir la base de datos en bases de datos y tablas?

1 Idea básica: ¿Qué es una subbase de datos y una subtabla?

Simplemente entendido desde el significado literal, significa almacenar los datos originalmente almacenados en una base de datos en bloques en múltiples bibliotecas, y almacenar los datos originalmente almacenados en una tabla en bloques en múltiples tablas.

2 Idea básica: ¿Por qué deberíamos separar bases de datos y tablas?

Datos

La cantidad de datos en la base de datos no es necesariamente controlable. Sin subbases de datos y tablas, con el desarrollo del tiempo y los negocios, la cantidad de datos en la base de datos aumentará. Habrá más y más tablas y la cantidad de datos en las tablas también será cada vez mayor. En consecuencia, la sobrecarga de operaciones de datos, adiciones, eliminaciones, modificaciones y consultas también será cada vez mayor. debido a la incapacidad de distribuir Los recursos de un servidor (CPU, disco, memoria, IO, etc.) son limitados y, eventualmente, la cantidad de datos que la base de datos puede transportar y sus capacidades de procesamiento de datos encontrarán cuellos de botella.

3 Estrategias de implementación para fragmentar bases de datos y tablas.

Existen dos tipos de fragmentación de bases de datos y tablas: fragmentación vertical y fragmentación horizontal.

3.1

¿Qué es la segmentación vertical, es decir, dividir tablas según módulos funcionales y relaciones cercanas, e implementarlas en diferentes bibliotecas? Por ejemplo, estableceremos la base de datos de definición workDB, la base de datos de productos payDB, la biblioteca de datos de usuario userDB, la base de datos de registro logDB, etc., que se utilizan para almacenar la tabla de definición de datos del proyecto, la tabla de definición de producto, la tabla de datos de usuario y la tabla de datos de registro respectivamente. . esperar.

3.2

¿Qué es la segmentación horizontal? Cuando la cantidad de datos en una tabla es demasiado grande, podemos dividir los datos en la tabla de acuerdo con ciertas reglas, como el hash de ID de usuario. y luego se almacena en varias tablas con la misma estructura y diferentes bibliotecas

. Por ejemplo, en las tablas de datos de usuario en nuestra base de datos de usuario, cada tabla tiene una gran cantidad de datos, por lo que la base de datos de usuario se puede dividir en múltiples bases de datos de usuario con la misma estructura: part0DB, part1DB, etc., y luego la tabla de datos de usuario userTable en userDB se divide en muchas tablas de usuarios: userTable0, userTable1, etc.

Luego, estas tablas se almacenan en múltiples userDB de acuerdo con ciertas reglas.

3.3 El método que se debe utilizar para implementar la fragmentación de bases de datos y de tablas depende del cuello de botella del volumen de datos en la base de datos y del tipo de negocio del proyecto.

Si la base de datos genera datos masivos debido a demasiadas tablas y la lógica de negocios del proyecto está claramente dividida y poco acoplada, entonces la segmentación vertical con reglas simples y fáciles de implementar debe ser la solución. primera opción.

Y

Si no hay muchas tablas en la base de datos, pero la cantidad de datos en una sola tabla es grande, o los datos son muy populares, en este caso debes elegir fragmentación horizontal, la segmentación horizontal es más complicada que la segmentación vertical. Separa físicamente los datos que originalmente pertenecían lógicamente a una entidad. Además de evaluar la granularidad de la segmentación durante la segmentación, se debe considerar la suma promedio de los datos. También impondrá una carga adicional de gestión de datos al personal del proyecto y a las aplicaciones en el futuro.

En proyectos reales, estas dos situaciones a menudo se combinan, lo que requiere una compensación, e incluso requiere una segmentación tanto vertical como horizontal. Nuestro proyecto de juego utiliza una combinación de segmentación vertical y horizontal. Primero segmentamos verticalmente la base de datos y luego segmentamos horizontalmente una parte de la tabla, generalmente la tabla de datos del usuario.

4 Problemas con subbases de datos y subtablas.

4.1 Problemas de transacción.

Después de dividir la base de datos y la tabla, la gestión de transacciones de la base de datos se volvió difícil porque los datos se almacenaban en diferentes bases de datos. Si confía en la función de gestión de transacciones distribuidas de la propia base de datos para ejecutar transacciones, pagará un alto precio de rendimiento; si la aplicación ayuda en el control y forma una transacción lógica de programa, también causará una carga de programación;

4.2 Problemas de unión entre bases de datos y tablas.

Después de realizar la fragmentación de bases de datos y tablas, es inevitable que los datos originalmente altamente relacionados lógicamente se dividan en diferentes tablas y diferentes bibliotecas. En este momento, las operaciones de asociación de las tablas no estarán restringidas. unir tablas ubicadas en diferentes subbases de datos, ni podemos unir tablas con diferentes granularidades de subtablas. Como resultado, el negocio que se puede completar con una consulta puede requerir varias consultas para completarse.

4.3 Carga adicional de gestión de datos y presión informática de datos.

Cargas adicionales de la gestión de datos

Las más obvias son el problema de la ubicación de los datos y la ejecución repetida de adición, eliminación, modificación y consulta de datos. Estos se pueden resolver a través de aplicaciones, pero. deben Provocar operaciones lógicas adicionales. Por ejemplo, para

una tabla de datos de usuario userTable que registra los resultados del usuario, la empresa requiere encontrar los 100 mejores resultados Antes de dividir la tabla, solo se requiere un orden

Se puede hacer por declaración, pero después de dividir la tabla, se necesitarán n órdenes

por declaraciones para encontrar los 100 datos de usuario principales de cada tabla y luego compararlos. Los datos se combinan y calculado para obtener el resultado.