Comparando soluciones de almacenamiento persistentes en python

Question

Estoy comenzando un nuevo proyecto científico que tiene una gran cantidad de datos (millones de entradas) Me gustaría almacenar en un formato de fácil y rápido acceso. Me he encontrado con varias opciones posibles diferentes, pero no estoy seguro de cómo elegir entre ellas. Mis datos probablemente solo puedan almacenarse como un diccionario, o potencialmente un diccionario de diccionarios. Algunas consideraciones potenciales:

• Velocidad. No puedo cargar todos los datos del disco cada vez que comienzo un nuevo script, y me gustaría tener acceso rápido a entradas aleatorias como sea posible.
• Facilidad de uso. Esto es pitón. El almacenamiento debe sentirse como python.
• Estabilidad/madurez. Me gustaría algo que sea compatible actualmente, aunque algo que funciona bien pero aún está en desarrollo estaría bien.
• Facilidad de instalación. Mi administrador de sistemas debería poder ejecutar esto en nuestro clúster.

Realmente no me importa mucho sobre el tamaño del almacenamiento, pero podría ser una consideración si una opción es realmente terrible en este frente. Además, si es importante, lo más probable es que esté creando la base de datos una vez y, a partir de ahí, solo pueda leerla.

Algunas opciones posibles que he empezado a analizar (ver this post):

• pyTables
• ZopeDB
• shove
• shelve
• redis
• durus

¿Alguna sugerencia sobre cuál de estos podría ser mejor para mis propósitos? Alguna mejor idea? Algunos de estos tienen un back-end; ¿Alguna sugerencia sobre qué back-end de sistema de archivos sería mejor?

Answer 1

A RDBMS.

Nada es más realiable que usar tablas en un RDBMS bien conocido. Postgresql viene a la mente.

Eso automáticamente le da algunas opciones para el futuro como la agrupación en clúster. Además, tiene automáticamente muchas herramientas para administrar su base de datos, y puede usarla desde otro software escrito en prácticamente cualquier idioma.

Es realmente rápido.

En el punto "feel like python", podría agregar que puede usar un ORM. Un nombre seguro es sqlalchemy. Tal vez con la extensión elixir "".

Usando sqlalchemy puede dejar que su usuario/sysadmin elija la base de datos que desea usar. Tal vez ya tengan instalado MySql, no hay problema.

Los RDBMS siguen siendo la mejor opción para el almacenamiento de datos.

Answer 2

SQLite - viene con Python, rápido, ampliamente dotados y fácil de mantener

Answer 3

Si sólo necesita (como dict) simples mecanismos de acceso y la necesidad de eficiencia para procesar una gran cantidad de datos, entonces podría haber un HDF5 buena opción. Si va a usar numpy, entonces realmente vale la pena considerarlo.

Answer 4

Ir con un RDBMS es confiable, escalable y rápido.

Si necesita una solución más scalabre y no necesita las características de RDBMS, puede ir con una tienda de clave-valor como couchdb que tiene una buena API de Python.

Answer 5

Puede que desee dar una oportunidad a mongodb - la biblioteca PyMongo funciona con diccionarios y es compatible con la mayoría de los tipos de Python. Fácil de instalar, muy eficiente + escalable. MongoDB (y PyMongo) también se usa in production en algunos nombres importantes.

Answer 6

Estoy trabajando en un proyecto así y estoy usando SQLite.

SQLite almacena todo en un archivo y es parte de Python's standard library. Por lo tanto, la instalación y la configuración son prácticamente gratuitas (facilidad de instalación).

Puede gestionar fácilmente el archivo de base de datos con pequeños scripts de Python o mediante diversas herramientas. También hay un Firefox plugin (facilidad de instalación/facilidad de uso).

Me resulta muy conveniente utilizar SQL para filtrar/ordenar/manipular/... los datos. Aunque, no soy un experto SQL. (facilidad de uso)

No estoy seguro de si SQLite es el sistema de base de datos de ayuno para este trabajo y carece de algunas características que podría necesitar, p. procedimientos almacenados.

De todos modos, SQLite funciona para mí.

Answer 7

La colaboración NEMO (construir un detector cósmico de neutrinos bajo el agua) tuvo muchos de los mismos problemas, y usaron mysql y postgresql sin mayores problemas.

Answer 8

si realmente solo necesita almacenamiento tipo diccionario, algunas de las tiendas clave/de valor o columnas nuevas como Cassandra o MongoDB pueden proporcionar mucha más velocidad de la que obtendría con una base de datos relacional. Por supuesto, si decides ir con RDBMS, SQLAlchemy es el camino a seguir (descargo de responsabilidad: yo soy su creador), pero tu lista de características deseada parece inclinarse en la dirección de "Solo quiero un diccionario que se sienta como Python" - si no están interesados ​​en consultas relacionales o ACID fuerte, esas facetas de RDBMS probablemente se sientan incómodas.

Answer 9

Realmente depende de lo que estás tratando de hacer. Un RDBMS está diseñado para datos relacionales, por lo que si sus datos son relacionales, utilice una de las diversas opciones de SQL. Pero parece que sus datos están más orientados hacia una tienda de valores clave con operaciones GET aleatorias muy rápidas. Si ese es el caso, compare los puntos de referencia de los diferentes almacenes de claves, centrándose en la velocidad GET. El almacén de valores-clave ideal mantendrá o almacenará en caché las solicitudes en la memoria y podrá manejar muchas solicitudes GET al mismo tiempo. En realidad, puede querer crear su propio conjunto de parámetros para poder comparar eficazmente las operaciones concurrentes GET concurrentes.

¿Por qué necesita un clúster? ¿El tamaño de cada valor es muy grande? De lo contrario, no debería necesitar un clúster para manejar el almacenamiento de un millón de entradas. Pero si está almacenando grandes cantidades de datos, eso es importante, y es posible que necesite algo que sea fácil de admitir leer esclavos y/o particiones transparentes.Algunas de las tiendas de valores clave están orientadas al documento y/u optimizadas para almacenar valores más grandes. Redis es técnicamente más eficiente de almacenamiento para valores más grandes debido a la sobrecarga de indexación requerida para GET rápidos, pero eso no significa necesariamente que sea más lento. De hecho, la indexación adicional hace que las búsquedas sean más rápidas.

Usted es el único que realmente puede responder a esta pregunta, y recomiendo encarecidamente armar un conjunto de pruebas de referencia personalizado para probar las opciones disponibles con escenarios de uso reales. Los datos que obtienes de eso te darán más información que otra cosa.