ZODB dans la vraie vie

Question

J'écris une application en Python, et j'ai joué avec diverses configurations ORM et SQL direct. Toutes ces solutions sont laides comme le péché.

Je me suis penché sur ZODB en tant que magasin d'objets, et cela semble être une alternative prometteuse... Le recommanderiez-vous ? Quelles sont vos expériences, problèmes et critiques, en particulier en ce qui concerne les perspectives des développeurs, l'évolutivité, l'intégrité, la maintenance à long terme et les alternatives ? Quelqu'un a commencé un projet avec cette solution et l'a abandonnée ? Pourquoi ?

Bien que les idées qui sous-tendent ZODB, Pypersyst et d'autres soient intéressantes, il semble qu'il y ait un manque d'enthousiasme à leur égard.

Answer 1

J'utilise ZODB depuis plus de dix ans maintenant, dans Zope et en dehors. C'est génial si vos données sont hiérarchiques. Le plus grand magasin de données qu'un client exploite a peut-être. Je ne sais pas, 100GB dedans ? Quelque chose de cet ordre de grandeur en tout cas.

Voici une comparaison des performances avec Postgres .

Si vous écrivez une application web WSGI, ces paquets peuvent vous être utiles :

• repoze.tm2 ( docs )

• repoze.zodbconn ( docs )

Answer 2

Par rapport à "n'importe quel magasin clé-valeur", les caractéristiques clés de la ZODB seraient l'intégration automatique des changements d'attributs avec de véritables transactions ACID, et des références propres et "arbitraires" à d'autres objets persistants.

La ZODB est plus grande que le simple FileStorage utilisé par défaut dans Zope :

• Le backend RelStorage vous permet de placer vos données dans un SGBDR qui peut être sauvegardé, répliqué, etc. à l'aide d'outils standard.
• ZEO permet une mise à l'échelle facile des appservers et des travaux hors ligne.
• La prise en charge de la validation en deux phases permet de coordonner les transactions entre plusieurs bases de données, y compris les SGBDR (à condition qu'ils fournissent une couche tenant compte de TPC).
• Hiérarchie facile basée sur les attributs des objets ou le confinement : il n'est pas nécessaire d'écrire des auto-joints récursifs pour l'émuler.
• La prise en charge des BLOB par le système de fichiers permet de servir des fichiers volumineux en toute simplicité.

Dans l'ensemble, je suis très heureux d'utiliser ZODB pour presque tous les problèmes où la forme des données n'est pas manifestement "carrée".

Answer 3

Je le recommande.

Je n'ai pas vraiment de critiques à formuler. Si c'est un magasin d'objets que vous recherchez, c'est celui-là qu'il faut utiliser. J'ai déjà stocké 2,5 millions d'objets dedans et je n'ai pas ressenti le moindre pincement.

Answer 4

ZODB a été utilisé pour de nombreuses grandes bases de données.

La plupart des utilisateurs de ZODB sont/étaient probablement des utilisateurs de Zope qui ont migré s'ils ont migré de Zope.

Les performances ne sont pas aussi bonnes que celles de la base de données relationnelle+ORM, surtout si vous avez beaucoup d'écritures.

La maintenance à long terme n'est pas si mauvaise, vous devez emballer la base de données de temps en temps, mais cela peut être fait en direct.

Vous devez utiliser ZEO si vous voulez utiliser plus d'un processus avec votre ZODB, ce qui est beaucoup plus lent que d'utiliser ZODB directement.

Je n'ai aucune idée des performances de ZODB sur les disques flash.

Answer 5

Avec le saumurage, vous devriez pouvoir utiliser n'importe quel valeur de la clé de manière similaire.