Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Первый релиз wZD 1.0.0, сервера компактного хранения мелких ..."	+1 +/–
Сообщение от opennews (??), 19-Янв-20, 19:25
Доступен первый выпуск wZD 1.0.0 - сервера для эффективного хранения большого числа файлов в компактном виде, который снаружи  выглядит как обычный WebDAV-сервер. Для хранения используется модифицированная версия BoltDB. Код проекта написан на языке Go и распространяется под лицензией BSD... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52214
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 19-Янв-20, 19:25	+/–
Можно в него какой-нибудь архив freedb запихнуть? Там файлы меньше сектора на диске, какой прирост можно ожидать?
Ответить | Правка | Наверх | Cообщить модератору

2. Сообщение от kai3341 (ok), 19-Янв-20, 20:02	–2 +/–
> Многопоточность Любопытно, а зачем это здесь? Тут к месту была бы асинхронность
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6, #33

3. Сообщение от syslinux (ok), 19-Янв-20, 20:14	+3 +/–
Попробуйте, там суть в том, что в каждой папке появляется свой bolt архив. Нет смысла заливать 1 файлик размером 1KB в одну папку, надо хотябы 32 таких файлика, так как bolt создает всегда минимум 32KB файл. Нет смысла заливать 10 000 000 мелких файлов в 1 папку, чтобы не создать огромный bolt архив. Тогда должна получится экономия, например блок 4KB в файловой в файловой системе, загрузили 64 файла по 512B в 1 болт архив получим потребление не 64 * 4KB, а всего 32KB. А у кластерных ФС зачастую блок минимальный 32-64KB, там существенная разница будет, так что да сэкономить кроме inodes еще и место возможно. Но это в теории, там размер страницы еще 4KB влияет возможно. Оптимально 100-10000 файлов на одну папку или подпапку = на 1 болт архив, в зависимости от размера каждого загружаемого файла. Там табличка на гитхабе есть как оптимально использовать.
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от syslinux (ok), 19-Янв-20, 20:18	+/–
>> Многопоточность > Любопытно, а зачем это здесь? Тут к месту была бы асинхронность Оно на Go, там асинхронность то есть. В сам болт архив все равно писать можно только последовательно, если запись рассматривать. Но вот если писать в разные папки, тобишь в болт архивы то пишется паралелльно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

