2016-11-11 7 views
2

J'utilisais Zodb pour le stockage de données volumineuses sous la forme d'un format de dictionnaire typique (clé, valeur). Mais tout en stockant dans ZODB je suis arrivé message d'avertissement:ZODB ou autre base de données pour le stockage de données volumineuses en python

C: \ python-3.5.2.amd64 \ lib \ site-packages \ ZODB \ Connexion. py: 550: UserWarning: L'objet que vous enregistrez est volumineux. (510241658 octets.)

Peut-être que vous stockez des médias qui devraient être stockés dans des blobs. Peut-être que vous utilisez une structure de données non-scalable, telle que PersistentMapping ou PersistentList.

Peut-être que vous stockez des données dans des objets qui ne sont pas persistants du tout. Dans ce cas, les données sont stockées dans l'enregistrement de l'objet persistant contenant .

Dans tous les cas, stocker des enregistrements de cette taille est probablement une mauvaise idée.

Si vous insistez et que vous voulez vous débarrasser de cet avertissement, utilisez pour spécifier une taille plus l'option de large_record_size du constructeur ZODB.DB (ou l'option grand enregistrement de taille dans un fichier de configuration).

warnings.warn (large_object_message% (obj. classe, len (p)))

s'il vous plaît indiquer comment puis-je stocker des données volumineuses dans ZODB ou suggèrent toute autre bibliothèque à cet effet

Répondre

1

Utilisez le support BLOB natif dans ZODB pour stocker des données volumineuses; Tout le reste est un anti-pattern sauf si vous avez besoin d'un type de stockage cloud qui ne peut pas être pris en charge sur un système de fichiers local.

Vous n'avez pas dit ce que vous stockez ou à quoi ressemble votre configuration de stockage, mais je pense que cela est invariant à la bonne approche: utilisez les BLOB. Comment ça marche: L'API blob stocke des objets en utilisant l'OID de l'objet Persistant wrapper (qui est généralement référencé comme un attribut de votre objet primaire persistant). L'OID (ID d'objet ZODB interne) de l'objet d'emballage est utilisé comme clé pour trouver les données BLOB, les récupérer, etc. à partir de votre stockage BLOB configuré.

Habituellement, il s'agit simplement d'un fichier sur le système de fichiers de votre application, mais peut également être stocké sur le système de fichiers de votre serveur de base de données (ZEO ou RDBMS derrière RelStorage, selon la configuration). Il est possible que certaines bases de données (par exemple PostgreSQL backend à RelStorage) puissent stocker des BLOB en utilisant leurs mécanismes de stockage BLOB natifs, que ZODB (via RelStorage) délivre.

Références:

  1. https://ziade.org/2007/09/14/to-blob-or-not-to-blob/

  2. https://stackoverflow.com/a/14645205/835961

  3. bibliothèques utiles:

    a. z3c.blobfile (sous licence ZPL)

    b. plone.namedfile (licence BSD)

+1

@WAS Je devrais mentionner, ce que vous faites maintenant est de stocker de très gros pickles qui doivent être chargés en une fois et ne peuvent pas être diffusés. Pour des choses comme les requêtes de plage HTTP (streaming progressif), c'est un bouchon de spectacle; Les personnes qui utilisent ZODB dans les grandes applications de production utilisent des BLOB puis transfèrent généralement les données du fichier vers un itérateur de stockage de fichiers qui fonctionne avec votre application web/réseau. Cela fonctionne très bien pour Zope 2, mais il y a aussi des approches que les applications pourraient utiliser pour utiliser des choses comme X-Sendfile directement à partir du serveur web frontal sans passer par l'application pour aller directement au BLOB. – sdupton

1

Vous devez stocker l'objet sur le système de fichiers et ajouter une référence à celui-ci dans le zodb comme si vous utilisiez une base de données régulière.

+0

pouvez-vous élaborer? – WAS

+0

Ceci est une réponse "presque". ZODB a une API BLOB, la bonne façon de référencer et de charger les données BLOB. L'utilisation d'autres types de "références" aux fichiers est probablement un anti-pattern. – sdupton