Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд.
Где предпочитаете хранить файлы (pdf, pic, binary):
1 в таблице,
2 в файловом хранилище субд,
3 в специализированных бд(отдельно от реляционной),
4 на диске(отдельно от бд).
5 иное?
Здравствуйте, vaa, Вы писали:
vaa>Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд. vaa>Где предпочитаете хранить файлы (pdf, pic, binary): vaa>1 в таблице, vaa>2 в файловом хранилище субд, vaa>3 в специализированных бд(отдельно от реляционной), vaa>4 на диске(отдельно от бд). vaa>5 иное?
Выбор зависит от предполагаемого кол-ва файлов, их среднего размера, соотношения на чтение/запись и много чего ещё, т.к. совсем универсального решения нет.
Если файлы большие, но их не очень много (например видео), то файловая система больше подходит, если файлов существенно больше, но они меньше (например аудио), уже есть о чём подумать. Если же это какие-либо документы, то уже становится важна транзакционность, и выбор уже находится от транзакционных ФС до БД, но в случае БД уже не просто работать с большими файлами (ограничения BLOB стриминга, распухание журнала транзакций).
Из практики, порой приходилось сталкиваться с PDF-ками на 20К страниц, объёмом в несколько гигабайт , это был ответ на запрос суда с полным перечнем запрашиваемых данных для проведения судебной экспертизы.
Здравствуйте, vaa, Вы писали:
vaa>Где предпочитаете хранить файлы (pdf, pic, binary): vaa>1 в таблице, vaa>2 в файловом хранилище субд, vaa>3 в специализированных бд(отдельно от реляционной), vaa>4 на диске(отдельно от бд). vaa>5 иное?
Если на диске, то нужно разумно подойти к файловой системе или учитывать особенности используемой системы. К примеру, в одной папке у вас будет 10 млрд. файлов и вы попробуете получить их список — нужно ли говорить, с какими проблемами столкнетесь?
Можно вообще отказаться от файловой системы и писать все в один большой файл или даже создать свою файловую систему под это дело.
Этот вопрос подобен вопросу о сортировке больших файлов, о чем наш коллега накатал статью. В простейшем случае как бы детский сад, но дьявол в деталях. Если у вас там миллиарды файлов, то написание своей файловой системы может оказаться лучшим вариантом.
Здравствуйте, vaa, Вы писали:
vaa>Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд. vaa>Где предпочитаете хранить файлы (pdf, pic, binary):
Если стоит вопрос предпочтения, то предпочту уже то, что уже есть в системе. Если есть субд, то пункт 1 — добавить табличку — легко и просто. Из коробки будут та же система развёртывания, миграции, бэкапов, етс для всей системы.
К следующим пунктам я бы переходил если пункт 1 не тянет по перформансу. И тут уже нужен аккуратный анализ требований и выбор решения, которое их удовлетворяет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vaa, Вы писали:
vaa>Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд. vaa>Где предпочитаете хранить файлы (pdf, pic, binary):
Зависит от того как с этими файлами работать и какие у них будут объемы
Здравствуйте, Shmj, Вы писали:
S>Можно вообще отказаться от файловой системы и писать все в один большой файл или даже создать свою файловую систему под это дело.
Ничо что это оксюморон? "отказаться от файловой системы" чтобы "создать свою файловую систему"
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, ·, Вы писали:
·>Здравствуйте, vaa, Вы писали:
vaa>>Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд. vaa>>Где предпочитаете хранить файлы (pdf, pic, binary): ·>Если стоит вопрос предпочтения, то предпочту уже то, что уже есть в системе. Если есть субд, то пункт 1 — добавить табличку — легко и просто. Из коробки будут та же система развёртывания, миграции, бэкапов, етс для всей системы. ·>К следующим пунктам я бы переходил если пункт 1 не тянет по перформансу. И тут уже нужен аккуратный анализ требований и выбор решения, которое их удовлетворяет.
мне вот тоже кажется таблица это оптимально, правда касательно объемов тут задумался,
в постгрес 35Тбайт на таблицу. т.е. около 35_000 гигов. не так уже и много, если задуматься.
т.е. по 10Мб примерно 3,5 млн записей.
тогда конечно стоит использовать https://www.npgsql.org/doc/large-objects.html?q=Large%20Objects
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, vaa, Вы писали:
vaa>>Где предпочитаете хранить файлы (pdf, pic, binary):
B>Где угодно, только не в самой БД!
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, ·, Вы писали: vaa> в постгрес 35Тбайт на таблицу. т.е. около 35_000 гигов. не так уже и много, если задуматься.
Это очень много. Один только бекап такой БД — уже серьезная задача. Такие объемы хранить в РСУБД не стоит, нужны специализированные blob хранилища.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Baiker, Вы писали: B>>Где угодно, только не в самой БД!
vaa>Почему? vaa>www.npgsql.org large-objects vaa>microsoft.com
Потому что не всё то зелёное, что летит. ДАЛЕКО не всё, что придумывают офисные "джамшуты" надо бежать реализовывать (яркий пример — EF).
Поначалу кажется да — всё засунули в БД — моногамия и красота! Но когда начнётся наполнение БД, а ты (очевидно) продолжаешь развивать систему, ты очень быстро придёшь к ситуации, когда надо что-то быстро забэкапить, изменить, посчитать, обновить данные, а твоя 10К база из-за large-objects распухла до размеров гигабайта и ты как дурак вынужден ждать по 5 минут операции с бэкапами только потому, что засунул в базу НЕИЗМЕНЯЕМЫЕ большие объекты, которые там нахрен не сдались. И см. ниже:
Sharov>Почему нет, если, например, небольшие файлы 5-10мб типа картинок?
ТЕМ БОЛЕЕ картинки! (к примеру, картинки товаров) Сегодня ты наструячил мегабайтных 3Д картинок, а завтра манагер подходит: "Нам нужен мобильный вебсайт — чтобы все картинки были по 5К". И начинается!... Сначала картинки выгрузи, причём так, чтобы не похерить их ID, затем отдай дизайнеру, он их ужмёт, отдаст тебе, ты ЗАНОВО импортируешь картинки в базу или того хуже — будешь создавать ещё одно поле теперь уже для ужатых картинок, да ещё согласовывать, чтобы ужатая как-то соотносилась с неужатой... ой ё!
Т.е. буквально на ровном месте огребаешь кучу проблем (+ проблемы, которые я описал для vaa). Оно тебе надо?
Я почему так говорю — тоже как вы по-молодости вляпывался во всякие "инновации от M$". И повозившись с нехреновой такой "базой с картинками", плюнул и сделал всё на внешних файлах. В результате база — маленькая, легко и БЫСТРО бэкапится/сжимается, модифицировать её — вообще без проблем (хоть каждый день пересоздавай!), а файлы организовал независимым способом: каждый файл именуется GUID'ом, а затем применяется "партишенинг": первые две буквы имени являются именем подкаталога (от единого корневого), где файлы и лежат:
Т.е. имеем распределённую систему файлов, чтобы не хранить миллиард фоток в одном каталоге.
Итого, чтобы мне перенести такую хренову тучу файлов в развёртываемую систему, мне достаточно из сархивировать и скопировать! Причём на любой носитель (не засирая системный с БД). Ну а в базе храним только имена конечных файлов, которые опять же легко переносятся, дополняются и т.п.
Здравствуйте, Baiker, Вы писали:
B>Потому что не всё то зелёное, что летит. ДАЛЕКО не всё, что придумывают офисные "джамшуты" надо бежать реализовывать (яркий пример — EF).
B>Поначалу кажется да — всё засунули в БД — моногамия и красота! Но когда начнётся наполнение БД, а ты (очевидно) продолжаешь развивать систему, ты очень быстро придёшь к ситуации,
Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо.
B>Sharov>Почему нет, если, например, небольшие файлы 5-10мб типа картинок?
B>ТЕМ БОЛЕЕ картинки! (к примеру, картинки товаров) Сегодня ты наструячил мегабайтных 3Д картинок, а завтра манагер подходит: "Нам нужен мобильный вебсайт — чтобы все картинки были по 5К". И начинается!... Сначала картинки выгрузи, причём так, чтобы не похерить их ID, затем отдай дизайнеру, он их ужмёт, отдаст тебе, ты ЗАНОВО импортируешь картинки в базу или того хуже — будешь создавать ещё одно поле теперь уже для ужатых картинок, да ещё согласовывать, чтобы ужатая как-то соотносилась с неужатой... ой ё! B>Т.е. буквально на ровном месте огребаешь кучу проблем (+ проблемы, которые я описал для vaa). Оно тебе надо?
Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял?
Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы?
B>Я почему так говорю — тоже как вы по-молодости вляпывался во всякие "инновации от M$". И повозившись с нехреновой такой "базой с картинками", плюнул и сделал всё на внешних файлах. В результате база — маленькая, легко и БЫСТРО бэкапится/сжимается, модифицировать её — вообще без проблем (хоть каждый день пересоздавай!), а файлы организовал независимым способом: каждый файл именуется GUID'ом, а затем применяется "партишенинг": первые две буквы имени являются именем подкаталога (от единого корневого), где файлы и лежат:
Тут появляются инфраструктурные проблемы как состояние базы синхронизировать с состоянием base_pic_dir.
B>Т.е. имеем распределённую систему файлов, чтобы не хранить миллиард фоток в одном каталоге. B>Итого, чтобы мне перенести такую хренову тучу файлов в развёртываемую систему, мне достаточно из сархивировать и скопировать! Причём на любой носитель (не засирая системный с БД). Ну а в базе храним только имена конечных файлов, которые опять же легко переносятся, дополняются и т.п.
Недостаточно. А в БД можно _если надо_ настраивать чтобы табличка с файлами была на другом носителе.
В общем, конечно же, можно сделать всё своё, но это, повторюсь зависит от задачи и требований. Вполне может быть условия, что простая табличка в субд будет достаточным решением. Если что — легко поменять потом. Правда тут топикстатрер заговорил о терабайтах, это конечно да, не надо такое в бд пихать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vaa, Вы писали:
vaa>Где предпочитаете хранить файлы (pdf, pic, binary): vaa>4 на диске(отдельно от бд).
Естественно файлы нужно хранить там где это давно предусмотренно — в файловой системе. Бекапы, антивирусы, оптимизация размещения (все есть для файлов, а для БД скорее проблемно) да и доступ будет быстрее чем в бд прочитать таблички а далее читать раздробленные файлы самой бд размазанные на диске.
Здравствуйте, ·, Вы писали:
·>Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо.
Я и предлагаю СРАЗУ обойти грабли, чтобы потом, когда навалится тонна задач, не бегать и жевать сопли "а я не знал, что база будет большая!". Профи должен чувствовать проблемы интуитивно.
B>>ТЕМ БОЛЕЕ картинки!
·>Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял? ·>Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы?
Ты нагородил непонятную кучу проблем. Суть решения в том, что файл остаётся файлом. С соотв. удобствами по его нативной обработке: картинки — фотошопить, доки — конвертить, музыку — ужимать и т.п. А уж расшаривать папочку или копировать... ты серьёзно обсуждаешь эту чушь??
·>Тут появляются инфраструктурные проблемы как состояние базы синхронизировать с состоянием base_pic_dir.
Вообще никаких проблем. Файлы как были, так и остаются. База живёт отдельно и "знает" свои файлы.
·>В общем, конечно же, можно сделать всё своё, но это, повторюсь зависит от задачи и требований
Почти не зависит. Файл есть файл, в БД ему делать нечего. Абстрактный blob, о котором знает только апп.сервер — да, можно хранить. Всё остальное лучше внешне.
Здравствуйте, Baiker, Вы писали:
B>·>Ну так это рефакторится же. Выгрузить картинки из базы в фс — небольшой таск на рефакторинг. Который надо делать только если надо. B>Я и предлагаю СРАЗУ обойти грабли, чтобы потом, когда навалится тонна задач, не бегать и жевать сопли "а я не знал, что база будет большая!". Профи должен чувствовать проблемы интуитивно.
Так ведь история повторяется: "нагородил непонятную кучу проблем". Ты эти проблемы вообще не понимаешь и не чувствуешь. Потерять-поломать файлы — как нефиг делать, субд же заставляет за целостностью следить. Ну будет у тебя в базе uuid, а файл пропал или поменялся на что-то другое.
Да банально изменение файла сделать транзакционным — уже надо действовать с осторожностью. А ещё конкурентный доступ, локи, етс.
А с блобом у тебя полный acid из коробки.
B>·>Не понял чем это будет проще в случае "/base_pic_dir/"? Расшаришь папочку для дизайнера на проде? Чтобы он там сразу менял? B>·>Или копировать туда-сюда будешь? А как потом мержить то, что наменял в течение недели дизайнер и что изменилось на проде? А ещё DR и горячие бэкапы? B>Ты нагородил непонятную кучу проблем. Суть решения в том, что файл остаётся файлом. С соотв. удобствами по его нативной обработке: картинки — фотошопить, доки — конвертить, музыку — ужимать и т.п. А уж расшаривать папочку или копировать... ты серьёзно обсуждаешь эту чушь??
Серьёзно. Ибо эти файлы не просто так файлы, а связаны неявно с сущностями в бд. И у тебя не просто файлы, а файлы доступные из аппа и связанные с определённой бизнес-логикой.
B>·>В общем, конечно же, можно сделать всё своё, но это, повторюсь зависит от задачи и требований B>Почти не зависит. Файл есть файл, в БД ему делать нечего. Абстрактный blob, о котором знает только апп.сервер — да, можно хранить. Всё остальное лучше внешне.
Чем абстрактный блоб принципиально от файла отличается?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, _ilya_, Вы писали:
__>Здравствуйте, vaa, Вы писали:
vaa>>Где предпочитаете хранить файлы (pdf, pic, binary): vaa>>4 на диске(отдельно от бд).
__>Естественно файлы нужно хранить там где это давно предусмотренно — в файловой системе. Бекапы, антивирусы, оптимизация размещения (все есть для файлов, а для БД скорее проблемно) да и доступ будет быстрее чем в бд прочитать таблички а далее читать раздробленные файлы самой бд размазанные на диске.
не знаю как в постгрес, а мсскуэль именно там и представлен файлстрим — как сетевой каталог(есть возможность расшарить). на нем можно файлы смотреть и даже наверно изменять, но при этом гарантируется целостность и транзакционность.
Здравствуйте, Baiker, Вы писали:
B> распухла до размеров гигабайта
Честно говоря, не понял размера проблемы. Я работал с БД MSSQL 500ГБ (1с торговля). не знаю хранилилсь ли в ней файлы, но это нормальные размеры для базы.
и бэкапилось все это и хранилось 7(или 30 не помню)д 12м 1г. на бэкап кстати уходило не так много времени. около получаса. + логи каждые 15 минут.
Здравствуйте, vaa, Вы писали:
vaa>и бэкапилось все это и хранилось 7(или 30 не помню)д 12м 1г. на бэкап кстати уходило не так много времени. около получаса. + логи каждые 15 минут.
vaa>тут пишут что это антипаттерн(хранить вне субд) vaa>https://github.com/boralp/sql-anti-patterns
Это просто рекомендация хранить всё в блобах что бы получить все бенефиты от бд. Очевидно, что невозможно свести любой кейс к блобам. Например, что бы конский блоб отдать для download, надо прокачать его через бд, сервер приложения и всех посредников по пути к нему.
А можно и отдать мимо всего этого при помощи специализированого стораджа типа S3. В этом случае нужно правильно организовать доступ к S3, решить вопрос с синхронизацией состояния.
До кучи, блоб не получится просто так разместить в какой то другой зоне. А вот CDN — запросто.
Здравствуйте, vaa, Вы писали:
vaa>·>Если стоит вопрос предпочтения, то предпочту уже то, что уже есть в системе. Если есть субд, то пункт 1 — добавить табличку — легко и просто. Из коробки будут та же система развёртывания, миграции, бэкапов, етс для всей системы. vaa>·>К следующим пунктам я бы переходил если пункт 1 не тянет по перформансу. И тут уже нужен аккуратный анализ требований и выбор решения, которое их удовлетворяет. vaa>мне вот тоже кажется таблица это оптимально, правда касательно объемов тут задумался, vaa> в постгрес 35Тбайт на таблицу. т.е. около 35_000 гигов. не так уже и много, если задуматься. vaa>т.е. по 10Мб примерно 3,5 млн записей.
Я бы наверное смотрел на соотношение размера данных к файлам.
Если в бд 1G данных и 100T файлов — то явно лучше файлы хранить отдельно, где-нибудь в облаке.
Если в бд 1T данных и 1T файлов, то зачем лишний раз заморачиваться.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Baiker, Вы писали:
B>Sharov>Почему нет, если, например, небольшие файлы 5-10мб типа картинок? B>ТЕМ БОЛЕЕ картинки! (к примеру, картинки товаров) Сегодня ты наструячил мегабайтных 3Д картинок, а завтра манагер подходит: "Нам нужен мобильный вебсайт — чтобы все картинки были по 5К". И начинается!... Сначала картинки выгрузи, причём так, чтобы не похерить их ID, затем отдай дизайнеру, он их ужмёт, отдаст тебе, ты ЗАНОВО импортируешь картинки в базу или того хуже — будешь создавать ещё одно поле теперь уже для ужатых картинок, да ещё согласовывать, чтобы ужатая как-то соотносилась с неужатой... ой ё! B>Т.е. буквально на ровном месте огребаешь кучу проблем (+ проблемы, которые я описал для vaa). Оно тебе надо?
Все это хорошо, но как быть с консистентностью и\или транзакционностью? Если кто-то случайно куда-то дел
файлы в фс, то база об этом не будет знать, а когда блобы в бд, то это "случайно" просто так не сделаешь.
Я сам хранил файлы во вне, а в бд хранил метаданные. Но вот как-то такой дизайн, когда за одни и те же
сущности (файл+метаданные) отвечают 2 разных, несогласованных механизма -- бд и фс. Ну вот как-то
не спокойно от такой организации. А вот когда все в базе -- уже спокойнее, уже один механизм взаимодействия
для всего.
Здравствуйте, vaa, Вы писали:
vaa> Обычное CRUD-приложение с бизнес-логикой. БД типа постгрес, мс скл, файрберд. vaa> Где предпочитаете хранить файлы (pdf, pic, binary):
В сколь-либо нагруженном приложении файлы всегда хранятся отдельно от БД (в S3 например, краевой случай внутреннего устройства S3-подобных систем оставим за скобками). Во всех остальных случаях без разницы (как удобнее) — цена неправильного решения очень низкая, всегда можно относительно быстро переделать.
Здравствуйте, Sharov, Вы писали:
S>Все это хорошо, но как быть с консистентностью и\или транзакционностью? Если кто-то случайно...
Это называется "высасывать из хера проблемы". В большинстве случаев если ты хранишь файл — всё, это конечная, "запечатаная" сущность. Её не надо изменять, максимум — удалить полностью из системы (из базы и диска). Ну а проблемы "файл куда-то делся" — извини, ИТ — это тебе не женская сумочка, тут порядок нужен!
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Baiker, Вы писали:
B>> распухла до размеров гигабайта
vaa>Честно говоря, не понял размера проблемы
Если ты из Эстонии — то да, сложно объяснить челу, что ждать полчаса бэкап — это долго!
vaa>тут пишут что это антипаттерн(хранить вне субд) vaa>https://github.com/boralp/sql-anti-patterns
Ну а у меня на заборе ***й написано — а там дрова лежат! (ц) Дальше будем обсуждать непонятные источники?
B>Если ты из Эстонии — то да, сложно объяснить челу, что ждать полчаса бэкап — это долго!
Без шуток, складывается впечатление что наличие консистентной копии базы вместе с файлами для вас не важно.
Ну и без файлов не у всех же базы игрушечные.))
Здравствуйте, ·, Вы писали:
·>Чем абстрактный блоб принципиально от файла отличается?
Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
случай, с PDF-файлами размером > 4Гб. Плюс к этому распухание журнала транзакций (надо же как-то ACID обеспечивать) и распухание самой БД, которую становится проблематично бэкапировать.
Например, БД представлена сотней таблиц, некоторые таблицы содержат около 10-100 млн записей, всё это хозяйство занимает около 200 Гб, что позволяет с необходимой частотой делать бэкапы, реплики и многое другое, чего например проблематично делать с хранилищем файлов, которое занимает под сотню терабайт.
Здравствуйте, 4058, Вы писали:
4>·>Чем абстрактный блоб принципиально от файла отличается? 4>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
случай, с
Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
4>PDF-файлами размером > 4Гб. Плюс к этому распухание журнала транзакций (надо же как-то ACID обеспечивать) и распухание самой БД, которую становится проблематично бэкапировать.
Прикольный случай, конечно. А что потом с этим файлом делать? Чую, что его и в pdf-reader открыть будет проблематично... не говоря уж о том, что прочитать никто не сможет столько.
4>Например, БД представлена сотней таблиц, некоторые таблицы содержат около 10-100 млн записей, всё это хозяйство занимает около 200 Гб, что позволяет с необходимой частотой делать бэкапы, реплики и многое другое, чего например проблематично делать с хранилищем файлов, которое занимает под сотню терабайт.
Да, я уже где-то выше написал, адекватность решения зависит от соотношения размеров данных и файлов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Здесь транзакционные ФС в помощь, либо специализированные хранилища (S3), либо движки на уровне самих БД (например FILESTREAM в MSSQL, но там свои ограничения) ну или по простому, в рамках транзакции БД делать изменения в БД и ФС.
4>>PDF-файлами размером > 4Гб. Плюс к этому распухание журнала транзакций (надо же как-то ACID обеспечивать) и распухание самой БД, которую становится проблематично бэкапировать. ·>Прикольный случай, конечно. А что потом с этим файлом делать? Чую, что его и в pdf-reader открыть будет проблематично...
Как раз у reader-ов проблем с этим нет, т.к. pdf изначально расчитан на поточную обработку, в общем в память сразу весь документ не потянет, проблема только с трансфером.
·>не говоря уж о том, что прочитать никто не сможет столько.
История приблизительно такая, суд запросил материалы для проведения экспертизы, контора у которой это запрашивали является крупным ритейлером, в частности от них требовалось приложить какие-то древние каталоги всей продукции, исходников (каталогов) видимо не сохранилось, в итоге они отсканировали эти 10-ки тысяч страниц и запихнули в один pdf-файл.
·>Да, я уже где-то выше написал, адекватность решения зависит от соотношения размеров данных и файлов.
Я тоже собственно с этого и начал, т.к. совсем универсального решения нет.
Здравствуйте, 4058, Вы писали:
4>·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает. 4>Здесь транзакционные ФС в помощь, либо специализированные хранилища (S3), либо движки на уровне самих БД (например FILESTREAM в MSSQL, но там свои ограничения) ну или по простому, в рамках транзакции БД делать изменения в БД и ФС.
Угу. С чем боролись, на то и напоролись: "неудобно и ресурсозатратно работать". Т.е. закат солнца вручную. Впрочем, если по задаче сразу ясно, что acid для файлов не нужен, то может и пойдёт.
4>>>PDF-файлами размером > 4Гб. Плюс к этому распухание журнала транзакций (надо же как-то ACID обеспечивать) и распухание самой БД, которую становится проблематично бэкапировать. 4>·>Прикольный случай, конечно. А что потом с этим файлом делать? Чую, что его и в pdf-reader открыть будет проблематично... 4>Как раз у reader-ов проблем с этим нет, т.к. pdf изначально расчитан на поточную обработку, в общем в память сразу весь документ не потянет, проблема только с трансфером.
Ну откроет документ, а как там что-то найти почитать? Придётся по нему как-то туда-сюда прыгать и начнутся тормоза.
4>·>не говоря уж о том, что прочитать никто не сможет столько. 4>История приблизительно такая, суд запросил материалы для проведения экспертизы, контора у которой это запрашивали является крупным ритейлером, в частности от них требовалось приложить какие-то древние каталоги всей продукции, исходников (каталогов) видимо не сохранилось, в итоге они отсканировали эти 10-ки тысяч страниц и запихнули в один pdf-файл.
Т.е. по сути это ошибка в UX проектировании, когда система позволила загрузить в себя такое. По уму они должны были поделить это на вменяемые юзабельные куски, и каждый кусок как-то аннотировать — какой каталог какой продукции и т.п.
Что теперь делать с этим pdf — неясно, прям саботаж какой-то делопроизводства.
4>·>Да, я уже где-то выше написал, адекватность решения зависит от соотношения размеров данных и файлов. 4>Я тоже собственно с этого и начал, т.к. совсем универсального решения нет.
Ну да. А мой поинт был в том, что если задача на данный момент толком неясна, то начать нужно с простого и надёжного — с блобов. А потом отрефакторить, если что.
Здравствуйте, 4058, Вы писали:
4>Из практики, порой приходилось сталкиваться с PDF-ками на 20К страниц, объёмом в несколько гигабайт , это был ответ на запрос суда с полным перечнем запрашиваемых данных для проведения судебной экспертизы.
Сразу представились требования к системе в стиле "ну и ещё нужно чтобы корректно работало с приложенными файлами, как правило это будут PDF документы", а по факту прилетает такое вот 20К чудо )) Как оно вообще, хоть каким-то софтом без глюков вообще открывалось на просмотр?
Здравствуйте, Firstborn, Вы писали:
F>Здравствуйте, 4058, Вы писали:
4>>Из практики, порой приходилось сталкиваться с PDF-ками на 20К страниц, объёмом в несколько гигабайт , это был ответ на запрос суда с полным перечнем запрашиваемых данных для проведения судебной экспертизы. F>Сразу представились требования к системе в стиле "ну и ещё нужно чтобы корректно работало с приложенными файлами, как правило это будут PDF документы", а по факту прилетает такое вот 20К чудо ))
Когда разрабатывали систему (в 2010-м) на подобные вещи особо не закладывались, и это мягко скажем "редкий случай", сейчас специально проверил, на массиве из 5 млн pdf-документов (накопленных за 12+ лет), всего 600 имеют более 1К страниц, и всего 10 более 10К. Но в данном случае дело не в кол-ве страниц (для pdf это не проблема), а в размере файла, т.к. в данном случае pdf выступил в виде контейнера для отсканированных материалов (массив jpeg-ов в 300DPIx24bit). Грубо говоря 20К страниц * 200 кб (средний размер скана) ~ 4 Гб. Сейчас специально проверил, на данный момент самый "тяжелый" случай это: 19К страниц общим объемом 6.5 Гб.
F>Как оно вообще, хоть каким-то софтом без глюков вообще открывалось на просмотр?
Как раз с этим проблем нет, условный Adobe Reader не тянет же его полностью в оперативку. Только что проверил, с шары открылся за 30 секунд, оперативки скушал около 80 мб, с навигацией по страницам проблемы нет.
Но самое интересное не это, в системе имеется процесс, осуществляющий над всем этим безобразием OCR (с использованием джижка ABBYY FineReader), собственно так я и узнал, что у нас бывают подобные "документы", когда обработка одного такого документа заняла заметно больше ожидаемого времени.
Здравствуйте, Baiker, Вы писали:
B>>> распухла до размеров гигабайта
vaa>>Честно говоря, не понял размера проблемы
B>Если ты из Эстонии — то да, сложно объяснить челу, что ждать полчаса бэкап — это долго!
Полчаса на бэкап гигабайта? Это, наверное, эстонский компьютер?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Baiker, Вы писали:
B>Это называется "высасывать из хера проблемы". В большинстве случаев если ты хранишь файл — всё, это конечная, "запечатаная" сущность. Её не надо изменять, максимум — удалить полностью из системы (из базы и диска).
Выделенное надо делать транзакционно. Как и добавление. И весь механизм таких транзакций придется обеспечивать врукопашную.
B>Ну а проблемы "файл куда-то делся" — извини, ИТ — это тебе не женская сумочка, тут порядок нужен!
Это может произойти как раз на этапе добавления-удаления. Запись в базе изменилась, а файл не успел, или наоборот. Добавить сюда конкурентные операции, и все станет еще веселее.
А еще надо делать согласованные бэкапы БД и файлов. И как ты будешь их делать я вообще плохо представляю, вряд ли для этого есть какие-то готовые средства.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, ·, Вы писали:
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Все так, но есть один нюанс — стоимость хранения в SaaS DB может быть на порядок выше стоимости хранения в каком нибудь Azure Storage/AWS S3. Стоит ли ACID и удобство этих денег — очень большой вопрос.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает. НС>Все так, но есть один нюанс — стоимость хранения в SaaS DB может быть на порядок выше стоимости хранения в каком нибудь Azure Storage/AWS S3. Стоит ли ACID и удобство этих денег — очень большой вопрос.
Беда в том, что этот вопрос иногда даже не ставится, т.к. проблемы не осознаются (см. "нагородил непонятную кучу проблем" выше по топику). И эти сэкономленные деньги потом ВНЕЗАПНО придётся потратить десятикратно, когда что-то потеряется или поломается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Baiker, Вы писали:
B>>Если ты из Эстонии — то да, сложно объяснить челу, что ждать полчаса бэкап — это долго!
vaa>Без шуток, складывается впечатление что наличие консистентной копии базы вместе с файлами для вас не важно. vaa>Ну и без файлов не у всех же базы игрушечные.))
Складывается впечатление, что ты наступил в говно, но пытаешься тут стоять "весь в белом". Ты спросил про базы — тебе ответили. Если ты не понимаешь причин и пытаешься продавливать своё явно дилетантское мнение (да ещё прибегая к паршивой демагогии, разговаривая ВМЕСТО собеседника) — просто вали нахер, твоё самовозвышение интересно только тебе самому.
Здравствуйте, ·, Вы писали:
·>Здравствуйте, 4058, Вы писали:
4>>·>Чем абстрактный блоб принципиально от файла отличается? 4>>Тем, что неудобно и ресурсозатратно работать с "большими" блобами, в зависимости от ограничений конкретной БД на размер LOB и возможностей LOB-стримминга. Я ранее упоминал
случай, с
·>Если ты делаешь на файлах, у тебя рано или поздно возникнут те же вопросы и с целостностью, и с бэкапами, и с DR, &c. Ну будешь эту же ACID обеспечивать вручную, сравнимым по затратам ресурсов способом, магически оно само не заработает.
Ещё раз для тех, кто только похмелился и не полностью въехал в тему (или проигнорировал её самую интересную часть):
КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
Соответственно, всё, что требуется от такого хранилища — иметь надёжный бэкап. Более того — иногда можно даже допустить его потерю (те же ушлёпские ролики тиктока).
Отсюда и мой совет выше: НЕ ХРАНИТЬ ФАЙЛЫ В БАЗЕ! Это (хранение в базе) — глупое решение, плачевные последствия которого приходят слишком поздно, чтобы что-то менять.
Здравствуйте, Baiker, Вы писали:
B>КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.
Но обработанные файлы — это уже новые сущности, которые не заменяют старые. Т.е. есть исходный файл, он лежит в s3 и имеет версию 1, а в базе эти id и версия привязаны к какой-то сущности (или только id без версии, если нужна самая последняя). Дизайнер ужимает файл, заливает его в s3 и появляется версия 2. Если нужна самая последняя версия, то в базе вообще ничего не меняется, т.к. у файла не поменялся id. Если бизнес-логика требует версионирования, то апается версия в соответствии с залитым файлом. При необходимости асинхронно работает сборщик мусора (ибо операция удаления обычно дорогая и бывает дешевле вообще никогда не удалять данные).
Т.е. проблемы с поддержанием целостности тут особо не стоит — файлы иммутабельны, метаинформация о них в базе иммутабельна, работать будет на любой базе.
Здравствуйте, Anton Batenev, Вы писали:
AB>·> У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны. AB>Но обработанные файлы — это уже новые сущности, которые не заменяют старые. Т.е. есть исходный файл, он лежит в s3 и имеет версию 1, а в базе эти id и версия привязаны к какой-то сущности (или только id без версии, если нужна самая последняя). Дизайнер ужимает файл, заливает его в s3 и появляется версия 2.
Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой?
AB>Если нужна самая последняя версия, то в базе вообще ничего не меняется, т.к. у файла не поменялся id. Если бизнес-логика требует версионирования, то апается версия в соответствии с залитым файлом. При необходимости асинхронно работает сборщик мусора (ибо операция удаления обычно дорогая и бывает дешевле вообще никогда не удалять данные).
Молодец, ты изобрёл MVCC.
AB>Т.е. проблемы с поддержанием целостности тут особо не стоит — файлы иммутабельны, метаинформация о них в базе иммутабельна, работать будет на любой базе.
Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой?
Ну он же в любом случае заливает новый файл через какую-то админку / веб-интерфейс и т.д. (ибо авторизация, история, аудит и вот это все) — это не должно быть головной болью дизайнера, его задача дизайнить. А уж админка / интерфейс сами справятся с базой.
·> Молодец, ты изобрёл MVCC.
Да как бы этому подходу сто лет как, не я его "изобретатель".
·> Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того.
Я вроде явно про uuid не писал, но в качестве идентификатора ты можешь использовать что тебе удобно (twitter вон изобрел snowflake). Правда если ты будешь использовать хэш от содержимого файла (особенно семейство sha), то это будет крайне медленно.
Здравствуйте, Anton Batenev, Вы писали:
AB>·> Как теперь дизайнер будет объяснять базе, что у файла появилась новая версия и как её связать со старой? AB>Ну он же в любом случае заливает новый файл через какую-то админку / веб-интерфейс и т.д. (ибо авторизация, история, аудит и вот это все) — это не должно быть головной болью дизайнера, его задача дизайнить. А уж админка / интерфейс сами справятся с базой.
Я об этом и говорил, что файлы тут ничем не помогут. Всё равно будет админка и коннект к базе. Файлы тут будут лишь усложнением, которое должно быть оправданным.
AB>·> Молодец, ты изобрёл MVCC. AB>Да как бы этому подходу сто лет как, не я его "изобретатель".
Это я к тому, что в случае использования субд это у тебя уже будет всё готовое, оттестированное и отлаженное. В случае самопальной реализации можно ВНЕЗАПНО наткнуться на множество граблей.
AB>·> Если иммутабельны, то и по uuid их идентифицировать не нужно, лучше sha2 использовать или типа того. AB>Я вроде явно про uuid не писал, но в качестве идентификатора ты можешь использовать что тебе удобно (twitter вон изобрел snowflake). Правда если ты будешь использовать хэш от содержимого файла (особенно семейство sha), то это будет крайне медленно.
snowflake это для генерации уникальных id, а я говорю про использование Content-addressable storage, чтобы содержимое файла определяло его id.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Baiker, Вы писали:
B>>КАК ПРАВИЛО "файлы в базе" не являются такими же "данными", как и записи. Файл — это некая одноразовая/readonly сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет. ·>У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.
Ты сейчас такую тупость спорол, что интернет завял!
"Меняют" — ЧЕРЕЗ МЕХАНИЗМ ПРИЛОЖЕНИЯ, что тут неясного-то?? Т.е. если я из "морды к базе" залил фотку сотрудника, ОЧЕВИДНО я не буду этот файл менять — он просто readonly хрень для показа. А вот если босс скажет, что эти же самые фотки занимают много места, тогда конечно же я их отдам (из файловой системы, дурачок!) простым зипом дизайнеру, он их ужмёт, а потом я точно так же разверну эти файлы на старое место — "морда к базе" даже не заметит изменений! (и СУБД тоже) Вот в чём главный профит. Файлы живут как бы сбоку и МАКСИМАЛЬНО ГИБКО обрабатываются утилитами (если нужно).
Здравствуйте, Anton Batenev, Вы писали:
AB>Но обработанные файлы — это уже новые сущности, которые не заменяют старые
Нет, я как раз топлю за случай, когда НАДО менять файлы. Базе ничего не будет, как был на диске 1.jpg — так и останется. Просто файлы вне базы имеют куда большую гибкость, чем идиотские блобы, бэкапящиеся в терабайтный razderi_menja_jakor'.bak
, это был ответ на запрос суда с полным перечнем запрашиваемых данных для проведения судебной экспертизы.
Т.е. если я из "морды к базе" залил фотку сотрудника, ОЧЕВИДНО я не буду этот файл менять — он просто readonly хрень для показа. А вот если босс скажет, что эти же самые фотки занимают много места, тогда конечно же я их отдам (из файловой системы, дурачок!) простым зипом дизайнеру, он их ужмёт, а потом я точно так же разверну эти файлы на старое место — "морда к базе" даже не заметит изменений! (и СУБД тоже) Вот в чём главный профит. Файлы живут как бы сбоку и МАКСИМАЛЬНО ГИБКО обрабатываются утилитами (если нужно).
