|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks, Ну и какой смысл в таком бэкапе? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:29 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, вообще-то смысл есть. Файлы то можно не все копировать, а только новые. С базой данных такое проблематично ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:33 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов ДенисС базой данных такое проблематично Инкрементальный бэкап существует. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:35 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, инкрементальный бекап надо периодически накатывать на полный, и делать полный тоже. Иначе когда пипец придёт будешь восстанавливаться очень долго. А база состоящая чуть менее чем полностью из блобов очень большая. Это тебе не инкрементальный бекап на основе гуида в 4.0 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:52 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денисинкрементальный бекап надо периодически накатывать на полный Никаких отличий от копирования новых файлов, их тоже надо накатывать на полную копию. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 12:55 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис ъъъъъ, вообще-то смысл есть. Файлы то можно не все копировать, а только новые. С базой данных такое проблематично Если не знать о наличии готового инструмента "инкрементальный бэкап" - тогда да. Ну, ОК, причины решения типа "внешние файлы" примерно понятны. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:02 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ, об инструменте то известно. Но подумай вот о чём. Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? Это тебе не 4.0, где ты можешь иметь полуготовую БД и накатывать на неё только последний инкремент. С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? ОК, 1Тб - небыстро. А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое? Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы? Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:42 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денис С отдельным файлами ты копируешь только новые файлы. Старые у тебя всегда на готове. Просто нужно хорошо понимать как им пользоваться :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Basil A. Sidorov Если взять за правило никогда не изменять внешние файлы после первоначального создания Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 14:59 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ Не меняем, не удаляем, храним все версии - отлично, партизаны всё толще. Хранятся уникальные экземпляры файлов - запрет на изменение после создание позволяет связывать с одним экземпляром хоть миллион имён. Сборка мусора - фоновая (не приоритетная) задача. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 15:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ Симонов Денис Допустим ты сделал копию уровня 0. База данных 1Тб. Далее делаешь инкрементные копии. Вот наделал ты их за месяц 100 штук. Тут падает база данных сколько ты будешь её восстанавливать по времени? ОК, 1Тб - небыстро. А случае "внешнего" хранения мгновенно восстанавливаем маленький файл базы, и ничего, что ссылки в нем могут слегка не соответствовать реальному состоянию файлов? Пусть будет слегка расхристанное состояние консистентности, зато восстановление быстрое? Или к файлам применяем некую чудесную операцию, восстанавливающую их к состоянию на момент бэкапа файла базы? Даже если "внешние" файлы все, полностью бэкапились в момент бэкапа файла базы - как ты обеспечишь консистентность "файл базы <-> внешние файлы" в таком бэкапе? Выгонишь всех юзеров на время бэкапа или переведешь их в режим ридонли? Я наверное глупый и не понимаю смысла жизни, но мне почему-то кажется, что при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys. Оно, конечно, ломотно - шевелить мозгами-руками раз в год по обещанию вместо того, чтобы часов по 8 получать ежедневный бакап и 80 подождать окончания рестора при аврале. Опять же, это время можно потратить на удовольствие от курения бумбука и принятия элитного алкоголя, кстати, секретаршам и бухгалтершам в это время совершенно нехрен делать, а на работе быть надо и, чем чёрт не шутит, может и перепасть... Впрочем, я, как всегда, ни на чём не настаиваю, конкретные ситуации они и есть конкретные. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 21:48 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка при хранении ссылки на файл, живущий в ФС внутри БД, последняя версия 100 раз обновлённого файла по той же ссылке путь-имя - это именно то, что доктор прописал после восстановления повреждённой базы со ссылками. Остаются вопросы по удалённым и добавленным с момента создания бакапа файлам. Решается, в общем-то, тривиально при применении драйвера hands.sys. Это не мои базы, это не моя война, я - чЮдо-программист, а не админ и не эксплуатационник. Программный продукт "в коробке", нафига мне им рассказывать о внутренней кухне, чтобы они там внутри копались? Да и, клиент дай бог вообще хоть какой бэкап настроит, а чтобы он что-то там начал выборочно внутри копаться - это вообще фантастика. Надежность обеспечивается исправным оборудованием вкупе с надежным энергоснабжением и регулярным резервным копированием в соответствии с рекомендациями, а восстанавливать данные по файликам - это кто будет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.05.2020, 22:15 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
ъъъъъ fraks, Ну и какой смысл в таком бэкапе? Смысл в том что такой бэкап компактнее и делается быстрее, в обе стороны. Естественно, допустимость такого очень зависит от того что там за картинки. Если это документы которые существенно обесценивают данные при их отсутствии, то у меня например это картинки к товарам, и это не является критичным. Я даже не делаю специальных бэкапов этой папки с картинками. Если вдруг с ней что-то случается - сделаю обратную синхронизацию из какого-нибудь филиала, ибо в ту сторону синхронизация происходит как минимум ежедневно. Для меня критично снижение нагрузки на сервер при бэкапах во время работы. Ну и время рестора, если вдруг такое понадобится. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 03:51 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
fraks например это картинки к товарам, и это не является критичным Понятный пример, спасибо. У меня - наоборот, база существует ради этих "картинок". В общем, все как всегда: "детали важны". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 05:08 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Можно свои 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.
"Думайте сами, решайте сами - иметь или не иметь". ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:06 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
shalamyansky, Способ №3 имеет мало преимуществ по сравнению с №2. Сейчас все же ломают копья сторонники №1 и №2. Из плюсов 2 и 3 - возможность дедупликации. Хотя наверное и в №1 это можно устроить ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:23 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Шавлюк ЕвгенийСпособ №3 имеет мало преимуществ по сравнению с №2. ну это смотря где используешь. Представь себе какой-нибудь веб-сайт. В простейшем случае картинка это просто файл до которого есть доступ у веб сервера, и он отдаёт его простой веб-ссылкой. А если это запихнули в блоб, то файлик из блоба ещё надо прочитать, а потом отдать его с нужными заголовками. Если содержимое файла защищено, то это конечно оправдано, а если оно не нуждается в каких-то там привилегиях, то имеем не хилый оверхед. Каждый случай имеет право на существование. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 15:34 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Насчёт "оверхеда" при хранении в блобах. Я так понимаю, что ни у кого именно с "оверхедом" именно из-за неправильно выбранной архитектуры хранения файлов проблем не было. Никто из-за него не переделывал систему со схемы "файлы в блобах" на "файлы снаружи" (или наоборот)? Предполагаю, что нет. :) Мне нравится схема, когда изображения товаров хранятся "снаружи", а сам файл базы остаётся крошечным, и при этом не сильно страшно сломать связи с несколькими картинками. Я бы в клиента кнопку возле картинки добавил - "Сообщить об отсутствии изображения или об ошибке"... :) ... Но вот у меня "картинками" являются, например, разные документы по расчёту стоимости, и, если пролюбить утвержденный план замены бордюрного камня в СВАО Москвы, то, мне кажется... ыыы ... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 16:39 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Симонов Денисимеем не хилый оверхед. Современные уэб-программисты не заботятся о таких мелочах. Они и кэширование-то картинок всегда запрещают, не то что там установить LastModified заголовок. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:04 |
|
Хранение фотографий в БД Firebird 2.5
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, разве вебпрограммисты используют Firebird? У них что-то волшебное, которое само собой объекты в базу сохраняет, и наоборот, из базы объекты восстановливает, с дикой скоростью. Так пишут. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2020, 17:11 |
|
|
start [/forum/topic.php?fid=40&msg=39959385&tid=1560348]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
151ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
others: | 253ms |
total: | 517ms |
0 / 0 |