Здравствуйте, 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 сущность, которая живёт, пока её не затребуют. Каталог фильмов, музыки, фотки сотрудников, рентгены больных... никто такие вещи не меняет без веской причины. Запись — меняют, сам файл — нет.
У меня все ходы записаны: "отдай дизайнеру, он их ужмёт,". Так что проспись потом приходи и вырази свою мысль, если она есть, твои переобувания в прыжке мало кому интересны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
