powered by simpleCommunicator - 2.0.48     © 2025 Programmizd 02
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / О хранении картинок в блобах
25 сообщений из 135, страница 1 из 6
О хранении картинок в блобах
    #39962560
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Расскажите, пожалуйста, о ваших случаях, когда централизованное хранение файлов документов в БД было сделано сперва в blob's, но потом из-за чего-то пришлось переделать на "внешнее" хранение (в файлах/каталогах файловой системы).

О проблемах, который послужили причиной переделки, и какой выигрыш был достигнут в результате.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962595
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ,

у меня ни разу не возникало такой необходимости. В принципе, представляю себе два возможных случая:

1. Файлы/картинки нужны на http сервере. Соответственно, их куда удобнее брать из файловой системы, нежели гнать через клиент и блобы.

2. Используется Oracle XE и размер базы не для картинок.

Но в обоих логично сразу использовать bfile.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962598
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ,

Ну на блобы всегда был лимит 2ГБ, чего не скажешь о файлах.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962600
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer,

как и когда правильно - примерно понятно.

Интересны случаи перехода с одной архитектуры на другую, причины перехода и достигнутые результаты.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962601
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
softwarer,

как и когда правильно - примерно понятно.

Интересны случаи перехода с одной архитектуры на другую, причины перехода и достигнутые результаты.
Был переход с блобов VARBINARY на FILESTREAM (SQL Server), читай блобы хранятся в файловой системе. Чтобы не кушало драгоценный SQL кэш, а запросы к блобам ходили мимо него. Ведь производительность таких запросов - не критична, а экономия главных ресусров - памяти очень даже.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962606
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Relic Hunter
Чтобы не кушало драгоценный SQL кэш

Это в смысле кэш запросов (планов запросов) или в смысле данных (содержимого этих блобов)?
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962607
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Relic Hunter,

что в итоге изменилось?
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962608
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Relic Hunter
Чтобы не кушало драгоценный SQL кэш

Это в смысле кэш запросов (планов запросов) или в смысле данных (содержимого этих блобов)?
Не совсем правильно выразился. От кэша запросов никуда не деться, а вот блоков данных очень даже нужно (Data Buffer) и забивать их блобами в целом не хорошо.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962609
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Relic Hunter,

что в итоге изменилось?
В результе операции вставки/чтения блобов замедлились, чего и добивались. Зато возрасла скорость более важных запросов.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962610
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Relic Hunter
ъъъъъ
Relic Hunter,

что в итоге изменилось?
В результе операции вставки/чтения блобов замедлились, чего и добивались. Зато возрасла скорость более важных запросов.

Нифига себе оптимизация...
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962611
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Relic Hunter
От кэша запросов никуда не деться, а вот блоков данных очень даже нужно (Data Buffer) и забивать их блобами в целом не хорошо.

Ясно. В Oracle это решается настройкой кэширования на уровне конкретного lob-поля в таблице. По умолчанию значение nocache (то есть блоки блоба не ложатся в buffer cache).
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962612
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Relic Hunter
пропущено...
В результе операции вставки/чтения блобов замедлились, чего и добивались. Зато возрасла скорость более важных запросов.

Нифига себе оптимизация...
Не подготовленные люди не сразу понимают сути происходящего. Затем и нужны профессионалы))
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962613
Фотография Relic Hunter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Relic Hunter
От кэша запросов никуда не деться, а вот блоков данных очень даже нужно (Data Buffer) и забивать их блобами в целом не хорошо.

Ясно. В Oracle это решается настройкой кэширования на уровне конкретного lob-поля в таблице. По умолчанию значение nocache (то есть блоки блоба не ложатся в buffer cache).
Ну так на то оно и значение по умолчанию и что его может изменить нехороший человек ("ридиска") ))
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962614
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Relic Hunter,

ну почему же нехороший? Сервер вполне разумно говорит, что если некоторое lob-поле хранит небольшие и часто нужные данные - ставь ему cache и наслаждайся производительностью. А если ридиска имеет возможность править параметры хранения на продакшне - виноват не ридиска, а те, кто ему такую возможность предоставил.

P.S. Вот смысла значение cache reads я не очень понимаю. В этом режиме читаемые блобы кэшируются, а записываемые - нет. Может быть, это для какого-нибудь экстравагантного случая таблицы, в которой блобы из нескольких строчек постоянно читаются, а из остальных - часто пишутся и редко читаются.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962685
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Расскажите, пожалуйста, о ваших случаях, когда централизованное хранение файлов документов в БД было сделано сперва в blob's, но потом из-за чего-то пришлось переделать на "внешнее" хранение (в файлах/каталогах файловой системы).

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


Когда блобы хранятся в одной бд с транзакционными данными, рано или поздно возникнет проблема. База вырастает и транзакции замедляются. Бекап вырастает в размере, что создает проблемы в администрировании.

В общем блобы надо держать в отдельной бд со своими настройками.

При хранении в файловой системе возникает проблема при большом кол-ве файлов в одной папке или большом числе файлов на диске.

Сейчас есть FileCatalog в MSSQL, который маппит БД с файловой системой.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962691
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Relic Hunter
ъъъъъ
Relic Hunter,

что в итоге изменилось?
В результе операции вставки/чтения блобов замедлились, чего и добивались. Зато возрасла скорость более важных запросов.


Действительно, только профи оценит, "как красиво изменилась архитектура в результате падения производительности системы"
(система блобы-"картинки" стала отдавать медленнее. Все остальное быстрее - да, круто).

