https://www.opennet.dev/openforum/vsluhforumID3/119539.html Доступен первый выпуск wZD 1.0.0 - сервера для эффективного хранения большого числа файлов в компактном виде, который снаружи выглядит как обычный WebDAV-сервер. Для хранения используется модифицированная версия BoltDB. Код проекта написан на языке Go и распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52214<br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#51 Fri, 15 Jan 2021 14:33:25 GMT очень похоже на Grafana/Loki. Так же boltdb в качетсве хранения данных, только там хранят логи<br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#48 Thu, 23 Jan 2020 04:45:46 GMT Завез я уже поддержку HTTPS, Keepalive, авторизацию per vhost, включение отключение 404-ых, метод POST(только бинарные данные так же как и в PUT), метод OPTIONS, и еще по мелочи. Пока только в ветке мастер, если кому надо можете попробовать собрать потестировать, версия 1.1.0-beta собрана на гитхабе. Это еще не все что туда будет добавлено.<br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#47 Tue, 21 Jan 2020 14:37:02 GMT GOMAXPROCS автоматом ставится по количеству CPU начиная с версии Go 1.5 .<br>Как бы, если вы хотите на машине с 1-м ядром использовать этот сервер, врядли это нормально для такого решения, с миллионами файлов.<br><br><br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#46 Tue, 21 Jan 2020 14:20:38 GMT &gt;[оверквотинг удален]<br>&gt; была пара металоггеров. Теперь вернул естесственно обратно.<br>&gt; Я думаю MooseFS то не лопнет и на 500млн файлов, но при <br>&gt; условии что у вас будет порядка 30-50млн подпапкок, где файлов по <br>&gt; 10-1000 примерно, но все равно скорость то будет помедленнее. А вот <br>&gt; если у вас 500млн файлов и 1млн подпапок всего, тогда это <br>&gt; все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями <br>&gt; в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок <br>&gt; и больше файлов, тем больше сами массивы, тем хуже все работает. <br>&gt; Но я уже не рискнул бы доводить до таких объемов у себя, просто <br>&gt; потому что и запускается дольше и CRC долго чекает итп итд. <br><br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#45 Tue, 21 Jan 2020 14:12:53 GMT &gt; нет, мне было интересно именно для moose до переноса всего в архивы <br>&gt; - чтобы понимать, на каких масштабах оно таки лопается.<br>&gt; 250миллионов файликов = 75G оперативы, я правильно понял?<br>&gt; А что при этом происходило на металоггере, или вы ими не пользовались? <br><br>Да, все верно.<br><br>Изначально был, потом убрал, чтобы он диски SSD мне не убивал. Не вспомню как он работал, когда было 150млн файлов, но в память точно все помещалось. У меня по 128GB было на серверах, где была пара металоггеров. Теперь вернул естесственно обратно.<br><br>Я думаю MooseFS то не лопнет и на 500млн файлов, но при условии что у вас будет порядка 30-50млн подпапкок, где файлов по 10-1000 примерно, но все равно скорость то будет помедленнее. А вот если у вас 500млн файлов и 1млн подпапок всего, тогда это все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок и больше файлов, тем больше сами массивы, тем хуже все работает. Но я уже не рискнул бы доводить https://www.opennet.dev/openforum/vsluhforumID3/119539.html#44 Tue, 21 Jan 2020 13:49:42 GMT нет, мне было интересно именно для moose до переноса всего в архивы - чтобы понимать, на каких масштабах оно таки лопается.<br><br>250миллионов файликов = 75G оперативы, я правильно понял? <br>А что при этом происходило на металоггере, или вы ими не пользовались?<br><br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#43 Tue, 21 Jan 2020 13:36:26 GMT Принял. Спасибо за уточнение как вы делаете. Значит предусмотрю изменение TTL без перезаписи файлов. То есть не только вместе с файлом когда идет первоначальная заливка, но и потом чтобы можно было поменять TTL на другой или убрать TTL вовсе. Методом DELETE можно и внешним скриптом пользоваться как у Вас без поддержки встроенного TTL.<br><br>На счет задумываться - да ФС имеют такие проблемы при очень массовых операциях. У меня в теории не должно быть проблем, не фс все-таки, принцип то примерно тот же как в SeaWeedFS, просто если думать волюмамим, то у меня волюмов столько сколько папок по сути, в них еще быстрее удаление будет работать.<br><br>Я ни в коем случае не говорю Вам что мое чем-то лучше тоже, просто тема об одном, а уже Оракл сюда был приплетен. Да и я сомневаюсь что он нормально будет работать, там один индекс будет громадным, это надо тестировать сначала Оракл в таком ключе, а потом уже писать сюда, а то это просто предположение :)<br>P.S. Просмотрел, это не Вы написали про Оракл изначально, другие коммент https://www.opennet.dev/openforum/vsluhforumID3/119539.html#42 Tue, 21 Jan 2020 13:29:18 GMT &gt;&gt; Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?<br>&gt; И да, орацл умеет в кластеры ;-) <br>&gt; btw - сколько на самом деле жрет памяти на metadata и какого <br>&gt; объема логи на логсерверах, если не жалко?<br><br>В wZD? 32 байта, оно хранится прямо в файле который заливается, память не используется. Из которых 8 байт зарезервировано под будущий дистрибьютор. Логи тут не нужны.<br><br>Мне уже не нужно никакое решение, я уже все что надо сделал без любой бд.<br>В MooseFS на оставшиеся 10млн файлов после архивирования потребляется 8GB RAM всего с учетом директорий, а было 75GB+.<br> https://www.opennet.dev/openforum/vsluhforumID3/119539.html#41 Tue, 21 Jan 2020 13:22:36 GMT &gt; Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?<br><br>Ну, для меня решение из этой новости или всё тот же SeaWeedFS &#8212; тоже в определённом смысле СУБД. Так что база в этом смысле. Если что, я тут нигде не топил за ненужность сабжа, напротив, пишу о причинах по которым такие решения нужны и возникают.<br><br>&gt; Кто утверждает, что такое количество допустим должно быть обязательно в фс общего <br>&gt; назначения, про кластерные забыли?<br><br>Не суть, имелись в виду ФС, как бы так сказать, совместимые с POSIX-семантикой.<br>Которым противопоставляется специализированное решение, имеющее свои преимущества, в т.ч. за счёт отказа от всяких неиспользуемых функций.<br><br>&gt; Вам дали способ - как упростить себе жизнь не изменяя файловую систему <br>&gt; на какие-то решения, которые еще неизвестно как себя поведут (в плане фс <br>&gt; изначально), в том числе оставлена без изменений работа с большими файлами, <br>&gt; не надо заботится о волюмах, изменять пути в приложении, и прочие вещи.<br><br>Я же разве против? Наоборо