5. Сообщение от Аноним (5), 19-Янв-20, 20:20	–1 +/–
в общем, понятно - у них лопнула moosefs (совершенно не предназначенная для такой фигни, поскольку держит ВСЕ метаданные в оперативной памяти и по другому работать не может (код как бы есть, но как бы не алле) в результате они написали полуработающий архиватор, умеющий отдавать файлы из моднявого архива. Но поскольку - полу - ему все еще нужен внешний nginx для работы. Зато "проблема" выбора неадекватного софта для кластера - решена.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

6. Сообщение от Аноним (6), 19-Янв-20, 20:26	+/–
В зависимости от используемых стратегий синхронизации потоков, такой код априори асинхронен - потоки просто делают свои задачки и ничего не знаю друг о друге. Возможно тут имелась в виду JS-like асинхронность, где процессорное время одного потока квантуется и он прыгает по коллбэкам, но такой паттерн реализован во фреймворках практически любого популярного современного языка (C++/Java/C#, по крайней мере, точно). С одним лишь отличием, что делается пул из N долгоживущих потоков-воркеров (а не 1 на весь рантайм). А дальше уже как у всех - Future/Promise, либо async/await, если разрабы языка тоже посматривают на модные тенденции в плане улучшения читабельности асинхронного кода.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #34

7. Сообщение от ala (?), 19-Янв-20, 20:44	+1 +/–
Надо потестить, судя по опциям там таймауты то есть чтобы наружу ставить, но там нет авторизации по паролю или айпи, видимо авторы это имели ввиду, почему им nginx нужен. Где б еще столько файлов найти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

8. Сообщение от raver (ok), 19-Янв-20, 21:53	+8 +/–
А задумка-то у автора не плохая, взял и решил проблему кластерных фс как 2х2. Мелочь и большие файлы шустро будут работать, и амазон не нужен. Да ему не плохо было бы сделать авторизацию свою, хотя на старте я бы тоже предостерег всех и выпустил софт с рекомендацией ставить за nginx. Да и нечему ему торчать наружу, там же заливаются файлы. Было бы неплохо если бы автор добавил именно "клиентскую" компрессию и шифрование а не на стороне сервера, чтобы пользователь сам мог хоть на php сжать, зашифровать, притом чем угодно и послать данные и хеадеры с указанием того чем сжато, зашифровано итп. А обратно получать эти же хеадеры с инфой данными, чтобы логика клиента сразу могла узнать тип компрессии, шифрования и расшифровать. А то в его todo написано об этом, но не указано как именно он будет делать компрессию и шифрование. Было бы идеально, так как тогда на стороне сервера не будет хранится ни ключ ни пароль.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9

9. Сообщение от xm (ok), 19-Янв-20, 22:31	+1 +/–
> Было бы неплохо если бы автор добавил именно "клиентскую" компрессию Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и сама файловая система в хранилище? Пустое это.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от syslinux (ok), 19-Янв-20, 23:49	+/–
>> Было бы неплохо если бы автор добавил именно "клиентскую" компрессию > Зачем клиенту делать то, что из коробки делает HTTP/2 в канале и > сама файловая система в хранилище? Пустое это. Не в защите транспортного уровня дело, а чтобы предоставить такую возможность, хочешь сам зашифровал чем тебе надо конкретный файл или даже значение и отправил это в хранилище. Гибкость. Тем более на фс далеко не во всех есть шифрование, и оно там на стороне сервера только оверхед создаст. Клиент же не только curl обычный может быть, а и целое приложение типа CRM системы или еще что, которой потребуется ключи у себя держать а не на сервере хранения. Сервер лишь при выдаче зашифрованных данных отдаст сразу в заголовках тот тип шифрования который был применен к данному конкретному файлу или значению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от xm (ok), 20-Янв-20, 00:04	+1 +/–
Шифровать это один вопрос, а сжатие - другой. По поводу шифрования, если это хранилка то ей должно быть по барабану шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить и выдать по запросу не особенно вникая в подробности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #12, #13

12. Сообщение от syslinux (ok), 20-Янв-20, 00:13	+/–
> Шифровать это один вопрос, а сжатие - другой. А что сжатие - все тоже самое - сжали у себя конкретный файл или значение и отправили указав тип сжатия в хеадере, сервер запомнил. При обратном запросе тоже самое, сервер выдал сжатые данные и тип сжатия, который был указан вначале. Серверов хранения может быть мало, а клиентов которые заливают много, у них CPU больше, чтобы и жать и шифровать, зачем оверхед сжатия на сервере хранения делать? Единственно что на сервере надо предусмотреть, так это настраиваемый параметр добавления заголовка для выдачи обычному браузеру сжатого контента типа gzip, чтобы браузер автоматом распаковал и отобразил содержимое, а не выдал мусор gz. В том числе можно объединить сжатие и шифрование для конкретного файла при такой схеме если это требуется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14

13. Сообщение от syslinux (ok), 20-Янв-20, 00:15	–2 +/–
> Шифровать это один вопрос, а сжатие - другой. > По поводу шифрования, если это хранилка то ей должно быть по барабану > шифрованный файл вы ей отправляете или нет. Её задача принять, сохранить > и выдать по запросу не особенно вникая в подробности. Так так оно и есть сейчас, за исключением того что хранилка будет получать от клиента кроме самого зашифрованного файла, еще и тип в хеадере, Чтобы обратно при запросе выдать хеадер с этим же типом. Таким образом клиент будет сразу знать что ему летит в каком зашифрованном формате, то есть логику клиента можно гибко программировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

14. Сообщение от xm (ok), 20-Янв-20, 00:16	+/–
> А что сжатие - все тоже самое Нет, всё не то же самое, потому что сжимать сжатое смысла, как правило, нет, как я на это и указал выше. Резюмируя, ваши предложения при гипотетическом внедрении лишь способны существенно снизить производительность системы ради призрачных и, по сути, бессмысленных целей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

15. Сообщение от syslinux (ok), 20-Янв-20, 00:29	–2 +/–
>> А что сжатие - все тоже самое > Нет, всё не то же самое, потому что сжимать сжатое смысла, как > правило, нет, как я на это и указал выше. а) Вы посылаете текстовый файл 100KB , он запишется как есть, тип сжатия 0(посылать в хеадере не надо). б) Вы послаете "уже" сжатый на клиенте текстовый файл размером 25KB в формате zstd и указываете тип сжатия допустим номер 2. Этот номер 2 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 2", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый zstd файл. в) Вы посылаете "уже" сжатый на клиенте текстовый файл размером 40KB в формате gzip и указываете тип сжатия допустим номер 1. Этот номер 1 запишется на хранилке в бинарный заголовок приклеенный к самому сжатому файлу. Сам файл запишется как есть. При выдаче информации сервер пошлет в response header "Compressed: 1", ваш "специализированный" клиент запрограммированый на получение этого хеадера распакует сжатый gzip файл, или "обычный" браузер сам распакует и выдаст содержимое, если сервер настроен на выдачу штатного Content-Encoding хеадера. Сам сервер ничего не жмет и ничего не распаковывает. Какая еще проблема производительности? Пишется 1 байт и все, на стороне сервера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #17, #29

