Для розжига, как ни странно, очень подходят обертки от батончиков РотФронт :)
Они промасленные и очень хорошо горят и не мокнут. Да и тащить лишнего не надо — конфету съел, бумажку в карман.
В разных случаях по-разному, где-то хранятся атрибуты, где-то нет. Если это просто оригинальное объявление о продаже недвижимости — то оно всегда html, никаких атрибутов, но зато есть оно же разобранном виде, и это разобранное уже лежит в базе, причем не в одной. В других случаях хранится мета-инфа: размер картинки, тип данных внутри, оригинальное название…
Согласно указанной Вами статье, «большинство систем будут проседать при нагрузке/соотношении в районе 2.»
Но я исходил из нашего опыта на наших машинах, и в районе 2х более-менее, обычно меньше, 5-6 — это усердное копирование файлов, требует мониторинга админа, ибо чревато скачком, а при 8 уже клиенты ругаются.
Мы поэкспериментировали с прозрачным сжатием на zfs: на SSD положили mysql базу. Пока радуемся жизни, все стало в разы быстрее, чем на обычных HDD, и при это влезло на SSD (размер базы сейчас порядка 1.3 Тб). С файлстораджем так не экспериментировали, но почему бы и нет.
Мы не очень доверяем lsyncd. Вцелом такую схему мы используем для бэкапа, так что в нашем конкретном случае не критично, если один файлик потеряется по пути. Периодически раз в день делаем полный rsync.
Мы не проводили бенчмарки на максимальный размер файла, у нас файлы складываются поминутно в каталог, и этот каталог жмется в архив, примерно по 1000 файлов в архиве, 25-30 мегабайт архив получается. Каких-то затруднений не испытывали, но опять же тут зависит от Вашей схемы использования, сколько вам надо отдавать в единицу времени, размер самих файлов и кучи других параметров. На Вашем месте я бы попробовал разные варианты, померял скорость и потом уже решал, что и как именно использовать.
tar не хранит каталог файлов в каком-то отдельном выделенном месте, у него вообще нет этой структуры, в tar есть информация об одном файле, потом сам файл, потом опять информация, потом файл, т.е. эта информация размазана по всему архивному файлу, и ее нельзя получить разово. В этом и есть проблема.
Я могу ошибаться, но даже если в каталоге файлов много, а нам нужно отслеживать создание — то достаточно мониторить сам каталог, а не все файлы в нем. В нашем кейсе файл создается и больше никогда не меняется, поэтому отслеживать изменения самих файлов не нужно. Если же мониторить все файлы — то это явно не то решение, которое подойдет в данном случае.
Зависит от конкретной ситуации. Когда система с файлами уже есть, то намного проще перепаковать в zip, чем городить абсолютно новую систему с базой. В каких-то случаях база вполне оправдана, особенно если решение проектируется с нуля.
Соглашусь, я сам пробовал больше 4096 и была проблема, и решил, что должно быть ровно 4096, а на самом деле должно быть меньше, но не обязательно ровно. Но 1024 и 2048 не выставлял :)
Мы на файловом хранилище решали очень просто: много мелких файлов клали в zip-архив. Кроме inodes выиграли «случайно» еще несколько сотен гигов места (при упаковке «без сжатия»).
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
Дело же не в наличии или отсутствии гида и не в том, коммерческий это альпинизм или спортивный, а в том, чтобы достигнуть цели, залезть на эту гору, замотивировать себя на что-то большее, чем условное «лежание у телевизора». Погода и гора не зависят от денег, надо в любом случае напрягаться, потеть, мокнуть под дождем, мерзнуть в снегу, рисковать здоровьем — в реальности очень небольшой процент людей на это готовы пойти и пожертвовать своим комфортом. В разработке то же самое: если дают вовремя зарплату на неинтересной работе, не все готовы идти на риск ради интересной работы, где надо авралить, иногда писать код ночами, потеть над релизом, а когда заказчику не понравится — получать за это еще и по голове.
Ну и я категорически не соглашусь с формулировкой «10 человек могут чудом, за деньги, без подготовки, взойти на довольно высокую гору». Это не чудо, это работа, тяжелая работа, и подготовка, и никакие деньги тут не решат, готов человек физически или нет, готов он морально или нет. Вообще, чтоб с одного разряда на другой переходить — нужно пахать, а чтоб с нуля залезть на гору — не надо? Еще больше надо. Потому что это не уже привычные горы, а вообще выход из зоны комфорта, это не то что непривычно — это страшно.
Раз уж так совпало, что мне через неделю в горы (наш Кавказ), вдруг кто порекомендует страховую риском "альпинизм", но которая реально покроет вертолет и т.п. Сколько ни читал отзывов — то там отказали, то там.
Вот тоже вопрос что чем клеить возник — не машинку правда, а палатку с силиконовым покрытием — порвалась. Может кто посоветовать, чем эти силиконизированные ткани клеить? Всякий клей типа «Момент» отвалился после первого же дождичка.
Они промасленные и очень хорошо горят и не мокнут. Да и тащить лишнего не надо — конфету съел, бумажку в карман.
Но я исходил из нашего опыта на наших машинах, и в районе 2х более-менее, обычно меньше, 5-6 — это усердное копирование файлов, требует мониторинга админа, ибо чревато скачком, а при 8 уже клиенты ругаются.
habr.com/ru/company/srg/blog/462967
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
Ну и я категорически не соглашусь с формулировкой «10 человек могут чудом, за деньги, без подготовки, взойти на довольно высокую гору». Это не чудо, это работа, тяжелая работа, и подготовка, и никакие деньги тут не решат, готов человек физически или нет, готов он морально или нет. Вообще, чтоб с одного разряда на другой переходить — нужно пахать, а чтоб с нуля залезть на гору — не надо? Еще больше надо. Потому что это не уже привычные горы, а вообще выход из зоны комфорта, это не то что непривычно — это страшно.
Раз уж так совпало, что мне через неделю в горы (наш Кавказ), вдруг кто порекомендует страховую риском "альпинизм", но которая реально покроет вертолет и т.п. Сколько ни читал отзывов — то там отказали, то там.