PostgreSQL: BYTEA vs OID + Большой объект?

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

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

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

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

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

Ответы

Ответ 1

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

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

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

Ответ 2

Но я обеспокоен тем, что поля bytea закодированы в Hex

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

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

Ответ 3

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

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