Обычное 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 — запросто.
, это был ответ на запрос суда с полным перечнем запрашиваемых данных для проведения судебной экспертизы.
