¿Por qué usar redis en lugar de mysql cuando hay muchos datos?
En términos generales, cuando hay muchos datos y una gran cantidad de concurrencia, se puede introducir Redis en la arquitectura para ayudar a mejorar el rendimiento general de la arquitectura y reducir la presión sobre Mysql (u otras bases de datos). ). Pero en lugar de usar Redis, simplemente no es necesario MySQL.
Debido a que el rendimiento de Redis es muy superior, puede admitir cientos de miles de operaciones de lectura/escritura por segundo y también admite persistencia, implementación de clústeres, distribución, sincronización maestro-esclavo, etc., Redis La seguridad y coherencia de los datos en escenarios tiene alta concurrencia, por lo que a menudo se usa en dos escenarios:
Almacenamiento en caché
Para determinar si los datos son adecuados para el almacenamiento en caché en Redis, debe Puedes considerar varios aspectos: ¿Lo comprobarás con frecuencia? ¿Cuál es la tasa de aciertos? ¿Cuántas operaciones de escritura hay? ¿Tamaño de datos?
A menudo usamos este método para enviar datos a Redis: llega la solicitud de consulta y ahora la consulta está en Redis. Si no se puede encontrar la consulta, consulte la base de datos para obtenerla. los datos y luego colóquelos en el caché, de modo que la segunda vez que llegue la misma solicitud de consulta, pueda obtener los datos directamente en Redis; sin embargo, debe prestar atención al problema de la penetración del caché;
Actualizar el caché será más complicado. Por lo general, después de modificar la base de datos, debe operar los datos en Redis, el código es muy simple, pero debe asegurarse de que los dos pasos sean la misma transacción; o la transacción final es consistente con el sexo.
Lectura y escritura de alta velocidad
Los más comunes son los contadores, como el número de lecturas de un artículo. Es imposible actualizar la base de datos cada vez que se lee.
Los escenarios de alta concurrencia son muy adecuados para usar Redis. Por ejemplo, durante la venta flash de Double 11, el inventario es de solo mil piezas. Cuando llega el momento de la venta flash, generalmente habrá decenas de miles. elementos en un período de tiempo muy corto. La solicitud llega al servidor. Si se usa una base de datos, es probable que la base de datos falle en este momento, por lo que generalmente se usa Redis (el escenario de venta flash es más complicado y Redis). es solo uno de ellos. Por ejemplo, si la solicitud excede un cierto número, las solicitudes redundantes se limitarán).
En este escenario de alta concurrencia, cuando una solicitud llega al servidor, se lee y escribe directamente en Redis, y la solicitud no accederá a la base de datos y el programa se ejecutará en el momento apropiado, por ejemplo; como cuando mil piezas de inventario se eliminan instantáneamente y luego se escriben los datos en lotes en la base de datos.
En términos generales, introducir Redis cuando sea necesario puede reducir la presión sobre las bases de datos MySQL (u otras). Los dos no son sustitutos.
Continuaré compartiendo mis conocimientos sobre el desarrollo de Java, el diseño de arquitectura, el desarrollo profesional de programadores, etc., y espero llamar su atención.
Los escenarios de aplicación de Redis y MySQL son diferentes.
En términos generales, no existe el uso de Redis en lugar de MySQL.
Porque Redis es una base de datos no relacional (NoSQL) y MySQL es una base de datos relacional.
Las bases de datos similares a Redis incluyen MongoDB y Memchache (que en realidad no tienen datos persistentes)
Las bases de datos relacionales de uso común ahora incluyen MySQL, SQL Server y Oracle.
Primero comprendamos la diferencia entre bases de datos relacionales y bases de datos no relacionales. 1. Método de almacenamiento
Una base de datos relacional está en formato tabular, por lo que se almacena en filas y columnas de tablas. Les resulta fácil asociarse y colaborar entre sí para el almacenamiento, y es muy conveniente extraer datos. Por el contrario, la base de datos Nosql se compone de bloques grandes. Generalmente se almacena en un conjunto de datos, como un documento, un par clave-valor o una estructura gráfica.
2. Estructura de almacenamiento
La base de datos relacional corresponde a datos estructurados. Las tablas de datos tienen estructuras predefinidas (definiciones de columnas) y la estructura describe la forma y el contenido de los datos. Esto es crucial para el modelado de datos. Aunque las estructuras predefinidas aportan confiabilidad y estabilidad, modificar estos datos es difícil. La base de datos Nosql se basa en una estructura dinámica y utiliza datos no estructurados. Debido a que la base de datos Nosql es una estructura dinámica, puede adaptarse fácilmente a los cambios en el tipo y la estructura de los datos. 3. Especificaciones de almacenamiento
Para lograr una mayor estandarización del almacenamiento de datos en bases de datos relacionales, los datos se dividen en las tablas relacionales más pequeñas para evitar la duplicación y lograr una utilización optimizada del espacio. Aunque la gestión es muy clara, cuando se diseña una sola operación en varias tablas, la gestión de datos se vuelve un poco problemática. Los datos Nosql se almacenan en conjuntos de datos planos y, a menudo, los datos pueden repetirse. Una única base de datos rara vez se separa, sino que se almacena como un todo, de modo que todos los datos son más fáciles de leer y escribir. 4. Expansión de almacenamiento
Esta puede ser la mayor diferencia entre las dos bases de datos relacionales. expansión vertical, lo que significa que si desea aumentar la potencia de procesamiento, necesita utilizar una computadora más rápida. Debido a que los datos se almacenan en tablas relacionales, el cuello de botella en el rendimiento de la operación puede involucrar varias tablas y debe superarse mejorando el rendimiento de la computadora. Aunque hay mucho espacio para la expansión, eventualmente se alcanzará el límite superior de expansión vertical. La base de datos Nosql es escalable horizontalmente y su almacenamiento se distribuye de forma natural. La carga se puede compartir agregando más servidores de bases de datos comunes al grupo de recursos. 5. Método de consulta
La base de datos relacional opera la base de datos a través de un lenguaje de consulta estructurado (que es lo que solemos llamar SQL). SQL admite operaciones CURD de bases de datos, que son muy potentes y de uso estándar en la industria. Las consultas Nosql operan datos en bloques y utilizan un lenguaje de consulta no estructurado (UnQl), que no tiene ningún estándar. El concepto de clave primaria en una tabla de base de datos relacional corresponde al ID de un documento almacenado en Nosql. Las bases de datos relacionales utilizan métodos de optimización predefinidos (como índices) para acelerar las operaciones de consulta, mientras que NoSQL tiene un modo de acceso a datos más simple y preciso. 6. Transacciones
Las bases de datos relacionales siguen reglas ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad), mientras que las bases de datos Nosql siguen principios BASE (Básico Disponible (Básicamente Disponible), transacciones suaves/flexibles (Estado Suave), transacciones eventuales consistencia (Consistencia Eventual)). Debido a la fuerte coherencia de los datos de las bases de datos relacionales, el soporte de transacciones es muy bueno. Las bases de datos relacionales admiten un control detallado sobre la atomicidad de las transacciones y una fácil reversión de las mismas. La base de datos Nosql elige dos de los CAP (Consistencia, Disponibilidad, Tolerancia de partición). Debido a que es difícil satisfacerlos todos en un sistema distribuido basado en nodos, el soporte para transacciones no es muy bueno, aunque también se pueden usar transacciones. , pero no es el punto brillante de Nosql. 7. Rendimiento
Las bases de datos relacionales pagan un precio enorme para mantener la coherencia de los datos y su rendimiento de lectura y escritura es relativamente pobre. El rendimiento es muy pobre frente a una alta lectura y escritura simultáneas, y la eficiencia es muy baja cuando se enfrenta a datos masivos. El formato de almacenamiento Nosql es del tipo clave-valor y se almacena en la memoria, lo cual es muy fácil de almacenar y tiene requisitos débiles para la coherencia de los datos. Nosql no requiere análisis de SQL y mejora el rendimiento de lectura y escritura. 8. Método de autorización
La mayoría de las bases de datos relacionales son pagas y costosas (MySQL es de código abierto, por lo que tiene la mayoría de los escenarios de aplicación), mientras que las bases de datos Nosql suelen ser de código abierto.
Por lo tanto, en entornos de aplicaciones reales, generalmente usamos MySQL para almacenar datos en nuestros procesos comerciales. Debido a que la relación entre estos datos es relativamente compleja, a menudo necesitamos consultar los datos de una tabla. de otras tablas relacionales, por ejemplo, consultar el pedido de un usuario requiere al menos datos de la tabla de usuarios y de la tabla de pedidos.
Para consultar los datos de ventas de un determinado producto, es posible que necesite una tabla de usuarios, una tabla de pedidos, una tabla de detalles de pedidos, una tabla de productos, etc.
En tal escenario de uso, si usamos Redis para almacenar, es decir, si lo almacenamos en forma de KeyValue, en realidad no satisface nuestras necesidades.
Incluso si la eficiencia de lectura de Redis es alta, no podemos usarlo.
Sin embargo, para algunas cosas que tienen poca correlación y requieren lectura y escritura de alta frecuencia, podemos usar Redis para mejorar en gran medida las capacidades de concurrencia de todo el sistema.
Por ejemplo, para la información de inventario de productos, aunque tenemos dichos campos en MySQL, no queremos que la base de datos MySQL se lea y escriba con frecuencia, porque usar esto hará que mi tabla de productos o mi tabla de inventario se conviertan en IO. es muy alto, afectando así la eficiencia de todo el sistema.
Por lo tanto, para dichos datos, y si hay alguna relación lógica compleja (solo pertenece a SKU), podemos ponerlos en Redis, realizar un pedido y reducir directamente el inventario en Redis, entonces, el La capacidad de concurrencia de nuestros pedidos se puede mejorar. Personalmente, creo que debería levantarme y corregirlo. Por el contrario, la cantidad de datos es grande y no debería usarse redis.
¿Por qué?
Dado que redis es una base de datos en memoria, se almacena en la memoria.
Imagínese que si su computadora usa redis para almacenar 100 G de datos, ¡entonces necesita más de 100 G de memoria! Escenarios de uso
Uno de los casos de uso más obvios de Redis es usarlo como caché. Simplemente guarde los datos activos o tenga un caché caducado.
Por ejemplo, Facebook utiliza Memcached como caché de sesión.
En resumen, nunca he visto a ninguna empresa grande con una gran cantidad de datos reemplazar MySQL por Redis.
Estás equivocado, no estás usando redis para reemplazar MySQL, sino introduciendo redis para optimización.
Cada vez más equipos de proyecto en BAT han adoptado la arquitectura redis MySQL para desarrollar herramientas de plataforma.
Como dijo el interrogador, cuando hay muchos datos, la eficiencia de las consultas de MySQL se reducirá considerablemente. Por lo general, utilizamos de forma predeterminada milisegundos si el campo consultado contiene un índice. Pero en el trabajo real, una vez encontré una tabla que contenía 10 campos y 18 millones de datos. Cuando, en un determinado escenario, teníamos que realizar una consulta precisa basada en un campo no indexado, una sola declaración SQL El tiempo de ejecución a veces puede alcanzar más. de 2 minutos, sin mencionar lo ineficiente que será si se utiliza una consulta difusa como like.
Inicialmente esperábamos resolver el problema agregando índices, pero frente a decenas de millones de datos, no nos atrevimos a agregar índices precipitadamente, porque una vez que la base de datos se bloquea , todas las solicitudes de escritura de la base de datos durante el período se colocarán en la cola de espera, si la solicitud se realiza a través de /i6543810796214813187/)
La lectura y la escritura son extremadamente rápidas
Redis es muy rápido y Se puede ejecutar por segundo. Velocidad de lectura y escritura de aproximadamente 100.000 veces. Tipos de datos enriquecidos
Redis admite tipos de datos enriquecidos, incluidas cadenas binarias, listas, conjuntos, conjuntos ordenados, hashes, etc.
Esto facilita el uso de Redis para resolver varios problemas, porque sabemos qué problemas se pueden resolver mejor usando qué tipos de datos. Atomicidad
Todas las operaciones de Redis son operaciones atómicas, lo que garantiza que si dos clientes acceden simultáneamente, el servidor de Redis pueda recibir valores actualizados. Herramientas ricas y prácticas que admiten la replicación maestro-esclavo entre máquinas
Redis admite la configuración de replicación maestro-esclavo, que puede lograr una copia completa del servidor maestro.
Las anteriores son las principales ventajas por las que los desarrolladores prefieren Redis. Sin embargo, tenga en cuenta que en entornos de producción reales, las empresas combinan Redis y MySQL para tomar decisiones específicas para diferentes escenarios de aplicación. Como el almacenamiento en caché: datos activos, contadores, colas de mensajes (similares a ActiveMQ, RocketMQ y otras herramientas), operaciones de bits (procesamiento de big data), bloqueos distribuidos y mecanismos de un solo subproceso, listas más recientes (como la lista de noticias más recientes). página de lista) y puede ver a Redis mostrando sus talentos en clasificaciones, etc. Sin embargo, para una precisión de datos rigurosa y aplicaciones relacionales complejas, las bases de datos relacionales como MySQL siguen siendo irremplazables.
MySQL Redis se usa generalmente en aplicaciones web. La aplicación web accede primero a Redis cada vez que no se encuentran datos. Diferencias esenciales
1. mysql: los datos se colocan en el disco redis: los datos se colocan en la memoria.
En primer lugar, debe saber que mysql se almacena en el disco y redis se almacena en la memoria. Redis se puede utilizar tanto para almacenamiento persistente como para almacenamiento en caché. En la actualidad, la mayoría de las empresas utilizan mysql redis. almacenamiento, y mysql se usa como almacenamiento primario, redis se usa como almacenamiento auxiliar como caché para acelerar el acceso y la lectura y mejorar el rendimiento. Diferencias en los escenarios de uso
1. Mysql admite consultas SQL, que pueden realizar algunas consultas y estadísticas relacionadas.
2. Redis tiene requisitos de memoria relativamente altos y no puede limitar todos los datos; condiciones Todos los datos se colocan en redis;
3. Mysql prefiere almacenar datos y redis prefiere recuperar datos rápidamente. Sin embargo, redis no es tan bueno como mysql para consultar relaciones de tablas complejas. Puede poner datos populares en redis y mysql. Datos básicos. El mecanismo operativo de mysql
Como base de datos relacional con almacenamiento persistente, la debilidad relativa de mysql es que cada vez que se realiza una solicitud para acceder a la base de datos, hay operaciones de E/S si se accede a la base de datos. repetida y frecuentemente. Primero: tomará mucho tiempo conectarse repetidamente a la base de datos, lo que resultará en una eficiencia operativa demasiado lenta. Segundo: el acceso repetido a la base de datos también hará que la carga de la base de datos sea demasiado alta, por lo que en este momento se deriva el concepto de almacenamiento en caché; . Persistencia de Redis
Dado que los datos de Redis se almacenan en la memoria, si no se configura la persistencia, todos los datos se perderán después de que se reinicie Redis. Por lo tanto, debe habilitar la función de persistencia de Redis para guardar los datos en el disco. , cuando redis se reinicia, los datos se pueden restaurar desde el disco. Redis proporciona dos métodos de persistencia, uno es la persistencia RDB (el principio es volcar periódicamente los registros de la base de datos de Reids en la memoria a la persistencia RDB en el disco) y el otro es la persistencia AOF (solo agregar archivos) (el principio es escribir la operación de Reids). iniciar sesión en el archivo de forma adjunta).
¡redis se almacena en la memoria ~!
La cantidad de datos definitivamente no es el criterio para elegir redis y mysql, porque tanto mysql como redis se pueden agrupar y expandir. La única restricción para ellos es el hardware (es decir, si tienes tanto dinero). para construir miles de clústeres), personalmente creo que la velocidad de lectura de datos puede ser uno de los criterios de selección. Además, ambos se usan a menudo en el trabajo, porque mysql se almacena en el disco duro para almacenamiento persistente, mientras que redis. se almacena en la memoria para el almacenamiento en caché para mejorar la eficiencia.
Una base de datos relacional es esencial, porque sólo una base de datos relacional puede proporcionarle una variedad de métodos de consulta. Si hay una serie de datos que se consultarán con frecuencia, entonces usar redis para almacenamiento no persistente para uso de consultas es una de las formas de resolver los problemas de rendimiento de concurrencia.