J'ai lancé une application avec Hibernate 3.2 et PostgreSQL 8.4. J'ai des champs Maintenant, ces champs sont max 4 kb (mais la moyenne est de 2-3 Ko). La documentation PostgreSQL a indiqué que les LOS sont bonnes lorsque les champs sont grands, mais je n'ai pas vu ce que «gros» signifiait.
J'ai mis à niveau vers PostgreSQL 9.0 avec hibernate 3.6 et j'étais bloqué pour changer l'annotation vers Je pense donc à changer tout à Y a-t-il de bons repères sur la performance de ces deux?
Quelqu'un a fait le commutateur et a vu une différence? octet [] mappés comme @basic (= pg bytea) et d'autres qui ont été mappés comme @lob (= pg Gros objet). Pourquoi l'incohérence? Parce que j'étais un hibernate noob.
@Type (type = "org.hibernate.type.primbytearrayblobtype") . Ce bogue a présenté une question de compatibilité potentielle et j'ai finalement découvert que les gros objets sont une douleur à traiter, par rapport à un champ normal.
BYTEA . Mais je suis préoccupé par le fait que byTea est codé dans Hex, de sorte qu'il y a des frais généraux dans le codage et le décodage, et cela blesserait la performance.
4 Réponses :
mais je suis préoccupé par les champs de Bytea sont codés dans HEX
Entrée BYTEA peut être au format hexagonal ou échappatoire, c'est votre choix. Le stockage sera le même. À partir de la version 9.0, la valeur de sortie est hex, mais vous pouvez modifier ceci en modifiant le paramètre bytea_output .
Je n'ai vu aucun point de repère.
De plus, il n'est pas stocké comme hexagonal, et je pense que libpq (et peut-être même le protocole) a une interface pour les transferts binaires des deux.
Je n'ai pas de comparaison de gros objets et de ByTea Handy, mais notez que le commutateur sur le format de sortie hexagonal en 9.0 a été fabriqué également car il est plus rapide que le codage personnalisé précédent. En ce qui concerne le codage de texte des données binaires, vous n'aurez probablement pas beaucoup plus rapidement que ce qu'il y a actuellement.
Si cela n'est pas assez bon pour vous, vous pouvez envisager d'utiliser le protocole binaire entre le client et le serveur PostgreSQL. Ensuite, vous obtenez essentiellement le matériel directement à partir du disque, ce qui ressemble beaucoup à de grands objets. Je ne sais pas si le PostgreSQL JDBC le supporte encore, mais une recherche rapide suggère non.
Fondamentalement, il y a des cas où chacun a du sens. Bytea est plus simple et généralement préférée. Le client Libs vous donne le décodage afin que ce n'est pas un problème.
Cependant, les lobes ont des fonctions soignées, telles qu'une capacité de recherche en eux et de traiter le lob en tant que flux d'octets au lieu d'un tableau d'octets.
"BIG" signifie "assez grand que vous ne voulez pas l'envoyer au client tout à la fois." Techniquement, la bytea est limitée à 1 Go comprimé et un lob est limité à 2 Go comprimé, mais vous avez vraiment frappé l'autre limite d'abord de toute façon. Si c'est assez gros, vous ne le souhaitez pas directement dans votre ensemble de résultats et que vous ne voulez pas l'envoyer au client tout à la fois, utilisez un lob.
Je suppose que de gros objets sont compressés, identiques à ceux que grillés bytea colonnes?
TL; DR Utilisez BYTEA Sauf si vous avez besoin de "streaming".
Le gros objet est divisé en plusieurs rangées. Cela vous permet de rechercher, de lire et d'écrire de gros objets comme un fichier OS. Vous pouvez les utiliser sans charger toute la chose en mémoire à la fois.
Cependant, les gros objets ont des descentes:
La table d'objet est seulement une grande table par base de données.
Les gros objets ne sont pas automatiquement supprimés lorsque l'enregistrement "possédant" est supprimé. (Techniquement, plusieurs enregistrements peuvent être référencés par plusieurs enregistrements.) Voir la fonction Comme il n'y a qu'une seule table, les autorisations de gros objet doivent être traitées en record par enregistrement.
Streaming est difficile et a moins de support par les pilotes de clients que de simples Cela fait partie du schéma système, vous n'avez donc pas limité aucun contrôle sur les options telles que partitionnement et espaces de table.
En termes de capacité, il n'y a pas une énorme différence. Je vis de deviner que 93% des utilisations du monde réel des gros objets seraient mieux desservies en utilisant bytea est une séquence d'octets et fonctionne comme n'importe quelle autre valeur.
lo_manage dans le module lo .
bytea .
bytea est limité à 1 Go; Les gros objets sont limités à 2 Go. Si 1 Go est trop limitant, probablement 2GB est aussi aussi.
bytea .
Une mise en garde pour les gros objets - Comme tous les morceaux partagent la même table du système, la limite sur la quantité que vous pouvez stocker au total est inférieure à celle du
BYTEA .En fonction de ce qu'ils sont,
lo_compat_privileges peut résoudre les problèmes de compatibilité.