Separación de lectura-escritura
Cuando el negocio de una empresa sigue creciendo y el número de usuarios aumenta significativamente, es probable que la base de datos original no pueda mantenerse por sí misma. Entonces sí
- Scale-in, que amplía el rendimiento del hardware, pero es probable que el número de usuarios siga creciendo y el aumento de rendimiento pronto se vea reducido.
- Separación de lectura y escritura: La base de datos no puede mantener, no es más que demasiada lectura y escritura, especialmente si hay consultas complejas como los productos más populares de las últimas 24 horas. Requiere sentencias SQL muy complejas y, por supuesto, es lento de ejecutar.
Sin embargo, para separar lecturas y escrituras, la base de datos debe dividirse en bibliotecas maestras y esclavas.
Las principales bases de datos relacionales del mercado soportan replicación de datos, por lo que puedes dividir una base de datos en dos roles: Master y Slave, escribir operaciones en el master y sincronizar el servidor master con otros servidores esclavos.
Las operaciones offline, como las operaciones de lectura y análisis de datos, se realizan en el servidor esclavo.
Sabemos que muchas aplicaciones en Internet se leen, de modo que varios esclavos pueden compartir la carga y garantizar la disponibilidad y corrección de los datos.
Sin embargo, también es necesario modificar el código original de la aplicación correspondiente, y debe cambiarse para usar la biblioteca maestra para escribir datos, y usar la biblioteca esclava al leer datos, lo que equivale a reescribir.
Consultas complejas
Sin embargo, incluso después de reescribir el código, descubrí que el rendimiento no mejoraba significativamente porque se usaban demasiadas consultas complejas, y hemos dicho en el componente de base de datos que las uniones requieren mucho rendimiento.
¿Podemos usar una tabla separada para almacenar los productos populares de las últimas 24 horas, de modo que solo necesitemos usar SQL simple para hacerlo?
En otras palabras, un único conjunto de tablas de base de datos es inapropiado para diferentes comportamientos como informes, búsquedas, transacciones, etc.
La tabla actual está diseñada para añadir y modificar datos, y no es adecuada para consultas complejas.
Pero también debemos considerar cómo se actualiza esta base de consultas, o si podemos tolerar este retraso, si puede que no se actualice en tiempo real.
CQRS
Si el retraso puede tolerarse debe verse desde una perspectiva empresarial, como los productos populares de las últimas 24 horas; un poco de información desactualizada no tiene mucho impacto, solo se requiere la consistencia final.
Podemos usar CQRS (Segregación de Responsabilidad por Consultas de Comandos), es decir, la separación de comandos para añadir o modificar comandos de las responsabilidades de consulta.
En CQRS, el énfasis está en la separación entre lectura (consulta) y escritura (comando), porque los datos leídos por los usuarios suelen estar desactualizados, así que ¿por qué necesitar leer desde la base de datos? Puedes establecer directamente una fuente de datos de lectura. Puede ser caché, puede ser XML, JSON, etc.
¿Cómo resolver el problema de cómo actualizar mencionado antes? Puedes usar Evento, es decir, un evento, por ejemplo, cuando se vende un producto, puedes publicar un evento para modificar el Modelo de Lectura original.
De este modo, la sincronización se vuelve asíncrona a través del mecanismo de eventos.
Finalmente, este método se utiliza mejor solo para consultas complejas, y las consultas simples originales siguen siendo obtenidas en la base de datos relacional. ¿Por qué? Debido a que la introducción de una nueva tecnología requiere un precio, como pasos de mutación síncrona y mecanismos de eventos, no podemos ver solo las ventajas de las nuevas tecnologías y no las desventajas.
|
Publicado en 4/5/2020 9:58:50
|
|
|
|
