powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Хранение фотографий в БД Firebird 2.5
23 сообщений из 48, страница 2 из 2
Хранение фотографий в БД Firebird 2.5
    #39959383
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fraks,

Ну и какой смысл в таком бэкапе?
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959385
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ,

вообще-то смысл есть. Файлы то можно не все копировать, а только новые. С базой данных такое проблематично
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959388
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисС базой данных такое проблематично

Инкрементальный бэкап существует.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959403
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

инкрементальный бекап надо периодически накатывать на полный, и делать полный тоже. Иначе когда пипец придёт будешь восстанавливаться очень долго. А база состоящая чуть менее чем полностью из блобов очень большая. Это тебе не инкрементальный бекап на основе гуида в 4.0
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959407
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисинкрементальный бекап надо периодически накатывать на полный

Никаких отличий от копирования новых файлов, их тоже надо накатывать на полную копию.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959461
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денис
ъъъъъ,

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

Если не знать о наличии готового инструмента "инкрементальный бэкап" - тогда да.

Ну, ОК, причины решения типа "внешние файлы" примерно понятны.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959462
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ,

об инструменте то известно. Но подумай вот о чём.
Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук.
Тут падает база данных сколько ты будешь её восстанавливать по времени?

Это тебе не 4.0, где ты можешь иметь полуготовую БД и накатывать на неё только последний инкремент.

С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959497
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Симонов Денис
Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук.
Тут падает база данных сколько ты будешь её восстанавливать по времени?


ОК, 1Тб - небыстро.

А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов?
Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое?
Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы?

Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли?
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959507
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов?
Если взять за правило никогда не изменять внешние файлы после первоначального создания, то ошибок будет всего две: "нет файла" и "есть мусор". Критична только первая.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959508
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис
С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове.
Никто не мешает так же делать с инкрементным бекапом хоть в 2.5
Просто нужно хорошо понимать как им пользоваться :)
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959518
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Basil A. Sidorov
Если взять за правило никогда не изменять внешние файлы после первоначального создания

Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959521
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще.
"Не доводи ничего до абсурда, ибо человек желающий трапезовать поздно вечером, рискует трапезовать рано по утру".
Хранятся уникальные экземпляры файлов - запрет на изменение после создание позволяет связывать с одним экземпляром хоть миллион имён.
Сборка мусора - фоновая (не приоритетная) задача.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959685
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
Симонов Денис
Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук.
Тут падает база данных сколько ты будешь её восстанавливать по времени?


ОК, 1Тб - небыстро.

А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов?
Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое?
Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы?

Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли?


Я наверное глупый и не понимаю смысла жизни, но мне почему-то кажется, что при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys. Оно, конечно, ломотно - шевелить мозгами-руками раз в год по обещанию вместо того, чтобы часов по 8 получать ежедневный бакап и 80 подождать окончания рестора при аврале. Опять же, это время можно потратить на удовольствие от курения бумбука и принятия элитного алкоголя, кстати, секретаршам и бухгалтершам в это время совершенно нехрен делать, а на работе быть надо и, чем чёрт не шутит, может и перепасть... Впрочем, я, как всегда, ни на чём не настаиваю, конкретные ситуации они и есть конкретные.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959694
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Старый плюшевый мишка
при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys.

Это не мои базы, это не моя война, я - чЮдо-программист, а не админ и не эксплуатационник.
Программный продукт "в коробке", нафига мне им рассказывать о внутренней кухне, чтобы они там внутри копались? Да и, клиент дай бог вообще хоть какой бэкап настроит, а чтобы он что-то там начал выборочно внутри копаться - это вообще фантастика.
Надежность обеспечивается исправным оборудованием вкупе с надежным энергоснабжением и регулярным резервным копированием в соответствии с рекомендациями, а восстанавливать данные по файликам - это кто будет?
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959732
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ъъъъъ
fraks,
Ну и какой смысл в таком бэкапе?


Смысл в том что такой бэкап компактнее и делается быстрее, в обе стороны.
Естественно, допустимость такого очень зависит от того что там за картинки.
Если это документы которые существенно обесценивают данные при их отсутствии, то у меня например это картинки к товарам, и это не является критичным. Я даже не делаю специальных бэкапов этой папки с картинками. Если вдруг с ней что-то случается - сделаю обратную синхронизацию из какого-нибудь филиала, ибо в ту сторону синхронизация происходит как минимум ежедневно.

