Resumen del trabajo que ha realizado redis para ahorrar memoria.
Los datos de prueba utilizados son específicos y pueden no funcionar bien con datos más pequeños o más grandes.
Los resultados de las pruebas no aparecen en la lista, así que veamos directamente las conclusiones.
La peor forma de almacenar entidades (es decir, registros) es utilizar hashes. Es entre 1 y 2 veces más lento y ocupa más espacio que otras opciones.
Además, el tipo de campo es cadena y usted mismo debe convertir el tipo.
La única ventaja es que puedes manipular un campo individualmente.
Tampoco es aconsejable utilizar el tipo string para almacenamiento, aunque es ligeramente mejor que el método anterior. La desventaja de que las claves ocupen más memoria queda expuesta cuando las entidades individuales son más pequeñas.
Almacenar todas las entidades de un tipo (es decir, una tabla) en un hash es más sencillo de implementar y ocupa menos memoria.
Usar multihash para almacenar todas las entidades de un tipo (es decir, en tablas separadas) es un poco más complejo de implementar, pero tiene un uso mínimo de memoria.
Si los valores de los campos individuales son pequeños (64 bytes por defecto) y el número de campos almacenados en un único hash es pequeño (512 por defecto), se utilizará un mapa zip hash, lo que reduce significativamente uso de memoria.
El número recomendado de campos almacenados en un único hash es una potencia de 2, como por ejemplo 1024. Un poco más que esto dará como resultado un mayor uso de memoria y latencia.
Los ingenieros de Instagram creen que el número óptimo de campos para utilizar un mapa zip hash es de alrededor de 1000. Sin embargo, en mis pruebas, la velocidad básicamente disminuyó a medida que aumentaba el número de campos, y el cambio en la huella de memoria de 128 a 1024 fue esencialmente insignificante.
Almacenar en formato JSON es una buena opción. Para contenido que contenga chino, configurar sure_ascii=False puede ahorrar mucha memoria.
El rendimiento de ujson es mucho mejor que el de json, que tiene una caída drástica en el rendimiento después de configurar sure_ascii=False.
cPickle no tiene tanto rendimiento como json, pero admite más tipos (como datetime).
MessagePack tiene una ligera ventaja de rendimiento sobre ujson, pero pierde legibilidad y requiere su propia decodificación para recuperar Unicode.
La afirmación de que es 4 veces más rápido que Protocol Buffer es insignificante, al menos su biblioteca Python no tiene ninguna ventaja obvia.
El uso de la compresión zlib ahorra más memoria pero reduce el rendimiento en un factor de 1 a 2.
A juzgar por los resultados de esta prueba, creo que no es tan económico como usar MongoDB. ......