> Куда положить 250 млн картинок объемом 80 TB просто как пример? В какую еще базу?Ну, для меня решение из этой новости или всё тот же SeaWeedFS — тоже в определённом смысле СУБД. Так что база в этом смысле. Если что, я тут нигде не топил за ненужность сабжа, напротив, пишу о причинах по которым такие решения нужны и возникают.
> Кто утверждает, что такое количество допустим должно быть обязательно в фс общего
> назначения, про кластерные забыли?
Не суть, имелись в виду ФС, как бы так сказать, совместимые с POSIX-семантикой.
Которым противопоставляется специализированное решение, имеющее свои преимущества, в т.ч. за счёт отказа от всяких неиспользуемых функций.
> Вам дали способ - как упростить себе жизнь не изменяя файловую систему
> на какие-то решения, которые еще неизвестно как себя поведут (в плане фс
> изначально), в том числе оставлена без изменений работа с большими файлами,
> не надо заботится о волюмах, изменять пути в приложении, и прочие вещи.
Я же разве против? Наоборот, всецело за.
Разве что заботиться иногда всё-таки надо, это позволяет получить дополнительный выигрыш.
> Кстати на счет SeaWeedFS - вы писали там есть TTL, что может
> быть удобно в некоторых случаях. Я сделаю у себя такую поддержку.
Наверное, уточню: в моём случае протухание по TTL реализовано внешним скриптом (потому что логика выбора удаляемых файлов немного нетривиальная), который посылает пачку запросов на удаление. Залить несколько миллионов файлов, потом продолжать потихоньку заливать файлы, а потом через сутки 2% самых старых из них удалить пачкой запросов — суровый такой стресс-тест. Более-менее традиционные ФС на удалении десятков тысяч мелких файлов ооочень крепко задумываются (иногда подвешивая вообще все операции ввода-вывода, пока журнал не прокачается).
