Cuando la cantidad de datos es grande, ¿por qué usar Redis en lugar de MySQL?
En términos generales, cuando la cantidad de datos es grande y la concurrencia es alta, 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 no es así. No significa que si usas Redis, no tengas que usar MySQL.
Debido a que el rendimiento de Redis es muy superior, puede admitir cientos de miles de operaciones de lectura/escritura por segundo, y Redis también admite persistencia, implementación de clústeres, distribución, sincronización maestro-esclavo, etc. En escenarios de alta concurrencia, la seguridad y coherencia de los datos de Redis son muy altas, por lo que generalmente se usa en los dos escenarios siguientes:
Almacenamiento en caché
Para determinar si los datos son adecuados en Redis Para el almacenamiento en caché, puede considerar los siguientes aspectos: ¿Lo consultará con frecuencia? ¿Cuál es la tasa de aciertos? ¿Cuál es el número de escrituras? ¿Cuál es el tamaño de los datos?
A menudo utilizamos este método para descargar datos en Redis: llega la solicitud de consulta y luego consulta en Redis. Si la consulta no tiene éxito, consulta la base de datos para obtener los datos. luego se coloca en el caché, de modo que cuando llegue la misma solicitud de consulta por segunda vez, los datos se puedan obtener directamente de Redis; sin embargo, debemos prestar atención al problema de penetración del caché;
La actualización de la caché puede ser más complicada. Por lo general, después de modificar la base de datos, también debe operar con los datos en Redis. El código es muy simple, pero debe asegurarse de que estos dos pasos sean la misma transacción; , o la coherencia final de la transacción.
Lectura y escritura a alta velocidad
Normalmente, se trata de un contador, por ejemplo, el número de veces que se ha leído un artículo, y es imposible actualizarlo en la base de datos. cada vez que se lee.
Los escenarios de alta concurrencia son muy adecuados para el uso de Redis, como la venta flash Double 11. Si hace un inventario, hay miles de artículos durante la venta flash y generalmente hay decenas de miles de solicitudes. en un período de tiempo muy corto Al llegar al servidor, si se usa una base de datos, es probable que la base de datos falle en un instante, por lo que generalmente se usa Redis (el escenario de venta flash será más complicado, y Redis lo es). solo uno de ellos), pero leer y escribir con la base de datos también es muy problemático. Por ejemplo, si la solicitud excede un cierto número de veces, el exceso de solicitudes se limitará), Redis es solo uno de ellos.
Este escenario de alta concurrencia significa que una vez que la solicitud llega al servidor, se lee y escribe directamente en Redis y la solicitud no accede a la base de datos, el programa escribirá datos en lotes en la base de datos; el momento apropiado, por ejemplo, si miles de artículos en stock se agotaron instantáneamente.
Por lo tanto, en general, la introducción de Redis puede reducir la presión sobre las bases de datos MySQL (u otras) cuando sea necesario; las dos no se reemplazan entre sí;
Continuaré compartiendo ideas sobre el desarrollo de Java, el diseño arquitectónico y el desarrollo profesional como programador.
Redis y MySQL se utilizan en diferentes escenarios de aplicación.
En términos generales, no hay forma de usar Redis sin usar MySQL.
Esto se debe a que Redis es una base de datos no relacional (NoSQL), mientras que MySQL es una base de datos relacional.
Las bases de datos similares a Redis incluyen MongoDB y Memchache (de hecho, no hay datos persistentes)
Es decir, las bases de datos relacionales actualmente, las bases de datos relacionales de uso común incluyen MySQL, SQL Server,. Oráculo.
Primero comprendamos la diferencia entre bases de datos relacionales y bases de datos no relacionales. 1. Almacenamiento
Las bases de datos relacionales son tabulares, por lo que se almacenan en filas y columnas de tablas. Les resulta fácil asociarse y colaborar entre sí para el almacenamiento, y también es fácil extraer datos. Por el contrario, la base de datos Nosql es una combinación de bloques grandes. Normalmente 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. La tabla de datos tiene una estructura predefinida (definición de columna) para describir la forma y el contenido de los datos. Esto es crucial para el modelado de datos.
Si bien las estructuras predefinidas aportan confiabilidad y estabilidad, modificar estos datos es difícil. Mientras que la base de datos Nosql se basa en estructuras dinámicas y puede usarse para datos no estructurados. Dado que las bases de datos Nosql están estructuradas dinámicamente, se adaptan fácilmente a los cambios en los tipos y estructuras de datos. 3. Especificaciones de almacenamiento
El almacenamiento de datos de bases de datos relacionales está altamente estandarizado y los datos se dividen en las tablas relacionales más pequeñas para evitar la duplicación y obtener una utilización optimizada del espacio. Aunque la gestión es clara, diseñar varias tablas en una sola operación hace que la gestión de datos sea un poco engorrosa. Si bien los datos Nosql se almacenan en conjuntos de datos planos, es posible que los datos se repitan con frecuencia. Una única base de datos rara vez se divide, sino que se almacena como un todo, por lo que todos los datos son más fáciles de leer y escribir. 4. Expansión del almacenamiento
Esta es probablemente la mayor diferencia entre las dos, las bases de datos relacionales son escalable verticalmente, lo que significa que desea aumentar la potencia de procesamiento y utilizar una computadora más rápida. Dado que los datos se almacenan en tablas relacionales, el cuello de botella en el rendimiento de la operación puede implicar más de una tabla, lo que debe superarse mejorando el rendimiento de la computadora. Aunque hay mucho espacio para la expansión, eventualmente 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. Consulta
Las bases de datos relacionales operan sobre la base de datos a través de un lenguaje de consulta estructurado (que normalmente llamamos SQL). El soporte de SQL para operaciones CURD de bases de datos es muy poderoso y es un uso estándar en la industria. Las consultas Nosql, por otro lado, operan sobre bloques de datos utilizando un lenguaje de consulta no estructurado (UnQl), que aún no ha sido estandarizado. 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 optimizaciones predefinidas (como índices) para acelerar las operaciones de consulta, mientras que Nosql es un modelo 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ásicamente disponibles), transacciones suaves/flexibles (soft). Transacciones blandas/flexibles (estado blando), coherencia eventual)). Las bases de datos relacionales tienen una gran coherencia en los datos y, por lo tanto, admiten bien las transacciones. Las bases de datos relacionales admiten un control detallado sobre la atomicidad de las transacciones y la facilidad para revertir las transacciones. La base de datos Nosql elige dos de los CAP (Consistencia, Disponibilidad, Tolerancia de partición). Dado que es un sistema distribuido basado en nodos, es difícil satisfacerlos todos, por lo que el soporte para transacciones no es muy bueno. ser utilizado, 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 de lectura y escritura es muy pobre cuando se enfrenta a una alta concurrencia y la eficiencia es muy baja cuando se enfrenta a datos masivos. El formato de almacenamiento de Nosql es todo tipo clave-valor y se almacena en la memoria, lo cual es muy fácil de almacenar y tiene requisitos muy débiles para la coherencia de los datos. Nosql no requiere análisis de SQL y puede mejorar el rendimiento de lectura y escritura. 8. Autorización
La mayoría de las bases de datos relacionales son pagas, costosas 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 los datos de nuestros procesos comerciales. Dado que la relación entre estos datos es relativamente compleja, a menudo necesitamos consultar los datos en una tabla y consultar otras relaciones. Los datos de la tabla, por ejemplo, para consultar el pedido de un usuario, requieren al menos datos de la tabla de usuarios y de la tabla de pedidos.
Para consultar los datos de ventas de un 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 este caso, usar Redis para almacenar datos en forma de KeyValue no es suficiente.
Aunque Redis es muy eficiente en lectura, no podemos usarlo.
Sin embargo, para algunos objetos no relacionados que requieren lectura y escritura frecuentes, podemos usar Redis para mejorar la concurrencia de todo el sistema.
Por ejemplo, para la información del inventario de productos, aunque tenemos dicho campo en MySQL, no queremos que la base de datos MySQL se lea y escriba con frecuencia, porque hacerlo provocará la IO de la tabla de productos o La tabla de inventario es muy alta, afectando así la eficiencia de todo el sistema.
Por lo tanto, para este tipo de datos, y datos que no tienen relaciones lógicas complejas (solo pertenecen a SKU), podemos poner el pedido en Redis y reducir el inventario directamente en Redis, para que la concurrencia de nuestros pedidos se podrán mejorar. Personalmente, creo que deberíamos estar en el lado correcto. Por el contrario, no debería colocarse una gran cantidad de datos en Redis.
¿Por qué?
Porque redis es una base de datos en memoria.
Imagínese si tiene 100 G de datos en su computadora, todos almacenados en Redis, ¡entonces necesitará 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é.
Por ejemplo, Facebook utiliza Memcached como caché de sesión.
En resumen, no he visto a ninguna gran empresa abandonar MySQL en favor de Redis cuando tiene muchos datos.
El interrogador está equivocado. Esto no reemplaza MySQL con redis, sino que introduce redis para la optimización.
En BAT, cada vez más equipos de proyecto adoptan la arquitectura redis+MySQL para desarrollar herramientas de plataforma.
Como indica el título, cuando la cantidad de datos es grande, la eficiencia de las consultas de MySQL se reducirá considerablemente. Si el campo consultado contiene un índice, normalmente devolvemos milisegundos de forma predeterminada. Pero en la operación real, el autor encontró una vez una tabla que contiene 10 campos y más de 18 millones de datos. Cuando ocurre un determinado escenario, tenemos que realizar consultas precisas basadas en un campo no indexado. El tiempo de ejecución de una sola declaración SQL a veces puede llevar más. de 2 minutos, sin mencionar cuán baja será la eficiencia si utiliza métodos como consultas difusas.
Al principio, esperábamos resolver este problema agregando índices, pero ante 10 millones de niveles de datos, no nos atrevimos a agregar índices fácilmente, porque una vez que la base de datos se bloquea, durante Si todas las solicitudes de escritura de la base de datos pasan por /i6543810796214813187/ )
Lectura y escritura extraordinariamente rápidas
Redis es muy rápido y puede realizar alrededor de 100.000 lecturas y escrituras por segundo. Tipos de datos enriquecidos
Redis admite tipos de datos enriquecidos, incluidas cadenas binarias, listas, conjuntos, conjuntos ordenados, valores hash, etc. Esto hace que Redis sea fácil de usar para resolver problemas porque sabemos qué problemas se resuelven mejor con qué tipos de datos. Atomicidad
Todas las operaciones en Redis son atómicas, lo que garantiza que cuando dos clientes acceden a Redis al mismo tiempo, el servidor de Redis recibe valores actualizados. Utilidades enriquecidas que admiten replicación maestro-esclavo heterogénea
Redis admite configuraciones de replicación maestro-esclavo, lo que permite una replicación precisa del servidor maestro.
Estas son algunas de las principales ventajas por las que los desarrolladores prefieren Redis. Sin embargo, tenga en cuenta que en entornos de producción reales, las empresas combinarán las características específicas de Redis y MySQL para hacer concesiones 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), bloqueo distribuido y mecanismos de un solo subproceso, listas más recientes (como la lista de noticias más recientes). página de lista) y clasificaciones, etc. pueden mostrar la efectividad de Redis. Escenarios de aplicación. Pero para una estricta precisión de los datos y aplicaciones relacionales complejas, MySQL y otras bases de datos relacionales siguen siendo insustituibles.
Las aplicaciones web generalmente usan MySQL + Redis, es decir, la aplicación web primero accede a Redis cada vez y luego accede a MySQL si no se pueden encontrar los datos. Diferencias esenciales
1. Mysql: los datos están en el disco, Redis: los datos están en la memoria.
Lo primero que debemos saber es que mysql se almacena en el disco, mientras que redis se almacena en la memoria. Redis se puede utilizar para almacenamiento persistente y almacenamiento en caché. Actualmente, la mayoría de las empresas almacenan mysql + redis, donde mysql sirve como almacenamiento principal y redis sirve como almacenamiento secundario y se utiliza como caché para acelerar el acceso de lectura y mejorar el rendimiento. Diferencias en escenarios de uso
1. Mysql admite consultas SQL y puede implementar algunas consultas y estadísticas relacionadas.
2. Redis tiene altos requisitos de memoria y no se puede usar en condiciones limitadas. datos en redis;
3. Mysql se centra en almacenar datos, mientras que redis se centra en obtener datos rápidamente. Redis se enfoca en obtener datos rápidamente, pero su capacidad para consultar relaciones de tablas complejas no es tan buena como mysql, por lo que puede colocar datos de uso común en redis y mysql almacena datos básicos. Mecanismo operativo 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, habrá operaciones de E/S si se accede a la base de datos repetidamente. y frecuentemente. En primer lugar: pasará mucho tiempo vinculándose repetidamente a la base de datos, lo que dará como resultado una eficiencia operativa más lenta. En segundo lugar: 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 el concepto de almacenamiento en caché se deriva de esto; tiempo. 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, es necesario habilitar la persistencia de Redis para guardar los datos en el disco y luego después. redis se reinicia Recuperar datos en 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 Reids en la memoria a la persistencia RDB del disco) y el otro es la persistencia AOF (archivo de solo agregar) (el principio es escribir la operación Reids inicie sesión en el archivo en forma de anexo).
¡redis está ubicado 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, y su limitación está solo en el hardware (es decir, no tienes Con esa cantidad de dinero para construir un servidor con miles de (un clúster compuesto por personas), personalmente creo que la velocidad de lectura de datos puede ser uno de los criterios de selección. Los otros dos métodos de trabajo suelen ser los mismos, porque mysql se almacena. en el disco duro para almacenamiento persistente, mientras que redis se almacena en la memoria, realice 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 amplia variedad de consultas. Si hay una serie de datos que se consultarán con frecuencia, entonces usar redis para el almacenamiento no persistente para consultas es una de las formas de resolver el problema de rendimiento de concurrencia.