PostgreSQL: BYTEA vs OID + oggetto grande?

Question

Ho avviato un'applicazione con Hibernate 3.2 e PostgreSQL 8.4. Ho alcuni campi byte[] mappati come @Basic (= PG bytea) e altri che sono stati mappati come @Lob (= PG Large Object). Perché l'incoerenza? Perché ero un noob in letargo.

Ora, questi campi sono max 4 Kb (ma la media è 2-3 kb). La documentazione di PostgreSQL diceva che i LO sono buoni quando i campi sono grandi, ma non ho visto cosa significasse "grande".

Ho aggiornato a PostgreSQL 9.0 con Hibernate 3.6 e sono rimasto bloccato a modificare l'annotazione su @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType"). Questo bug ha portato avanti un potenziale problema di compatibilità, e alla fine ho scoperto che gli oggetti di grandi dimensioni sono un problema da affrontare, rispetto a un campo normale.

Quindi sto pensando di cambiarlo a bytea. Ma sono preoccupato che i campi bytea siano codificati in Hex, quindi c'è un sovraccarico nella codifica e nella decodifica, e questo danneggerebbe le prestazioni.

Ci sono buoni benchmark sulle prestazioni di entrambi? Qualcuno ha fatto l'interruttore e ha visto una differenza?

Answer 1

Fondamentalmente ci sono casi in cui ognuno ha un senso. bytea è più semplice e generalmente preferito. Le librerie client ti forniscono la decodifica, quindi non è un problema.

Tuttavia i LOB hanno alcune caratteristiche chiare, come la possibilità di cercare all'interno di essi e trattare il LOB come un flusso di byte invece di un array di byte.

"Grande" significa "Abbastanza grande che non si desidera inviarlo al client tutto in una volta." Tecnicamente, bytea è limitato a 1 GB compressi e un lob è limitato a 2 GB compressi, ma in realtà si raggiunge comunque l'altro limite. Se è abbastanza grande non lo vuoi direttamente nel tuo set di risultati e non vuoi inviarlo al cliente tutto in una volta, usa un LOB.

Answer 2

ma sono preoccupato del fatto che i campi bytea sono codificati in esadecimale

ingresso bytea può essere in esadecimale o la fuga formato, questa è la vostra scelta. Lo spazio di archiviazione sarà lo stesso. A partire dalla versione 9.0, l'output predefinito è hex, ma è possibile modificarlo modificando il parametro bytea_output.

Non ho visto alcun benchmark.

Answer 3

Non ho un confronto di oggetti di grandi dimensioni e facilmente a portata di mano, ma si noti che il passaggio al formato di output esadecimale in 9.0 è stato effettuato anche perché è più veloce della precedente codifica personalizzata. Per quanto riguarda la codifica del testo dei dati binari, probabilmente non si otterrà molto più velocemente di quanto non sia attualmente.

Se ciò non è abbastanza buono per te, puoi considerare l'utilizzo del protocollo binario tra client e server PostgreSQL. Quindi in pratica ottieni le cose direttamente dal disco, proprio come i grandi oggetti. Non so se il JDBC di PostgreSQL lo supporti ancora, ma una rapida ricerca suggerisce di no.