PostgreSQL: BYTEA против OID + большой объект?

Question

Я запустил приложение с Hibernate 3.2 и PostgreSQL 8.4.У меня есть byte[] поля, которые были отображены как @Basic (= PG bytea), а другие - как @Lob (= PG Large Object).Почему несоответствие?Поскольку я был нубером Hibernate.

Теперь эти поля составляют максимум 4 Кб (но в среднем это 2-3 кб).В документации PostgreSQL упоминалось, что LO хороши, когда поля большие, но я не понял, что означает «большой».

Я обновился до PostgreSQL 9.0 с Hibernate 3.6 и застрял, чтобы изменить аннотациюдо @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType").Эта ошибка выдвинула потенциальную проблему совместимости, и в конце концов я обнаружил, что с большими объектами приходится сталкиваться с болью по сравнению с обычным полем.

Так что я думаю об изменении всего этого на bytea,Но я обеспокоен тем, что поля bytea кодируются в шестнадцатеричном формате, поэтому при кодировании и декодировании возникают некоторые накладные расходы, и это может ухудшить производительность.

Существуют ли хорошие показатели производительности обоих?Кто-нибудь сделал переключатель и увидел разницу?

Answer 1

В основном есть случаи, когда каждый имеет смысл. Bytea проще и обычно предпочтительнее. Клиентские библиотеки дают вам декодирование, так что это не проблема.

Однако у больших объектов есть некоторые полезные функции, такие как возможность искать в них и обрабатывать большие объекты как поток байтов вместо массива байтов.

«Большой» означает «достаточно большой, чтобы не отправлять его клиенту сразу». Технически, bytea ограничен 1 ГБ сжатого, а lob ограничен 2 ГБ сжатого, но в любом случае вы сначала достигнете другого предела. Если он достаточно большой, вы не хотите, чтобы он был непосредственно в наборе результатов, и вы не хотите сразу отправлять его клиенту, используйте LOB.

Answer 2

Но меня беспокоит, что байтовые поля кодируются в шестнадцатеричном формате.

Байтовый ввод может быть в шестнадцатеричном или escape-формате, это ваш выбор.Хранение будет таким же.Начиная с версии 9.0, выходным значением по умолчанию является шестнадцатеричное, но вы можете изменить это, отредактировав параметр bytea_output .

Я не видел никаких тестов.

Answer 3

У меня нет сравнения больших объектов и удобных байт, но обратите внимание, что переключение на шестнадцатеричный формат вывода в 9.0 было сделано также потому, что оно быстрее, чем предыдущая пользовательская кодировка. Что касается текстового кодирования двоичных данных, вы, вероятно, не получите намного быстрее, чем в настоящее время.

Если этого недостаточно, вы можете рассмотреть возможность использования двоичного протокола между клиентом и сервером PostgreSQL. Тогда вы в основном получаете материал прямо с диска, как большие объекты. Я пока не знаю, поддерживает ли это PostgreSQL JDBC, но быстрый поиск подсказывает нет.