16. Сообщение от n80 (?), 20-Янв-20, 00:33	+1 +/–
Использую для аналогичного (sea)weedfs, уже несколько лет работает в проде (не без проблем, но остальное было ещё хуже). Интересно будет сравнить с этим wZD.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

17. Сообщение от xm (ok), 20-Янв-20, 00:38	–1 +/–
Беда нашего образования в том, что писать оно учит, а вот читать и, тем более, понимать, не очень. Повторяю: сжимать в канале умеет HTTP/2, сжимать на диске - файловая система. Делать это в других местах - ненужный оверхед. З.Ы. 1. 100K это не мелкий файл который прекрасно может эффективно хранится без каких-либо ухищрения практически в любой файловой системе. З.Ы. 2. И уже пишите по-русски "заголовок" вместо корявого "хеадер" (который даже в оригинале транскрибируется иначе).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #18

18. Сообщение от syslinux (ok), 20-Янв-20, 00:43	–7 +/–
> Беда образования, что писать оно учит, а вот читать и, тем более, > понимать не очень. > Повторяю: сжимать в канале умеет HTTP/2, сжимать на диске - файловая система. > Делать это в других местах - ненужный оверхед. > З.Ы. И уже пишите по-русски "заголовок" вместо корявого "хеадер" (который даже в > оригинале транскрибируется иначе). Не все фс умеют сжимать. Это опция, а не обязаловка. Кому надо, будет использовать. Гибкость. Выше очень подробно расписано. Сленговое слово хеадер обсуждать не намерен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

19. Сообщение от Аноним (19), 20-Янв-20, 09:37	+1 +/–
Я, может, чего-то не понимаю, но что мешает использовать в таком же режиме loop-файлы с любыми файловыми системами? Не хватает метаданных в одной ФС - сделал ещё десять и подмонтировал их в нужные каталоги. Для мелких файлов - reiserfs с tail-packing, для крупных xfs и так далее.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #20, #23, #30

20. Сообщение от Аноним (20), 20-Янв-20, 09:46	+1 +/–
то что ты, наверное, не хочешь создавать стопиццот loop-файлов вручную и обеспечивать им стопиццот точек монтирования для плохой имитации работы архиватора. Это архив, банальный архив. Но с модными dav и http/2 интерфейсами. Костылик вокруг неверно выбранной базовой технологии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #21

21. Сообщение от Александр Литягин (?), 20-Янв-20, 10:16	+/–
Не всегда базовую технологию можно выбирать. Так что это костылик, позволяющий жить где придется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #24