Для меня критично снижение нагрузки на сервер при бэкапах во время работы.
Ну и время рестора, если вдруг такое понадобится.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959736
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
fraks
например это картинки к товарам, и это не является критичным

Понятный пример, спасибо.

У меня - наоборот, база существует ради этих "картинок".

В общем, все как всегда: "детали важны".
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959872
shalamyansky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Можно свои 3 копейки внесу?

Вариантов хранения пользовательских файлов не 2, а 3 как минимум. Вот ИМХО их достоинства и недостатки:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
вариант                                       плюсы                                      минусы

1 Файлы хранятся в BLOB и                     "автоматически", т. е. средствами СУБД     возможно большой объем базы, что следствием имеет
  и отдаются через select соответственно      обеспечены целостность всех данных         большие времена backup и restore
                                              и транзакционность операций с ними

2 Файлы хранятся в файловой системе сервера,  сравнительно небольшой объем базы          целостность и транзакционность не обеспечены,
  но отдаются (возможно, и загружаются)                                                  в том числе и для backup, однако их можно попытаться
  посредством udf через sql-соединение                                                   поддержать своим ПО поверх СУБД

3 Файлы хранятся в файловой системе,          сравнительно небольшой объем базы          а) целостность и транзакционность не обеспечены,
  и отдаются параллельным транспортом                                                       и поддержка их в условиях полностью независимоых друг от друга
  (http, ftp, samba и иже с ними)                                                           методов доступа к файлам и базе (независимых по пользователям,                            
                                                                                            правам доступа, времени доступа, транспорту) представляется 
                                                                                            малореальной. Это касается и backup в первую очередь.
 
                                                                                         б) второй транспорт требует дополнительных усилий по 
                                                                                            администрированию (адреса, имена, порты, файерволы, права доступа
                                                                                            и пр. и пр.), в результате из ситуации "работает все или ничего"
                                                                                            попадаем в ситуацию "тут работает, а тут хрен"
                                                                                            с гораздо большей головной болью по поддержке


"Думайте сами, решайте сами - иметь или не иметь".
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959887
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
shalamyansky,

Способ №3 имеет мало преимуществ по сравнению с №2.
Сейчас все же ломают копья сторонники №1 и №2.
Из плюсов 2 и 3 - возможность дедупликации. Хотя наверное и в №1 это можно устроить
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959894
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Шавлюк ЕвгенийСпособ №3 имеет мало преимуществ по сравнению с №2.

ну это смотря где используешь. Представь себе какой-нибудь веб-сайт. В простейшем случае картинка это просто файл до которого есть доступ у веб сервера, и он отдаёт его простой веб-ссылкой. А если это запихнули в блоб, то файлик из блоба ещё надо прочитать, а потом отдать его с нужными заголовками. Если содержимое файла защищено, то это конечно оправдано, а если оно не нуждается в каких-то там привилегиях, то имеем не хилый оверхед.

Каждый случай имеет право на существование.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959939
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Насчёт "оверхеда" при хранении в блобах.

Я так понимаю, что ни у кого именно с "оверхедом" именно из-за неправильно выбранной архитектуры хранения файлов проблем не было.
Никто из-за него не переделывал систему со схемы "файлы в блобах" на "файлы снаружи" (или наоборот)?
Предполагаю, что нет. :)

Мне нравится схема, когда изображения товаров хранятся "снаружи", а сам файл базы остаётся крошечным, и при этом не сильно страшно сломать связи с несколькими картинками. Я бы в клиента кнопку возле картинки добавил - "Сообщить об отсутствии изображения или об ошибке"... :)
...
Но вот у меня "картинками" являются, например, разные документы по расчёту стоимости, и, если пролюбить утвержденный план замены бордюрного камня в СВАО Москвы, то, мне кажется... ыыы ...
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959960
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисимеем не хилый оверхед.

Современные уэб-программисты не заботятся о таких мелочах. Они и кэширование-то картинок
всегда запрещают, не то что там установить LastModified заголовок.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39959965
ъъъъъ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov,

разве вебпрограммисты используют Firebird? У них что-то волшебное, которое само собой объекты в базу сохраняет, и наоборот, из базы объекты восстановливает, с дикой скоростью. Так пишут.
...
Рейтинг: 0 / 0
Хранение фотографий в БД Firebird 2.5
    #39960078
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

вот тут прям обидно было )
...
Рейтинг: 0 / 0
23 сообщений из 48, страница 2 из 2
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Хранение фотографий в БД Firebird 2.5
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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