Comments 23
Уважаемый товарищ, чьи мыcли мы так и не поняли.
От этого уважаемого товарища в тот же день вышла другая статья, которая кстати, вам очень подходит.
Краткая её суть такая: если у вас маленькие файлы и вы всегда можете читать/писать их целиком, вы можете использовать key-value хранилище.
Когда у вас куча мелких файлов, важной проблемой становятся накладные расходы на поиск файла в ФС.
key-value хранилища эту проблему решают.
Рекомендую вам посмотреть в эту сторону.
Боюсь, что здесь в одну кучу смешиваются два вида хранилищ.
S3, Swift и прочие — это объектные хранилища.
А GridFS в MongoDB, как написано в доке — это вообще хранилище для больших файлов ("large files").
Они, конечно, размывают понятие "путь к файлу", но файл у них остается файлом.
Даниил же рассказывает про кластерную NoSQL СУБД.
Т.е., если очень упростить, они хранят файлы, как строки в хранилище типа redis.
Такой трюк можно сделать только с маленькими файлами и там он оправдан.
Поэтому я, как прочитал вашу статью, сразу вспомнил про статью от него.
Он упоминает Aerospike и судя по тестам, вашу задачу она решает быстро и надежно.
На первый взгляд кажется, что решение использовать файлы по соображениям производительности привело как раз к невозможности обеспечить эту самую производительность легким путем.
А для mc — написать vfs на питоне занимает 100 строчек. И будет редис на панелях с папками.
Сам redis использовать в таком месте не получится — он все хранит в оперативке и синхронизируется с диском. 6 ТБ данных туда засунуть проблематично. А ещё проблематичней будет эти данные сохранять на диск. Здесь нужен подход традиционных СУБД — хранить данные на диске и по максимуму использовать оперативку под кеширование.
Во-первых, спасибо за замечание, видимо я не совсем понятно выразился. Мысль была в том, что у нас было, грубо говоря, 2 пути: засунуть файлы в какую-нибудь базу и не засунуть. Понятно, что баз много, хороших и разных. Но нам бы тогда, повторюсь, пришлось переписывать весь код работы с файлами и менять подход к работе с ними, в том числе к их отдаче. Также напомню, что у нас разные ДЦ, т.е. непредсказуемая latency и весьма условный 1Gbps между нодами. Взвесив все «за» и «против» мы выбрали вариант без баз. Безусловно, у обоих вариантов есть недостатки и преимущества.
Вы предлагаете использовать FUSE? Посмотрите, автор привел объемы данных. Представляете накладные расходы на путешествия user — kernel — user на каждый чих?
FUSE-решения хороши, когда нужно сделать удобно, но о скорости там речи не идёт вообще. GlusterFS это наглядно показал.
Это не для работы в продакшене, это для отладки. (В статье упоминалось, что один из недостатков иметь данные в key-value storage по сравнению с файлами, — это невозможность ходить по структуре файлов в mc; в принципе, сам по себе аргумент достаточно сильный ИМХО — отладка очень важна.)
Но если есть недоверие к пингвину, можете посмотреть на FreeBSD. Есть мнение, что там оно роднее. Хотя, есть и другие мнения =)
docs.oracle.com/cd/E19253-01/820-0836/gbchx/
Честно — сами такое ещё не пробовали, но zfs крута и вполне может быть. Если теоретизировать, то механизм CoW должен позволять очень быстро получить набор изменений относительно снапшота. Тогда, если у вас изменения только на условном мастере и их относительно мало, то дифф будет небольшой, быстрый и накатить его на RO слейв не займет времени. Ну и плюс все остальные плюшки ZFS (про минусы тоже надо помнить!).
Как раз небольшым проектам нужно брать готовые решение и для этого есть пару аргументов.
1. Готовое решение имеет комьюнити и там всегда идет работа над уличением продукта.
2. Только используя готовое решение долгое время можно понять что действительно вам нужно. Чтоб потом когда вы станете крупным проектом со штатом в сотни программистов написать что-то свое пользуясь опытом других. И этим проектом будет занимать целый отдел а не один программист.
3. Как часто бывает у подобных самописных решений очень сложная кодовая база, очень сложная инфраструктура и точно у этого всего нет документации. Долгих лет Максиму. Но случись что с ним вы будете смотреть на страдание того кто это возметься поддерживать. А еще вы точно от него услышать что это все нужно переписать так как это чужой программный продукт и там кучу изъянов. И новая итерация самописного $#@ ПО
ИМХО. Не пишете свои велосипеды там где задачи стары как мир используйте готовое решение. А это задача именованием такая и решена уже сотнями способов под все случаи жизни.
Как пережить масштабирование и синхронизировать-таки всё между дата-центрами