22. Сообщение от Аноним (-), 20-Янв-20, 11:37	+/–
Это для тех у кого ФС до сих пор не умеет в tail packing? :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #27

23. Сообщение от Аноним (-), 20-Янв-20, 11:38	+1 +/–
Я что-то не понимаю - что мешает просто использовать ФС с tail packing и предоставить ФС делать ФСовскую работу? Делать эрзац ФС на go в юзермоде и называть это инновацией - ну даже не знаю, хайп ради хайпа какой-то. Мол, смотрите как мы лихо научились левой пяткой правое ухо, записывайтесь в нашу школу йоги, однако!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #25, #39

24. Сообщение от syslinux (ok), 20-Янв-20, 11:39	+/–
Ну насчет прям костылика я с вами не очень согласен, если вы читали todo, то там достаточно много чего будет в ближайшее время реализовано, кроме банального помещения файликов в архивчики. Да это одна из главных задач была - чтобы можно было жить где придется не меняя основное кластерное решение впринципе. Из тяжелого в todo, только собственный дистрибьютор и FUSE, то что не получится просто и надежно сходу сделать за там 3 месяца. Дистрибьютор будет полностью отдельным компонентом, чтобы можно было обходится впринципе без кластерных фс в системах побольше, а сам текущий бекенд останется универсальным. Хотите так, хотите по другому.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от syslinux (ok), 20-Янв-20, 11:42	+/–
Это не ФС для начала, сравнение не корректное. ФС не ограничивается одним или парочкой серверов, если делать решение побольше раз в 10-50 например. Можете сравнить это так, как будто у вас zip архивы с мелочью вместо файлов, только это не zip и с полноценными возможностями. Так что это не ФС в юзер спейсе, а архивы. То что потом туда будет похитрому приделан FUSE потом для разнообразия, это не означает, что это ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

26. Сообщение от Аноним (26), 20-Янв-20, 13:33	+/–
> Использую для аналогичного (sea)weedfs, уже несколько лет работает в проде (не без проблем, но остальное было ещё хуже). Интересно будет сравнить с этим wZD. И как оно? Мы в свое время побоялись её на прод пускать. С какими проблемами пришлось столкнуться? Как нагрузку держит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #28

27. Сообщение от анонн (ok), 20-Янв-20, 13:48	+1 +/–
> Это для тех у кого ФС до сих пор не умеет в tail packing? :) Наверное, это для тех, кто в курсе минимального размера фрагмента/(суб)блока и разницы между ФС и "solid archiv". А в "tail packing" (block suballocation) умеют и древние ФС - нашли чем хвастаться :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

