LINUX.ORG.RU

SQL database binary data store


0

0

Может кто объяснить или ткнуть носом в ссылку: почему всегда пугают - "Не надо хранить бинарные данные в базе данных!". Почему не надо? Говорят про ужасные нагрузки на базу данных, на то, что она для этого не предназначена... Какой может быть вред от простой таблицы, которая имеет вид идентификатор/бинарные данные с индексом на идентификатор?
Понимаю, что реляционные базы данных создавались не для этого, но объясните, пожалуйста, кто знает - какие могут быть проблемы и почему так лучше не делать?

Заранее спасибо.


Да фиг его знает, если посмотреть на PostgreSQL, то видим следующее:
1. Импортированный в базу файл размещается на диске в отдельном файле, так что если база рухнет, то восстановление файла не будет отличаться от восстановления файла на файл-сервере (единственное - название файла заменится на идентификатор LO - OID). В 8.0.0 - не так :-( файл записан блоками вперемешку со служебными данными PostgreSQL :-(
2. Если посмотреть исходники libpq (библиотеки работы с PostgreSQL), то увидим, что файл по сети передается блоками, по-умолчанию размер блока 8Kb в PostgreSQL 8.0.0, что маловато для передачи больших файлов, однако это значение можно увеличить (безболезненно увеличивал в 7.0.x, только нужно libpq и сервера и клиента править).

saper ★★★★★
()
Ответ на: комментарий от saper

Спасибо за грамотный ответ - уж не думал, что кто-то вообще ответит...

Интересует как раз PostgreSQL, но никак не могу найти хорошую документацию по этому поводу... Где можно почитать про специфику работы PostgreSQL с бинарными данными через Large Objects? В чём минусы/плюсы и так далее?

То что в 8.0 файлы идут вперемешку - не пугает - хотелось бы, чтобы при этом все сервисные программы (как то backup) работали и на этих таблицах. Кстати, а такое решение (про перемешку блоками) как-то обосновывают? Скорость?

Заранее спасибо.

xlex
() автор топика
Ответ на: комментарий от xlex

> Кстати, а такое решение (про перемешку блоками) как-то обосновывают? Скорость?
Мне кажется тут больше от единой архитектуры, начиная с какой то версии стало возможным хранить данные в поле text неограниченной длины (ограничения по большей части только от файлововй системы).

Уточни, что тебя конкретно интересует? Чтобы JDBC/ODBC драйвер для Windows стал поддерживать большие объекты в PostgreSQL посмотри в папку contrib исходников сервера на предмет lo.

Можешь еще посмотреть исходники libpq, да и документация у PostgreSQL довольно таки хорошая :) Если что то конкретное - отпиши, общих таких обзоров или сравнений я не встречал, поискать можно где-нибудь на gborg.postgresql.org и www.postgresql.org в документации.

saper ★★★★★
()
Ответ на: комментарий от saper

Меня интересует собственно сам PostgreSQL (на данный момент доступ к нему из PHP), и нюансы связанные с бинарными данными (насколько я знаю с ними можно напортачить так, что в результате будет весьма ощутимо подтормаживать вся база данных) - то есть как стоит делать, на что следует обратить внимание, какие недостатки и достоинства у каждого из них (в официальной документации я этого не нашёл).

Проблема в том, что до этого использовалась MySQL (у неё, как мне кажется, документация получше будет) и хотелось бы прочитать про особенности PostgreSQL (книгу Стоунза и Метью, для начала прочитал, но там далеко не всё затронуто...).

xlex
() автор топика
Ответ на: комментарий от xlex

Посмотрел 8.0.0:
- все большие объекты при импорте пишутся в один файл на диске;
- при удалении большого объекта на диске место не освобождается (этот единственный файл сохраняет прежний размер);
- размер единственного файла со всеми большими объектами уменьшается после команды vacuum.

Минус очевиден - если рухнет этот единственный файл, то все большие объекты потеряются.

По работе из PHP c PostgreSQL не подскажу :-(

saper ★★★★★
()
Ответ на: комментарий от xlex

Если будете менять размер блока большого объекта в библиотеках PostgreSQL - делайте это осторожно и обязательно тестируйте, неизвестно что там в новых версиях :-|

saper ★★★★★
()
Ответ на: комментарий от saper

Да, но если рухнет любой файл с таблицей - то все объекты внутри него потеряются (то есть это применимо к любой таблице)...

Насчёт PHP - и не надо, я просто общую дополнительную документацию по этой базе данных, по её устройству и идеалогии. Вот эта информация (про 8.0), например откуда? Из собственного опыта? Или есть где почитать?

И спасибо за совет с изменением размера блока данных.

xlex
() автор топика
Ответ на: комментарий от xlex

> Да, но если рухнет любой файл с таблицей - то все объекты внутри него потеряются (то есть это применимо к любой таблице)...
Да, но потенциально раньше было безопаснее, я подозреваю, что сейчас новая организация хранения больших объектов дает прибавку в скорости. Это очевидно из того, что для очистки файла требуется VACUUM.

> Вот эта информация (про 8.0), например откуда?
Поскольку недавно поставил 8.0.0, то для ответа быстренько проверил, как PostgreSQL работает с большими объектами. Вообще вся документация собрана в исходниках сервера в postgresql-8.0.0/doc/postgres.tar.gz, можно еще посмотреть комментарии в исходниках libpq (и клиента и сервера - они разные), размер буфера LO выловил именно в исходниках.

saper ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.