Мы не очень доверяем lsyncd. Вцелом такую схему мы используем для бэкапа, так что в нашем конкретном случае не критично, если один файлик потеряется по пути. Периодически раз в день делаем полный rsync.
Мы не проводили бенчмарки на максимальный размер файла, у нас файлы складываются поминутно в каталог, и этот каталог жмется в архив, примерно по 1000 файлов в архиве, 25-30 мегабайт архив получается. Каких-то затруднений не испытывали, но опять же тут зависит от Вашей схемы использования, сколько вам надо отдавать в единицу времени, размер самих файлов и кучи других параметров. На Вашем месте я бы попробовал разные варианты, померял скорость и потом уже решал, что и как именно использовать.
tar не хранит каталог файлов в каком-то отдельном выделенном месте, у него вообще нет этой структуры, в tar есть информация об одном файле, потом сам файл, потом опять информация, потом файл, т.е. эта информация размазана по всему архивному файлу, и ее нельзя получить разово. В этом и есть проблема.
Я могу ошибаться, но даже если в каталоге файлов много, а нам нужно отслеживать создание — то достаточно мониторить сам каталог, а не все файлы в нем. В нашем кейсе файл создается и больше никогда не меняется, поэтому отслеживать изменения самих файлов не нужно. Если же мониторить все файлы — то это явно не то решение, которое подойдет в данном случае.
Зависит от конкретной ситуации. Когда система с файлами уже есть, то намного проще перепаковать в zip, чем городить абсолютно новую систему с базой. В каких-то случаях база вполне оправдана, особенно если решение проектируется с нуля.
Соглашусь, я сам пробовал больше 4096 и была проблема, и решил, что должно быть ровно 4096, а на самом деле должно быть меньше, но не обязательно ровно. Но 1024 и 2048 не выставлял :)
Мы на файловом хранилище решали очень просто: много мелких файлов клали в zip-архив. Кроме inodes выиграли «случайно» еще несколько сотен гигов места (при упаковке «без сжатия»).
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
Дело же не в наличии или отсутствии гида и не в том, коммерческий это альпинизм или спортивный, а в том, чтобы достигнуть цели, залезть на эту гору, замотивировать себя на что-то большее, чем условное «лежание у телевизора». Погода и гора не зависят от денег, надо в любом случае напрягаться, потеть, мокнуть под дождем, мерзнуть в снегу, рисковать здоровьем — в реальности очень небольшой процент людей на это готовы пойти и пожертвовать своим комфортом. В разработке то же самое: если дают вовремя зарплату на неинтересной работе, не все готовы идти на риск ради интересной работы, где надо авралить, иногда писать код ночами, потеть над релизом, а когда заказчику не понравится — получать за это еще и по голове.
Ну и я категорически не соглашусь с формулировкой «10 человек могут чудом, за деньги, без подготовки, взойти на довольно высокую гору». Это не чудо, это работа, тяжелая работа, и подготовка, и никакие деньги тут не решат, готов человек физически или нет, готов он морально или нет. Вообще, чтоб с одного разряда на другой переходить — нужно пахать, а чтоб с нуля залезть на гору — не надо? Еще больше надо. Потому что это не уже привычные горы, а вообще выход из зоны комфорта, это не то что непривычно — это страшно.
Раз уж так совпало, что мне через неделю в горы (наш Кавказ), вдруг кто порекомендует страховую риском "альпинизм", но которая реально покроет вертолет и т.п. Сколько ни читал отзывов — то там отказали, то там.
Вот тоже вопрос что чем клеить возник — не машинку правда, а палатку с силиконовым покрытием — порвалась. Может кто посоветовать, чем эти силиконизированные ткани клеить? Всякий клей типа «Момент» отвалился после первого же дождичка.
Но если копать глубже, но я в статье как раз и озвучивал ситуацию про смену поколений, и поколение приходящих студентов, не зная прошлых наработок и не имея достаточно опыта, реализует деплой в виде простых скриптов или вообще вручную. Посмотрите на результаты опроса: деплой через FTP или самописными скриптами отнюдь не на последнем месте. Т.е. все делается, на самом деле, с минимумом усилий. И чтоб сделать качественный скачок — нужны мотивированные люди и опыт.
Вы много встречали джуниоров, которые грезят о будущем человечества? Сеньоры — да, от них стоит этого ожидать, но не от всех же. Поэтому и задачки по опыту даются, и стратегии разрабатываются соответствующими людьми.
Любой человек, а разработчик тем более, будет усиленно сопротивляться внедрению нового, если не увидит выгод для себя, а изучение нового — это в первый момент сильно затратно. Так что один из способов уменьшить сопротивление — показать радужные перспективы в будущем. Иногда надо просто дорасти до технологии.
Я не против критики, потому что только так и можно увидеть все стороны ситуации. И да, как автор, я смотрю на ситуацию субъективно исходя из своего опыта, чего и не скрываю, изначально понимая, что вариантов использования намного больше, чем я затронул.
И то, что я видел, что люди используют докер не потому, что он реально нужен, а потому что это нынче популярно — это реальный кейс, с которым пришлось столкнуться. Отнюдь не все так делают, конечно же нет, и мы сами используем докер, я хотел лишь подчеркнуть в статье два основных момента:
1. Докер надо использовать там, где он реально нужен, а не везде вообще
2. Не надо забывать про хорошие системы упаковки, про которые сейчас мало говорят, но они есть и успешно работают и не надо их бояться
So if your machine has 128 GB of RAM, run two nodes each with just under 32 GB. This means that less than 64 GB will be used for heaps, and more than 64 GB will be left over for Lucene.
habr.com/ru/company/srg/blog/462967
Да, поскольку файлы раздавал nginx, то пришлось к нему прикрутить модуль распаковки zip на лету.
Ну и я категорически не соглашусь с формулировкой «10 человек могут чудом, за деньги, без подготовки, взойти на довольно высокую гору». Это не чудо, это работа, тяжелая работа, и подготовка, и никакие деньги тут не решат, готов человек физически или нет, готов он морально или нет. Вообще, чтоб с одного разряда на другой переходить — нужно пахать, а чтоб с нуля залезть на гору — не надо? Еще больше надо. Потому что это не уже привычные горы, а вообще выход из зоны комфорта, это не то что непривычно — это страшно.
Раз уж так совпало, что мне через неделю в горы (наш Кавказ), вдруг кто порекомендует страховую риском "альпинизм", но которая реально покроет вертолет и т.п. Сколько ни читал отзывов — то там отказали, то там.
Очков Валерий Федорович, Хмелюк В. А.
1990 год
эквм.рф/biblioteka/cartochki/0003.htm
Но если копать глубже, но я в статье как раз и озвучивал ситуацию про смену поколений, и поколение приходящих студентов, не зная прошлых наработок и не имея достаточно опыта, реализует деплой в виде простых скриптов или вообще вручную. Посмотрите на результаты опроса: деплой через FTP или самописными скриптами отнюдь не на последнем месте. Т.е. все делается, на самом деле, с минимумом усилий. И чтоб сделать качественный скачок — нужны мотивированные люди и опыт.
И то, что я видел, что люди используют докер не потому, что он реально нужен, а потому что это нынче популярно — это реальный кейс, с которым пришлось столкнуться. Отнюдь не все так делают, конечно же нет, и мы сами используем докер, я хотел лишь подчеркнуть в статье два основных момента:
1. Докер надо использовать там, где он реально нужен, а не везде вообще
2. Не надо забывать про хорошие системы упаковки, про которые сейчас мало говорят, но они есть и успешно работают и не надо их бояться
www.elastic.co/guide/en/elasticsearch/guide/master/heap-sizing.html#_just_how_far_under_32gb_should_i_set_the_jvm
So if your machine has 128 GB of RAM, run two nodes each with just under 32 GB. This means that less than 64 GB will be used for heaps, and more than 64 GB will be left over for Lucene.