28. Сообщение от n80 (?), 20-Янв-20, 15:02	+/–
> И как оно? Мы в свое время побоялись её на прод пускать. А чего бояться, тестировать надо (и, пожалуй, хотя бы ознакомиться с кодом, благо его мало), а там уж ясно станет, либо пускать, либо не пускать. В моём случае, похоже, реальная нагрузка оказалась даже меньше тестовой, так что в итоге замечательно работает. И да, специфика моего случая: принципиально важна возможность удалять старые файлы (т.е. держать архив за N дней), при таком количестве файлов в случае ФС это была огромная боль. > С какими проблемами пришлось столкнуться? Как нагрузку держит? 1. Поначалу (ещё до выбора кого использовать) традиционно стоит проблема разобраться с документацией. У weedfs сущностей используется меньше (чем у аналогов), так что это ещё одна из причин его выбрать в итоге. 2. Конечно же вылезла проблема Go'шного GC (который «stop the world» любит делать), но по пути до прода она исчезла (во-первых, было несколько важных обновлений Go и самого weedfs, во-вторых, нагрузка на проде оказалась куда ниже, чем в тестах). Так что нагрузку в итоге держит стабильно. В итоге упёрлось всё в ширину канала наружу, а не в БД. 3. Т.к. использовать вложенные каталоги тут весьма нежелательно, пришлось чутка поменять код приложений, которые работали с этой БД, вместо путей вида /datatype/param-a/param-b/param-c/zzz стали, грубо говоря, /datatype/param-a_param-b_param-c_zzz. Т.к. оно используется только по HTTP (без всяких FUSE-обёрток), такое изменение никаких новых проблем не принесло. 4. Не забыть на nginx, стоящем между интернетами и БД, явно указать что для проксируемых запросов разрешён только метод GET. Не то что бы это проблема, но могло ей стать, если бы не вспомнили в последний момент. Вроде, и очевидная вещь, но имеет отношение не к самой БД, а к инфраструктуре вокруг, так что может и остаться незамеченной (прямо скажем, нечасто в nginx в секции proxy_pass приходится указывать список методов). 5. В какой-то момент volume заполняется и сам он расти не будет, при этом, насколько помню, его максимальный размер в коде ограничен. Нужно либо править код сразу (исходя из своих предположений о том, сколько будет храниться), либо вовремя подключать больше томов. Т.е., в общем-то, мелочи, а не проблемы. Нужно заранее прикидывать сколько места будут занимать данные, использовать не антикварную версию Go и, конечно же, тестировать. Что отдельно радует (хоть это и не показатель), за несколько лет оно ни разу не сегфолтилось, не падало из-за необработанных исключений и не зависало из-за какого-нибудь deadlock.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #32

29. Сообщение от Sokoloff (?), 20-Янв-20, 15:14	+/–
>а)... он запишется как есть >б) ... Сам файл запишется как есть. >в) ... Сам файл запишется как есть. Не совсем понятно зачем серверу знать про компрессию если он всегда хранит файл как есть? По сути Вы хотите хранить дополнительные метаданные к файлу, я не знаю WebDav такое умеет или нет. Но накойняк, всегда можно запихать сжатие в имя файла. Пишите a) data.txt б) data.txt.zstd в) data.txt.gzip И обрабатывайте в зависимости от расширения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #38

30. Сообщение от n80 (?), 20-Янв-20, 15:14	+/–
> Я, может, чего-то не понимаю, но что мешает использовать в таком же > режиме loop-файлы с любыми файловыми системами? Не хватает метаданных в одной > ФС - сделал ещё десять и подмонтировал их в нужные каталоги. > Для мелких файлов - reiserfs с tail-packing, для крупных xfs и так далее. Для некоторых задач у ФС слишком большие (по сравнению с такими специализированными решениями) накладные расходы на один файл. При этом большая часть возможностей ФС может быть вообще не нужна (типа отдельных mode/uid/gid/atime/mtime/ctime/etc для каждого файла), но нельзя просто взять их и отключить. Не говоря уж про то, как «больно» на ФС удалять/обновлять много мелких файлов. Соответственно, если можно читать с дисков сразу содержимое файлов и не тратить память ядра (и пропускную способность дисков) на чтение inode, не говоря уж про время на системные вызовы для открытия очередного запрошенного файла, то на том же железе можно хранить куда больше файлов и в единицу времени обрабатывать куда больше запросов. Так в своё время мордокнига (facebook) и пришла к своему haystack, но т.к. в публичный доступ была выложена только статья, но не сама БД, у других контор с похожими нуждами начали возникать свои реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #31, #35

31. Сообщение от n80 (?), 20-Янв-20, 15:16	+/–
А, и чуть не забыл: у обычных ФС нет встроенной репликации между серверами. Можно, конечно, использовать rsync (или даже костылить что-то на inotify в духе lsyncd), но это, опять-таки, будет очень «больно» на огромных каталогах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Аноним (26), 20-Янв-20, 18:38	+/–
Спасибо! На днях потестирую.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

33. Сообщение от funny.falcon (?), 20-Янв-20, 19:13	+/–
BBolt - это mmap-ed хранилище. В один тред не будет ни какой конкурентности при чтении холодных данных. Мало того, Go runtime не способен отреагировать на затупивший page fault, как он мог бы среагировать на затупивший syscall. Потому, для хорошей производительности ещё и придется вручную GOMAXPROCS увеличивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #47

