Эффективное хранение сотен миллионов маленьких файлов. Self-Hosted решение



    Уважаемое сообщество, эта статья будет посвящена эффективному хранению и выдаче сотен миллионов маленьких файлов. На данном этапе предлагается конечное решение для POSIX совместимых файловых систем с полноценной поддержкой блокировок, в том числе кластерных, и вроде бы даже уже без костылей.

    Поэтому для этой цели я написал свой собственный специализированный сервер.
    По ходу реализации этой задачи удалось решить основную проблему, попутно добиться экономии дискового пространства и оперативной памяти, которую нещадно потребляла наша кластерная файловая система. Собственно такое количество файлов вредно для любой кластерной файловой системы.

    Идея такая:

    Простыми словами, через сервер заливают мелкие файлы, они сохраняются напрямую в архив, и так же считываются из него, а большие файлы кладутся рядом. Схема: 1 папка = 1 архив, итого имеем несколько миллионов архивов с мелкими файлами, а не несколько сотен миллионов файлов. И все это реализовано полноценно, без всяких скриптов и раскладывания файлов по tar/zip архивам.

    Постараюсь изложить покороче, заранее приношу извинения если пост будет емким.

    Началось все с того, что я не смог найти подходящего сервера в мире, который мог бы сохранять данные, полученные через HTTP протокол напрямую в архивы, так чтобы не было недостатков присущих обычным архивам и объектным хранилищам. А причиной поисков стал разросшийся до больших масштабов Origin кластер из 10 серверов, в котором скопилось уже 250,000,000 мелких файлов, а тенденция роста и не собиралась прекращаться.

    Тем, кто читать статьи не любит и небольшая документация проще:

    сюда и сюда.

    Update. Из docker образа убран nginx.

    И docker заодно:
    docker run -d --restart=always -e bindaddr=127.0.0.1:9699 \
     -e host=localhost -e root=/var/storage -v /var/storage:/var/storage --name wzd \ 
     -p 80:9699 eltaline/wzd

    Далее:

    Update. В версии 1.1.0 уже появился HTTPS / метод POST / IP авторизация и прочее.

    Если файлов очень много, необходимы значительные ресурсы, причём, самое обидное, часть их пропадает впустую. К примеру, при использовании кластерной файловой системы (в рассматриваемом случае — MooseFS) файл, независимо от фактического размера, занимает всегда минимум 64 KB. То есть для файлов размером 3, 10 или 30 KB на диске требуется по 64 KB. Если файлов четверть миллиарда, мы теряем от 2 до 10 терабайт. До бесконечности создавать новые файлы не удастся, так как в той же MooseFS есть ограничение: не более 1 миллиарда при одной реплике каждого файла.

    По мере увеличения количества файлов, нужно много оперативной памяти для метаданных. Так же частые большие дампы метаданных способствуют износу SSD-накопителей.

    Сервер wZD. Наводим порядок на дисках.

    Сервер написан на языке Go. Прежде всего мне нужно было уменьшить количество файлов. Как это сделать? За счёт архивирования, но в данном случае без компрессии, так как у меня файлы это сплошные ужатые картинки. На помощь пришла BoltDB, которую еще пришлось лишать недостатков, это отражено в документации.

    Итого вместо четверти миллиарда файлов в моем случае осталось только 10 миллионов Bolt архивов. Если бы у меня была возможность изменить текущую структуру наполнения файлами директорий, то возможно было бы сократить примерно и до 1 миллиона файлов.

    Все мелкие файлы упаковываются в Bolt архивы, автоматически получающие имена директорий, в которых они лежат, а все крупные файлы остаются рядышком с архивами, их нет смысла упаковывать, это настраиваемо. Маленькие — архивируем, большие — оставляем без изменений. Сервер работает прозрачно и с теми, и с другими.

    Архитектура и особенности сервера wZD.



    Сервер функционирует под управлением операционных систем Linux, BSD, Solaris и OSX. Я тестировал только для архитектуры AMD64 под Linux, но он должен подойти и для ARM64, PPC64, MIPS64.

    Основные фишки:

    • Многопоточность;
    • Мультисерверность, обеспечивающая отказоустойчивость и сбалансированность нагрузки;
    • Максимальная прозрачность для пользователя или разработчика;
    • Поддерживаемые HTTP-методы: GET, HEAD, PUT и DELETE;
    • Управление поведением при чтении и записи через клиентские заголовки;
    • Поддержка гибко настраиваемых виртуальных хостов;
    • Поддержка CRC целостности данных при записи/чтении;
    • Полудинамические буферы для минимального потребления памяти и оптимальной настройки сетевой производительности;
    • Отложенная компакция данных;
    • В дополнение предлагается многопоточный архиватор wZA для миграции файлов без остановки сервиса.

    Реальный опыт:

    Я разрабатывал и тестировал сервер и архиватор на живых данных довольно долгое время, сейчас он успешно функционирует на кластере включающем 250,000,000 мелких файлов (картинок), расположенных в 15,000,000 директорий на раздельных SATA-дисках. Кластер из 10 серверов представляет собой Origin-сервер, установленный за CDN-сетью. Для его обслуживания используется 2 сервера Nginx + 2 сервера wZD.

    Тем, кто решит использовать этот сервер, имеет смысл перед использованием спланировать структуру директорий, если это применимо. Сразу оговорюсь, что сервер не предназначен для того, чтобы всё запихнуть в 1 Bolt архив.

    Тестирование производительности:

    Чем меньше размер заархивированного файла, тем быстрее выполняются с ним операции GET и PUT. Сравним полное время записи HTTP клиентом в обычные файлы и в Bolt архивы, и так же чтение. Сравнивается работа с файлами размером 32 KB, 256 KB, 1024 KB, 4096 KB и 32768 KB.

    При работе с Bolt архивами проверяется целостность данных каждого файла (используется CRC), до записи и так же после записи происходит считывание на лету и пересчет, это естественно вносит задержки, но главное — безопасность данных.

    Тесты производительности я проводил на SSD-накопителях, так как на SATA-дисках тесты не показывают четкой разницы.

    Update (v1.1.0), улучшена производительность на 5-25%.

    Графики по результатам тестирования:




    Как видно, для небольших файлов разница во времени чтения и записи между архивированными и не заархивированными файлами невелика.

    Совсем иную картину уже получим при тесте чтения и записи файлов размером 32 MB:



    Разница во времени между чтением файлов — в пределах 5-25 мс. С записью дела обстоят хуже, разница составляет около 150 мс. Но в данном случае и не требуется заливать большие файлы, в этом попросту нет смысла, они могут жить отдельно от архивов.

    *Технически можно использовать данный сервер и для задач требующих NoSQL.

    Основные методы работы с wZD сервером:

    Загрузка обычного файла:
    curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

    Загрузка файла в Bolt архив (если не превышен серверный параметр fmaxsize, определяющий максимальный размер файла, который может быть включён в архив, если же превышен, то файл загрузится как обычно рядом с архивом):
    curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

    Скачивание файла (если на диске и в архиве есть файлы с одинаковыми именами, то при скачивании приоритет по умолчанию отдаётся не заархивированному файлу):
    curl -o test.jpg http://localhost/test/test.jpg

    Скачивание файла из Bolt архива (принудительно):
    curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg


    Описание других методов есть в документации.

    Документация wZD
    Документация wZA

    Сервер пока что поддерживает только протокол HTTP, с HTTPS пока не работает. Также не поддерживается метод POST (еще не решено нужен он или нет).

    Кто покопается в исходном коде, обнаружит там ириску, ее не все любят, но я не привязывал основной код к функциям веб фреймворка, кроме обработчика прерываний, так что в дальнейшем могу переписать быстро почти на любой движок.

    ToDo:

    • Разработка собственного репликатора и дистрибьютора + гео для возможности использования в больших системах без кластерных ФС (Всё по взрослому)
    • Возможность полного реверсивного восстановления метаданных при их полной утере(в случае использования дистрибьютора)
    • Нативный протокол для возможности использования постоянных сетевых соединений и драйверы к разным языкам программирования
    • Расширенные возможности использования NoSQL составляющей
    • Компрессии разных типов (gzip, zstd, snappy) для файлов или значений внутри Bolt архивов и для обычных файлов
    • Шифрование разных типов для файлов или значений внутри Bolt архивов и для обычных файлов
    • Отложенная серверная видео конвертация, в том числе и на GPU

    У меня всё, надеюсь этот сервер кому-нибудь пригодится, лицензия BSD-3, копирайт двойной, так как не было бы компании где я работаю, не написал бы и сервер. Разработчик я в единственном числе. Буду признателен за найденные баги и фич реквесты.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 34

      +1

      Как решается проблема синхронного изменения (создания) файла несколькими репликами? Все кластерные файловые системы свою монстрообразность как раз ради этого и придумывают, чтобы можно было адекватно разрулить ситуацию, когда в один и тот же файл несколько конкурентных запросов приходит.

        0
        Достаточно просто, POSIX кластерная фс должна быть с поддержкой блокировок, в таком случае она разрулит этот момент. В самом BoltDB реализован таймаут на взятие блокировки, который настраивается у меня в wZD, а так же еще дополнительно есть повторы, тоже настраиваемые, таким образом получается так, что кластерная фс не позволит записать одновременно в 1 Bolt архив 2-м и более wZD серверам работающих на разных серверах. А чтобы не получить 500 ошибку в итоге и нужны таймауты и взятие попыток блокировки, запрос просто будет ожидать некоторое заданное время.

        Дополнительно в самом wZD реализованы для безопасности виртуальные mmutex с попытками и таймаутами, чтобы не позволить даже дойти до файловой блокировки в рамках 1 сервера wZD, если в 1 сервер будут идти загрузки файлов параллельно в большом количестве в 1 папку, тобишь в 1 Bolt архив.

        Если проще, то как раз и рассчитано на то что под wZD будет кластерная фс, он сам не является дистрибьютором пока, чтобы в будущем обходиться без кластерной фс. С обычной фс все тоже самое будет, просто с ней будет работать только 1 wZD сервер.

        Суть этого сервера на текущий момент в том, чтобы значительно разгрузить любую кластерную ФС, в 10-10000 раз уменьшив общее кол-во файлов, где как у кого получится, тогда она себя будет прекрасно чувствовать. Что касается работы с большими файлами — нет проблем — они записываются как обычные файлы без архивирования. Сервер универсален.
          0

          Я не совсем понял, кто хранит блокировку, кто её снимает (если поставивший блокировку сервер умер) и каким образом обеспечивается надёжность хранителя блокировки?

            +1
            Какую именно блокировку вы имеете ввиду? У меня есть виртуальные блокировки(если сервер умрет, в его памяти так же исчезнет блокировка), в BoltDB есть блокировки(если сервер умрет, снимется и блокировка), в MooseFS обеспечиваются блокировки на уровне уже самих физических файлов, файловая система поддерживает блокировки. То есть умерший сервер не может никак сделать так, чтобы заблокировать файл навсегда. Везде предусмотрены таймауты. Bolt это же безсерверная база фактически.

            Если просто, вот у вас есть кластерная фс, которая поддерживает блокировки и сама условно за этим следит. Вот вы берете и пробуете начать работать с файлом любым конкурентно с эксклюзивной блокировкой на запись, вам сама фс по сути не даст захватить это в 2 процесса. То есть на уровне фс это все уже решено. Не важно какой именно софт будет работать с файлом в итоге. В данном случае именно эксклюзивную блокировку ставит сам BoltDB — его код.
        +1

        250 миллионов мелких объектов? Чем вам БД стандартная не подходит?

          +1
          Файлы не настолько маленькие, примерно 1 KB — 1024 KB, суммарно общий объем ~80 TB на данный момент чистых данных, поэтому база не подходит. Просто тех которые поменьше их больше.
          0
          Были ли проблемы с контрольной суммой за время эксплуатации?
            0
            Пока нет, всегда совпадало, железо из строя еще не выходило.
              +1
              Чтобы разбежались контрольные суммы не обязательно нужен выход из строя железа. Как яркий пример, rowhummer. Бывают ещё и трудноуловимые проблемы с памятью под нагрузкой. Ещё были менее известные кейсы как баг trim в системном ядре. И чем больше масштабы проекта, тем вероятнее что чтото вылезет.
                0
                Да я согласен, может быть множество проблем которые это вызовут.
                Например в хранилищах, особенно на SSD дисках может быть так, что файл не запрашивался много лет и его ячейки изменили заряд, так называемая bit rot проблема, ну это может и не только по этой причине случится.

                Например в MooseFS это решено так, что сама фс потихонечку периодически в фоне запрашивает файлы частями, сверяет суммы, так как там есть реплика, если где-то сумма не сойдется, то она в фоне сама заново восстановит битый файл с доступной реплики. В Minio тоже есть некоторое решение, но я его не изучал, не могу сказать как у них работает.

                И мне придется в будущем делать аналогичное решение, если я сделаю свой дистрибьютор по типу как в Minio или в MooseFS, чтобы можно было сделать уже свой полноценный кластер с дистрибьюторами без кластерной фс впринципе.
                  0
                  Мне этот вопрос очень интересен, потому что на «несерверном» железе данные деградируют достаточно быстро (и 3 месяца для бэкапа выглядит уже вполне себе адекватным интервалом). И по мере роста плотности данных и сложности устройств процесс этот будет лишь усугубляться.
                    0
                    Технически я могу попробовать в ближайший месяц даже еще без создания дистрибьютора реализовать такую опцию по проблеме bit rot или аналогичных проблемах уже в текущий свой сервер. Это все равно рано или поздно надо будет делать, потому что по сути дистрибьютор, когда он будет реализован, не будет заниматься непосредственной периодической проверкой, заниматься то будет ей как раз текущий продукт, он же бекенд по сути. Но как вы понимаете он ведь ничего не восстановит сейчас, у него нет реплик еще, так то это итак будет делать кластерная фс под ним, если она конечно есть под ним :), но как сделаю сможет хотя бы проверять что у него в архивах на текущий момент.
                      0
                      Даже без восстановления — всегда полезно, и как можно раньше, узнать что данные деградируют.

                      Мне со своей стороны — интересно создать контейнерный формат (возможно чем то похожий на HDF5), в котором можно былобы хранить мелкие файлы, что бы был внешний словарь для распаковки, также была информация для восстановления (аналог винрар или кодов Рида-Соломона), а так же дешевое восстановление в случае сбоя (чтобы его можно былобы восстановить с бинарного образа диска даже если FAT таблица или её аналог — отсутствовали ).

                      Мотивы — аналогичные вашим, работа с мелкими файлами — дорогая + врожденная параноя о ненадежности.
                        0
                        Интересный формат, даже не слышал ранее о HDF5, изучу.

                        В случае например классической файловой системы, если бы у меня была цель восстановить фактически с секторов диска данные тех же Bolt архивов, когда нет уже ни журналов, ничего вообще нет, но еще нулями не затерли данные, то я бы поступил так, я бы добавил уникальную метку своего формата в каждый записанный файл, включающую бинарную информацию о начале и конце данных — это на простом языке.

                        Даже не обязательно это был бы Bolt с файлами внутри, рассмотрим любой формат, даже обычный файл с приклеенным к нему таким заголовком, по аналогии как я уже приклеиваю сейчас заголовок с метаинформацией в wZD.

                        Ну а далее нужна низкоуровневая утилита, которая будет искать такие заголовки, брать из них начало и конец, собирать файл обратно. Это если простой вариант, если же серверов несколько и один хранит у себя полфайла, и другой полфайла, и больше реплик нет, то написать такую утилитку еще та задачка. Для рида-соломона это собрать все еще сложнее в случае большей части дисков без фс, и с остатками данных там, где еще есть фс.

                        Но идея мне понятна, до такой степени я сейчас не готов у себя делать реализацию, надо бы сначала закончить задачи более насущные и простые.
                          0
                          Например: Зная размер сектора (минимальную единицу фрагментации ФС), можно вначало каждого сектора вписывать его порядковый номер и crc. А дальше всегда можно склеить из кусочков по аналогии с ТСР протоколом, только вместо сети — диск, а вместо пакета — кластер файловой системы.
            –1

            Лучше бы в min.io коммитили.

              +2
              Да я бы с радостью, но там возникают теже проблемы, просто уже в объектном хранилище. Для такого количества файлов и более, тем более маленьких или очень маленьких он не предназначен. Надо же не потерять производительность.

              Я немного уточню зачем я придумал свой сервер.

              Вот смотрите, MooseFS нормально работает с 200, даже с 300 миллионами файлов, но чем дальше, тем хуже, minio по своей архитектуре вообще не предназначен для этого.

              Если правильно продумать структуру директорий, чтобы было допустим примерно по 1000
              маленьких файлов в каждой папке или подпапке, то работая с архивами на базе того же Bolt, можно в 1000 раз уменьшить количество файлов. и будет у Вас в MooseFS уже 200-300 тысяч файлов, но уже по сути больших. Далее только успевайте подавать диски MooseFS, чтобы наращивать емкость, и вполне можно хранить в большом кластере MooseFS фактически не реально очень много файлов. Никаких проблем с громадными метаданными.

              Вот оно по сути уже, какое-никакое сейчас, но реальное решение без серьезной деградации производительности по совокупности на двух продуктах.

              Я просто не тестировал еще свой сервер например с GlusterFS, знаю только что он вообще не переваривает очень много мелких файлов. Если тесты будут положительными, то и тут решается проблема. Не обязательно даже мне делать более сложное решение, когда можно оптимально получить готовое решение вместе с другим продуктом.

              Дело только в архитектуре.
                0

                Min.io использует низлежащую фс для хранения метаданных и данных. Единственный оверхэд — ваша фс тоже хранит метаданные.
                Min.io всего лишь реализует верхнеуровневую абстракцию и предоставляет api.

                  0
                  Я еще добавлю немного от себя.
                  Что я могу в дальнейшем теоретически добавить в функционал?

                  Например у нас есть тысячи или даже миллионы архивов, в них тысячи файлов каждом архиве, но доступны они пока только из архиватора wZA или из wZD по HTTP.

                  Если получится реализовать прозрачное FUSE монтирование через bind и перехват данных, то тогда будет возможно автоматом монтировать моментально эти Bolt архивы, например при любом действии — зашли в папку, раз и он быстро примонтировался и вы в midnight commander увидели сразу содержимое этого Bolt архива на равне с обычными файлами, и можете работать как с обычными файлами. И в моем случае, я смогу через такой FUSE сделать блокировку, да целого bolt архива, но тем не менее смогу, точно так же как сейчас архив блокируется на запись данных. И так же смогу считать столько байт сколько мне надо. Иными словами полноценная FUSE поддержка задумана уже.

                  Например Minio можно примонтировать через FUSE, но там действуют ограничения, например теже блокировки не поддерживаются в файлах-объектах, которые вы увидите. Так же там будет возможно получить только полное содержимое объекта, насколько я помню. Нельзя просто взять и считать 300 байт из такого объекта.

                  Да, я уже модифицировал BoltDB под свой сервер, я детально не указывал в статье конкретно для чего, но в документации это описано. wZD теперь может считывать из Bolt архива столько данных сколько надо из значения, например для поддержки Range / Accept-Ranges (это когда клиент просит докачку), без считывания целого значения — в данном случае файла внутри Bolt архива. Зачем лишний оверхед, когда клиент попросил — дай мне данные из файла с 300 по 700 байт условно.

                  Если поглубже подумать, то очень разные у нас с Minio подходы. Мой сервер не заменит Minio скажем так, никогда, он просто не совместим банально с Amazon S3. У меня другой продукт, который универсально решает кучу проблем. Но Minio так же не сможет то, что сможет wZD.
                    +1

                    Напишите бекенд для минио. И все, по аналогии с ажуром и тп.
                    Сверху будет с3 апи, внизу храните как хотите.

                      0
                      Теоретически это можно будет сделать, но для этого нужно именно свой дистрибьютор мне реализовать, если вообще Minio потом примут эту штуку как бекенд(Gateway) к себе. Потому что Minio в таком случае не будет делать ни erasure coding, ни репликацию, он только предоставит S3 API. Все остальное ведь все равно полностью делать надо в своем же бекенде уже с дистрибьютором, иначе какой смысл это все в Minio тащить как бекенд(Gateway).

                      Но если даже просто сделать чтобы был S3 API к тому что уже есть у меня, да мне проще его к себе вписать даже в текущий компонент, зачем еще один прокси в виде Minio в таком случае?

                      Вообще это дельное предложение от Вас, да можно будет сделать Gateway к wZD для Minio, точнее к дистрибьютору wZD. Но уже когда будет сделан свой дистрибьютор. Да такая возможность вполне реальна в будущем, в том числе для разнообразия.
                      +1

                      Я бы на вашем месте сначала попробовал бы реализовать свой storage под имеющийся интерфейс в minio.

                        0
                        Вы посмотрите туда в код — там волюмы с путями, как мне все свое вписать туда как storage? Это нужно полностью свой уровень VFS делать, чтобы было представление как вообще обычной файловой системы, тогда будет работать быстро — ну предлагаете фактически почти свою FS написать — для того чтобы Minio потом смог использовать это как Storage в итоге, потому что просто FUSE это не реально с тысячами или миллионами болт архивов в итоге, оно просто умрет.

                        Чистый FUSE в будущем я смогу реально использовать только для того, чтобы предоставлять доступ на лету в конкретный Bolt архив без архиватора, только когда туда идет обращение или открывается папка — прозрачно для пользователя — это есть у меня в дальних планах. Не примонтируешь же разом все Bolt архивы.
                  0
                  SeaWeedFS под задачу подходит лучше.
                    0
                    SeaWeefFS — это уже ФС, запись быстрая, чтение медленнее, рассчитана только на маленькие файлы и только. В его фс возможна только репликация в итоге. Ручное управление volume, что не очень удобно.

                    wZD — это не ФС и не объектное хранилище, а упаковщик мелочи по сути, после реализации дистрибьютора(возможностей кластерной фс) будет возможна репликация и аналоги raid-10, raid-60. То есть можно будет записывать и распределять именно части файлов по нодам wZD. В режиме типа raid-10 запись и чтение будут расти линейно — чем больше нод тем быстрее, главное чтобы сеть и CPU были мощные, фактически части будут записываться параллельно и так же считываться параллельно.

                    Рассчитано универсально на большие и маленькие файлы и даже как на обычный NoSQL, в отличие от SeaWeedFS.

                    В режиме типа raid-10 возможен будет вариант JBOD + реплика, то есть файлы можно будет делить и на 4 части + 4 реплики и на 8 частей + 8 реплик? а не только на 2 части + 2 реплики. Самым сложным будет реализовать Reed-Solomon, например 8 частей + 2 части четности, чтобы общее потребление дискового пространства по нодам было 125% а не 200%. Ну это конечно сейчас всё еще не реализовано, планирую за год сделать +-.

                    А пока можно отлично использовать с текущими кластерными фс. Полноценный мануал как использовать с кластерными фс, включая настройку самих фс будет сделан по ходу дела. Сейчас это всего лишь базовый релиз у меня, не стоит ждать что все фишки в нем появятся моментально.
                      +1
                      SeaWeefFS — это уже ФС, запись быстрая, чтение медленнее, рассчитана только на маленькие файлы и только. В его фс возможна только репликация в итоге. Ручное управление volume, что не очень удобно.


                      Вас точно в заблуждение не ввели буквы FS в конце названия?
                      То что расчитана на маленькие файлы и большие не так эффективно хранит — это да.

                      Но что подразумевается под «ручным управлением»? И от куда про медленное чтение?
                      Почему у вас оно быстрое, а в SeaWeedFS оно меделенное?
                        0
                        Ну по сути это и есть ФС, ведь у нее полноценные Volume ограниченные в 32GB, вот откуда управление волюмами берется, я может конечно пропустил что-то, возможно она автоматом создает дополнительные волюмы, тогда простите за ошибочное восприятие документации.

                        Чтение одинаковое +-, я имел ввиду, так как тема ушла именно в сторону полноценной кластеризации, что у него возможны только реплики, то есть файл читается полностью, но у него нету разбития файла по частям, то что будет в моем дистрибьюторе, а тогда будет возможно параллельно читать/записывать части файла, чтобы было линейное масштабирование чтения — больше нод, мощнее сеть = быстрее.

                        Разговор здесь шел в основном о дистрибьюции, но она не реализована у меня пока еще. Забыл добавить ключевое слово «будет».
                      0
                      По своей сути если так проще будет, то у меня волюмы это bolt архивы для мелочи. И их может быть динамически очень много в итоге, нет жесткого управления волюмами. И так же в них не помещаются большие файлы, зачем их туда паковать?

                      Именно это корень зла всех объектных хранилищ, невозможно эффективно совместить много маленького и много большого. В MooseFS нещадно кушается память если у вас много-много файлов. Чтобы она быстро работала, как пример, в ее памяти много миллионов массивчиков живет с инфой о файликах.

                      wZD на данный момент призван значительно расширить возможности обычных кластерных фс, разгрузив их от мелочи.

                      В дальнейшем, после реализации собственного дистрибьютора, в бекендах wZD будет дополнительно подсчитываться в фоне CRC контрольная сумма для больших отдельных файлов и их частей, и так же проверяться в фоне. Но на лету при выдаче готового файла проверка вестись уже не будет, так как файл большой, это сильно замедлит чтение. Будет достаточно фонового процесса защиты от bit rot для маленьких файлов в болтах и больших файлов или их частей. Для маленьких файлов проверка CRC на лету останется при выдаче этих файлов.
                    +1

                    На выходе изобретете цеф. Так как нужен периодический скрабинг для проверки, репликация и тп

                      –1
                      Нет не Сeph, всё попроще. А обход для выявления bit rot сделан уже во всех современных фс и объектных хранилищах. Да и эту процедуру легко написать, это не трудоемко, даже в многопоточном варианте.

                      Восстановление реплики тоже сделано везде.

                      Сам wZD останется универсальным. Собственный дистрибьютор будет полностью отдельным сервисом.

                      Таким образом wZD можно будет использовать как на существующих обычных или кластерных файловых системах с дополнительно включенной встроенной bit rot проверкой своих файлов, там где это надо, так и с собственным кластерным дистрибьютором. Так что любой вариант на выбор.
                      0
                      Я не уловил, если клиенту нужен 1 маленький файл, он получает взамен архив с 1000?
                      Или это все делается на уровне сервера? Не очень расточительно распаковывать архив с 1000 ради одного?
                        0
                        Нет конечно, кому тогда нужно такое решение.
                        Вытаскивется именно 1 файлик всегда, а если метод HEAD или OPTIONS, или GET + Range: bytes=..., то читается вообще только заголовок или диапазон байт из конкретного файлика или значения, даже не целый файлик из архива.
                          +1
                          то читается вообще только заголовок или диапазон байт из конкретного файлика или значения, даже не целый файлик из архива

                          А вы уверены что с точки зрения диска вы не читаете весь файл архива?
                            0
                            Уверен и протестировал, потому что я и модифицировал сам код BoltDB, чтобы работало именно так как надо.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое