PostgreSQL: BYTEA против OID+большой объект?
Я запустил приложение с Hibernate 3.2 и PostgreSQL 8.4. У меня есть некоторые byte[] поля, которые были определены как @Basic (= PG bytea) и другие, которые были сопоставлены как @Lob (=PG большой объект). Почему разнобой? Потому что я спящий нуб.
теперь эти поля максимальны 4 Кб (но среднее значение составляет 2-3 КБ). В документации PostgreSQL упоминалось, что LOs хороши, когда поля большие, но я не видел, что означает "большой".
я обновился до PostgreSQL 9.0 с Hibernate 3.6, и я застрял, чтобы изменить аннотацию на @Type(type="org.hibernate.type.PrimitiveByteArrayBlobType"). Эта ошибка вызвала потенциальную проблему совместимости, и в конце концов я обнаружил, что большие объекты-это боль, с которой нужно иметь дело, по сравнению с обычным полем.
поэтому я думаю изменить все это на bytea. Но меня беспокоит, что bytea поля закодированы в Hex, поэтому есть некоторые накладные расходы при кодировании и декодировании, и это повредит производительности.
там хорошо контрольные показатели эффективности обоих из них? Кто-нибудь сделал подмену и увидел разницу?
3 ответов
в принципе есть случаи, когда каждый имеет смысл. bytea проще и, как правило, предпочитают. Клиентские библиотеки дают вам декодирование, так что это не проблема.
однако над полем есть некоторые аккуратные функции, такие как возможность искать внутри них и рассматривать LOB как поток байтов вместо массива байтов.
" большой "означает" достаточно большой, вы не хотите отправлять его клиенту сразу."Технически bytea ограничен 1GB сжатым, а lob ограничен 2GB сжатый, но на самом деле вы все равно сначала достигаете другого предела. Если он достаточно большой, вы не хотите, чтобы он был непосредственно в вашем результирующем наборе, и вы не хотите отправлять его клиенту сразу, используйте LOB.
но меня беспокоит, что поля bytea закодированы в Hex
bytea вход может быть в формате hex или escape, это ваш выбор. Хранение будет таким же. Начиная с Версии 9.0 выходным значением по умолчанию является hex, но вы можете изменить это, изменив параметр bytea_output.
Я не видел никаких ориентиров.
У меня нет сравнения больших объектов и bytea, но обратите внимание, что переход на формат вывода hex в 9.0 был сделан также потому, что он быстрее, чем предыдущая пользовательская кодировка. Что касается текстового кодирования двоичных данных, вы, вероятно, не получите намного быстрее, чем есть в настоящее время.
Если это недостаточно хорошо для вас, вы можете рассмотреть возможность использования двоичного протокола между клиентом PostgreSQL и сервером. Тогда вы в основном получаете материал прямо с диска, очень похоже на большие предметы. Я не знаю, поддерживает ли PostgreSQL JDBC это, но быстрый поиск предлагает нет.