sql - usar - redis ventajas y desventajas
Escalabilidad del uso de MySQL como base de datos clave/valor (4)
No hay duda de que usar una solución NOSQL será más rápido, ya que es más simple.
NOSQL y Relational no compiten entre sí, son diferentes herramientas que pueden resolver diferentes problemas.
Dicho esto para 1000 escrituras / día o por hora, MySQL no tendrá ningún problema.
Por 1000 por segundo necesitarás un hardware elegante para llegar allí. Para la solución NOSQL probablemente aún necesitará algún sistema de archivos distribuidos.
También depende de lo que está almacenando.
Estoy interesado en conocer los impactos en el rendimiento del uso de MySQL como una base de datos clave-valor frente a decir Redis / MongoDB / CouchDB. He utilizado tanto Redis como CouchDB en el pasado, así que estoy muy familiarizado con sus casos de uso, y sé que es mejor almacenar los pares clave / valor en decir NoSQL vs. MySQL.
Pero esta es la situación:
- la mayoría de nuestras aplicaciones ya tienen muchas tablas MySQL
- Alojamos todo en Heroku (que solo tiene MongoDB y MySQL, y básicamente es de tipo 1-db por aplicación)
- no queremos utilizar múltiples bases de datos diferentes en este caso.
Entonces, básicamente, estoy buscando información sobre la escalabilidad de tener una tabla de clave / valor en MySQL. Tal vez en tres diferentes niveles arbitrarios:
- 1000 escribe por día
- 1000 escrituras por hora
- 1000 escrituras por segundo
- 1000 lecturas por hora
- 1000 lecturas por segundo
Un ejemplo práctico es construir algo así como el rastreador de análisis web en tiempo real de MixPanel , que requeriría escribir muy a menudo dependiendo del tráfico.
Wordpress y otros programas populares usan esto todo el tiempo: Publicar tiene un modelo "Meta" que es solo clave / valor, por lo que puede agregar propiedades arbitrarias a un objeto que puede ser buscado.
Otra opción es almacenar un hash serializable en un blob, pero eso parece peor.
¿Cuál es tu opinión?
Diría que tendrá que ejecutar su propio punto de referencia porque solo usted conoce los siguientes aspectos importantes:
- el tamaño de los datos que se almacenarán en esta tabla de KV
- el nivel de paralelismo que desea alcanzar
- la cantidad de consultas existentes que llegan a su instancia de MySQL
También diría que, dependiendo de los requisitos de durabilidad para estos datos, también querrás probar varios motores: InnoDB, MyISAM.
Si bien espero que algunas soluciones NoSQL sean más rápidas, en función de sus limitaciones, puede descubrir que MySQL funcionará lo suficientemente bien para sus requisitos.
SQL datos SQL se usan cada vez más como capa de persistencia, con los cálculos y la entrega almacenados en caché en repositorios de Key-Value .
Con esto en mente, esos tipos han hecho una gran prueba aquí:
- InnoDB inserta 43,000 registros por segundo AT ITS PEAK *;
- TokuDB inserta 34,000 registros por segundo AT ITS PEAK *;
- Este KV inserta 100 millones de registros por segundo (más de 2,000 veces).
Para responder a su pregunta, es más que probable que un repositorio de Key-Value supere a MySQL en varios órdenes de magnitud:
Procesamiento de 100,000,000 artículos:
kv_add()....time:....978.32 ms
kv_get().....time:....297.07 ms
kv_free()....time:........0.00 ms
De acuerdo, tu prueba fue de 1,000 ops por segundo, ¡pero no puede hacerte daño para poder hacer 1,000 veces más!
Vea esto para más detalles (también lo comparan con el Tokyo Cabinet ).
Eche un vistazo a la serie de entradas de blog aquí donde el autor ejecuta pruebas que comparan el rendimiento de MongoDB y MySQL, y combate el desorden de ajuste del rendimiento de MySQL. MongoDB estaba haciendo ~ 100K lecturas por fila por segundo, MySQL en el modo c / s estaba haciendo 43K máx., Pero con la biblioteca integrada logró subir a 172K lecturas por fila por segundo.
Suena un poco complicado llegar tan alto en un solo nodo, entonces ymmv.
La segunda pregunta es un poco más difícil, pero esto aún puede darte algunas ideas sobre las configuraciones para probar.