И клиент и начальник навряд ли оценит "едет медленнее, зато как жужжит!"
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962692
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ,

я пожалуй тут постою.
подожду ответов в метриках - примеров успехов, так сказать.
Об этом холиваре "картинки в БД vs картинки в FS" я слышал примерно 100500 раз начиная с 2011 года.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962714
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hawkmoon
ъъъъъ,

я пожалуй тут постою.
подожду ответов в метриках - примеров успехов, так сказать.
Об этом холиваре "картинки в БД vs картинки в FS" я слышал примерно 100500 раз начиная с 2011 года.


Ваш знакомый знает толк в извращениях, в base64 кодировать и декодировать потом на каждый чих. Лучше бы мне это процессорное время подарил.

Давайте рассмотрим плюсы и минусы хранения ассетов (графики, скриптов, стилей) в БД, по сравнению с файлами на диске:


Плюсы:

Доступность из любого места проекта, без проксирования и использования сетевых файловых систем;
Возможность гарантированного хранения произвольных метаданных, без отрыва от файла;
Возможность организации файловой системы не в виде орграфа.
Пониженная нагрузка на физические диски (без учета возможного локального дискового кэша);
ACID, при условии реализации его базой данных.


Минусы:

Дополнительная машинерия для доступа к данным (отдачи клиенту, записи файлов администратором и т. д.);
Повышенная латентность, нагрузка на сеть и сервер БД;
Избыточная обработка, связанная с протоколом работы с БД (включая сериализацию данных), по сравнению с протоколом работы с файловой системой.
Отсутствие некоторых инструментов, например, sendfile(2) или mmap(2).
В абсолютном большинстве случаев, хранение и отдача ассетов сводится к неизменяемым файлам с хорошо определенными именами, прекрасно укладывающимся даже не в орграф, а в дерево. Отдача легковесным сервером типа nginx, за счет инструментов типа sendfile и кэширования (выполняется VFS-подсистемой ядра ОС), позволяет отдавать их с минимальными издержками, что и требуется для задачи.

Большинство плюсов, при этом, достаточно условны, т.к. БД в большом ряде случаев будут проигрывать по сравнению с более специализированными инструментами (например, GlusterFS или MooseFS) или композитными (БД для метаданных, традиционная ФС для данных) решениями.

Итого: следует считать, смысла в базе данных для хранения ассетов нет. Если возникает редкий случай, когда он появляется — вы об этом узнаете. Взято https://ru.stackoverflow.com/questions/112730/Способы-хранения-картинок
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962764
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_voronin
Бекап вырастает в размере, что создает проблемы в администрировании.

Когда нужно восстановить систему после сбоя и внезапно оказывается, что части нужных данных просто нет, это создаёт куда большие проблемы в администрировании.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962803
Hawkmoon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
a_voronin,

об этом и так все знают.
не надо это доказывать.

Вопрос топик-стартера же не в этом. А "кто реально отказывался от хранения в БД и перекладывал в файлы и к чему это привело в цифрах ?"
Как - не интересно. Интересно к чему привело. А мне еще интересно - и сколько это стоило в человекоднях.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962850
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hawkmoon
a_voronin,

об этом и так все знают.
не надо это доказывать.

Вопрос топик-стартера же не в этом. А "кто реально отказывался от хранения в БД и перекладывал в файлы и к чему это привело в цифрах ?"
Как - не интересно. Интересно к чему привело. А мне еще интересно - и сколько это стоило в человекоднях.


Отказались от хранения Excel в той же БД, что и остальные данные. Сделали 2 Бд. Заняло 1 человекодень. Загрузка данных ускорилась, но точно не мерила.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962885
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
a_voronin
Когда блобы хранятся в одной бд с транзакционными данными, рано или поздно

Спасибо, но к вопросу ваш ответ не имеет никакого отношения.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962891
dimonz80
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ъъъъъ
Расскажите, пожалуйста, о ваших случаях, когда централизованное хранение файлов документов в БД было сделано сперва в blob's, но потом из-за чего-то пришлось переделать на "внешнее" хранение (в файлах/каталогах файловой системы).

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


Миграция хранения файлов из БД в ФС только планируется. База Postgresql 10, файлы хранятся как BLOB. Файлы в основном не очень большие, несколько Мб (сканы в PDF по большей части). Файлов около 100 тыс. Сначала планировалось, что файлы удаляться не будут. При таком раскладе (кроме повышенного расхода дискового пространства) проблем не должно было возникнуть, т. к. физически, точнее на уровне таблицы с блобами файлы хранятся "подряд" идущими блоками и доступ на стенде размером в 100 Гб был более чем приемлемый (Postgressql хранит блобы в спец таблице pg_largeobject, порубленными по 2 Кб на кортеж) . Однако ситуация изменилась, когда понадобилось удалять файлы, т.к. в середине таблицы появились "дыры", в которые стали записываться куски новых файлов, а другие куски которые не влезли - в конец и скорость доступа начала понемногу деградировать, т.к. считать файл "последовательно" уже не получается.

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

Как-то так.
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962924
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
dimonz80,

Вы планируете использовать ФС, в которой не бывает фрагментации?
...
Рейтинг: 0 / 0
О хранении картинок в блобах
    #39962926
fkthat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Вы планируете использовать ФС, в которой не бывает фрагментации?

На SSD фрагментация побоку.
...
Рейтинг: 0 / 0
25 сообщений из 135, страница 1 из 6
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / О хранении картинок в блобах
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]