34. Сообщение от funny.falcon (?), 20-Янв-20, 19:14	+/–
Практически описали рантайм Go. Правда, они решили сосредоточиться на "зеленых потоках" вращающихся на тредпуле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

35. Сообщение от Аноним (35), 20-Янв-20, 22:40	+1 +/–
>нельзя просто взять их и отключить Так всякие raw-разделы ещё в OracleDB были. Просто мне кажется, что если ты упираешься в ограничения ФС при работе с файлами - то ты что-то неправильно делаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #36

36. Сообщение от n80 (?), 21-Янв-20, 03:00	+/–
> Так всякие raw-разделы ещё в OracleDB были. С OracleDB почти не имел дела, но сразу два момента: 1) тут всё-таки про свободное ПО речь, это очень важный момент 2) низкие накладные расходы, легковесность, максимизация количества обрабатываемых простых запросов в единицу времени (по сравнению с конкурентами на таком же железе) — точно не про Oracle > Просто мне кажется, что если ты упираешься в ограничения ФС > при работе с файлами - то ты что-то неправильно делаешь. Полностью согласен. И вот один из путей перестать делать неправильно — положить данные в подходящую для задачи специализированную СУБД, а не в отдельные файлы в ФС общего назначения. О том и речь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #37

37. Сообщение от syslinux (ok), 21-Янв-20, 12:00	+/–
Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? Кто утверждает, что такое количество допустим должно быть обязательно в фс общего назначения, про кластерные забыли? Там писал один человек, что moosefs лопнула, не лопнула, она нормально впринципе работает с такими количествами файлов, если у вас есть деньги на оперативную память, но вот ее CRC проверка фоновая проводится несколько месяцев на таких количествах, а она там однопоточная и это не регулируется. Доводить до половины миллиарда файлов или больше уже нет смысла в ней. Вам дали способ - как упростить себе жизнь не изменяя файловую систему на какие-то решения, которые еще неизвестно как себя поведут(в плане фс изначально), в том числе оставлена без изменений работа с большими файлами, не надо заботится о волюмах, изменять пути в приложении, и прочие вещи. Кстати на счет SeaWeedFS - вы писали там есть TTL, что может быть удобно в некоторых случаях. Я сделаю у себя такую поддержку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #40, #41

38. Сообщение от syslinux (ok), 21-Янв-20, 15:32	+/–
>[оверквотинг удален] >>б) ... Сам файл запишется как есть. >>в) ... Сам файл запишется как есть. > Не совсем понятно зачем серверу знать про компрессию если он всегда хранит > файл как есть? По сути Вы хотите хранить дополнительные метаданные к > файлу, я не знаю WebDav такое умеет или нет. Но накойняк, > всегда можно запихать сжатие в имя файла. Пишите > a) data.txt > б) data.txt.zstd > в) data.txt.gzip > И обрабатывайте в зависимости от расширения. Сделано будет просто для унификации как и с типом шифрования, любой способ будет работать, даже если без доп.метаданных и без расширения залить все равно определится тип сжатия по первым 512 байтам, за исключением совсем редких типов. Для чего надо у типа шифрования, да банально обмен ссылками, если кто-то будет использовать без единой базы, и будет уже известен тип шифрования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

39. Сообщение от пох. (?), 21-Янв-20, 15:41	+/–
> Я что-то не понимаю - что мешает просто использовать ФС с tail packing вероятно - то что раз люди вынуждены использовать moose - у них уже давным-давно хранилище не влезает в один корпус, при требуемых емкости и надежности? А кластерные fs, увы, ни про какой tail fucking не знают, они вообще сексуально неразвитые. И выбор из moose/lizard с их metadata=ram (то есть как только все данные о ВСЕХ файлах перестали влезать в оперативку одного компьютера - опачки, кластер превращается в тыкву) и gluster (для создания файла надо опросить ВСЕ узлы кластера - метаданных-то нет, поэтому надо у каждого спросить "а не лежит ли у тебя уже файл с таким же точно именем/путем?") А они изобрели [не]банальный архиватор с webdav интерфейсом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

40. Сообщение от пох. (?), 21-Янв-20, 15:45	+/–
> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? в оракловую, например. Не вижу особых проблем, кроме цены решения. Такая картинка - отличный blob (не очень-то и 'l'), причем ее метаданные если есть - абсолютно перпендикулярны типовым для файловой системы (в последнюю очередь, полагаю, вас интересует ее atime с точностью до микросекунды), и вы их все равно в какой-то тазе банных храните ведь? И да, орацл умеет в кластеры ;-) btw - сколько на самом деле жрет памяти на metadata и какого объема логи на логсерверах, если не жалко?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42

41. Сообщение от n80 (?), 21-Янв-20, 16:22	+/–
> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? Ну, для меня решение из этой новости или всё тот же SeaWeedFS — тоже в определённом смысле СУБД. Так что база в этом смысле. Если что, я тут нигде не топил за ненужность сабжа, напротив, пишу о причинах по которым такие решения нужны и возникают. > Кто утверждает, что такое количество допустим должно быть обязательно в фс общего > назначения, про кластерные забыли? Не суть, имелись в виду ФС, как бы так сказать, совместимые с POSIX-семантикой. Которым противопоставляется специализированное решение, имеющее свои преимущества, в т.ч. за счёт отказа от всяких неиспользуемых функций. > Вам дали способ - как упростить себе жизнь не изменяя файловую систему > на какие-то решения, которые еще неизвестно как себя поведут (в плане фс > изначально), в том числе оставлена без изменений работа с большими файлами, > не надо заботится о волюмах, изменять пути в приложении, и прочие вещи. Я же разве против? Наоборот, всецело за. Разве что заботиться иногда всё-таки надо, это позволяет получить дополнительный выигрыш. > Кстати на счет SeaWeedFS - вы писали там есть TTL, что может > быть удобно в некоторых случаях. Я сделаю у себя такую поддержку. Наверное, уточню: в моём случае протухание по TTL реализовано внешним скриптом (потому что логика выбора удаляемых файлов немного нетривиальная), который посылает пачку запросов на удаление. Залить несколько миллионов файлов, потом продолжать потихоньку заливать файлы, а потом через сутки 2% самых старых из них удалить пачкой запросов — суровый такой стресс-тест. Более-менее традиционные ФС на удалении десятков тысяч мелких файлов ооочень крепко задумываются (иногда подвешивая вообще все операции ввода-вывода, пока журнал не прокачается).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #43

42. Сообщение от syslinux (ok), 21-Янв-20, 16:29	+/–
>> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу? > И да, орацл умеет в кластеры ;-) > btw - сколько на самом деле жрет памяти на metadata и какого > объема логи на логсерверах, если не жалко? В wZD? 32 байта, оно хранится прямо в файле который заливается, память не используется. Из которых 8 байт зарезервировано под будущий дистрибьютор. Логи тут не нужны. Мне уже не нужно никакое решение, я уже все что надо сделал без любой бд. В MooseFS на оставшиеся 10млн файлов после архивирования потребляется 8GB RAM всего с учетом директорий, а было 75GB+.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #44

43. Сообщение от syslinux (ok), 21-Янв-20, 16:36	+/–
Принял. Спасибо за уточнение как вы делаете. Значит предусмотрю изменение TTL без перезаписи файлов. То есть не только вместе с файлом когда идет первоначальная заливка, но и потом чтобы можно было поменять TTL на другой или убрать TTL вовсе. Методом DELETE можно и внешним скриптом пользоваться как у Вас без поддержки встроенного TTL. На счет задумываться - да ФС имеют такие проблемы при очень массовых операциях. У меня в теории не должно быть проблем, не фс все-таки, принцип то примерно тот же как в SeaWeedFS, просто если думать волюмамим, то у меня волюмов столько сколько папок по сути, в них еще быстрее удаление будет работать. Я ни в коем случае не говорю Вам что мое чем-то лучше тоже, просто тема об одном, а уже Оракл сюда был приплетен. Да и я сомневаюсь что он нормально будет работать, там один индекс будет громадным, это надо тестировать сначала Оракл в таком ключе, а потом уже писать сюда, а то это просто предположение :) P.S. Просмотрел, это не Вы написали про Оракл изначально, другие комментаторы молодцы. SeaWeedFS тут совершенно корректно сравнивать, у меня решение зависимо конечно, в случае большого сторейджа, от обычных кластерных ФС на данный момент, но потом будет дистрибьютор и можно будет обходится и без кластерных ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

44. Сообщение от пох. (?), 21-Янв-20, 16:49	+/–
нет, мне было интересно именно для moose до переноса всего в архивы - чтобы понимать, на каких масштабах оно таки лопается. 250миллионов файликов = 75G оперативы, я правильно понял? А что при этом происходило на металоггере, или вы ими не пользовались?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #45

45. Сообщение от syslinux (ok), 21-Янв-20, 17:12	+1 +/–
> нет, мне было интересно именно для moose до переноса всего в архивы > - чтобы понимать, на каких масштабах оно таки лопается. > 250миллионов файликов = 75G оперативы, я правильно понял? > А что при этом происходило на металоггере, или вы ими не пользовались? Да, все верно. Изначально был, потом убрал, чтобы он диски SSD мне не убивал. Не вспомню как он работал, когда было 150млн файлов, но в память точно все помещалось. У меня по 128GB было на серверах, где была пара металоггеров. Теперь вернул естесственно обратно. Я думаю MooseFS то не лопнет и на 500млн файлов, но при условии что у вас будет порядка 30-50млн подпапкок, где файлов по 10-1000 примерно, но все равно скорость то будет помедленнее. А вот если у вас 500млн файлов и 1млн подпапок всего, тогда это все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок и больше файлов, тем больше сами массивы, тем хуже все работает. Но я уже не рискнул бы доводить до таких объемов у себя, просто потому что и запускается дольше и CRC долго чекает итп итд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #46

46. Сообщение от syslinux (ok), 21-Янв-20, 17:20	+/–
>[оверквотинг удален] > была пара металоггеров. Теперь вернул естесственно обратно. > Я думаю MooseFS то не лопнет и на 500млн файлов, но при > условии что у вас будет порядка 30-50млн подпапкок, где файлов по > 10-1000 примерно, но все равно скорость то будет помедленнее. А вот > если у вас 500млн файлов и 1млн подпапок всего, тогда это > все будет уже гораздо хуже работать. Ведь MooseFS создает индексы частями > в памяти чтобы искать сразу по нужным массивчикам. Чем меньше папок > и больше файлов, тем больше сами массивы, тем хуже все работает. > Но я уже не рискнул бы доводить до таких объемов у себя, просто > потому что и запускается дольше и CRC долго чекает итп итд.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

47. Сообщение от syslinux (ok), 21-Янв-20, 17:37	+/–
GOMAXPROCS автоматом ставится по количеству CPU начиная с версии Go 1.5 . Как бы, если вы хотите на машине с 1-м ядром использовать этот сервер, врядли это нормально для такого решения, с миллионами файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33

48. Сообщение от syslinux (ok), 23-Янв-20, 07:45	+/–
Завез я уже поддержку HTTPS, Keepalive, авторизацию per vhost, включение отключение 404-ых, метод POST(только бинарные данные так же как и в PUT), метод OPTIONS, и еще по мелочи. Пока только в ветке мастер, если кому надо можете попробовать собрать потестировать, версия 1.1.0-beta собрана на гитхабе. Это еще не все что туда будет добавлено.
Ответить | Правка | Наверх | Cообщить модератору

51. Сообщение от hes (?), 15-Янв-21, 17:33	+/–
очень похоже на Grafana/Loki. Так же boltdb в качетсве хранения данных, только там хранят логи
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема