Доставки куда? Если сервис упал, то что толку от этих сообщений в кафке? Вы потом будете чесать репу и думать как обработать сообщения вручную? А проигнорировать ошибку и при синхронном взаимодействии никто не мешает.
Я заметил что в некоторых организациях упавший сервис, проблемы с перфомансом или не работающее приложение считается в порядке вещей. Но это конечно не так.
А почему в Кафку? Асинхронное взаимодействие хорошо только там, где без него действительно никак. По-умолчанию, всегда надо использовать RPC. Асинхронщина убивает перформанс и сильно запутывает разработку, отладку и траблшутинг.
Взаимодействие через БД создаёт проблему, что очень сложно модифицировать БД которую используют несколько команд. Для этого собственно и придумали микросервисы - одна база одна команда, за неё отвечающая
Какая-то на редкость неактуальная статья. В Китае кризис перепроизводства, электрические машины не могут продать, цены на литий падают и литиевые шахты закрываются
И в это же самое время мы пишем про светлое будущее электромобилей. Я рекомендую подобным умникам вложить все свои деньги в литий и Теслу.
Есть ещё один способ правильно оценить сроки - работает на ура. Дать сутки на то чтобы вникнуть в суть проблемы, разобраться с требованием и прикинуть, как решать задачу. Понятно, что если кто-то пытается за 15 минуть оценить задачу хоть в поинтах, хоть в попугаях, то это всё равно что ткнуть пальцем в небо.
Что касается T-shape, то есть вещи которые обязан знать любой разработчик. Для Java это будет Java, maven/gradle, Spring. Также все бэкэнд разработчики должны хорошо разбираться в сетях, linux, реляционных БД.
Те кто имеет пробелы в базовых вещах - пусть доучиваются
Каждый раз, как только речь заходит о налогах, обязательно вылезает какой-нибудь индивид с нулевым знанием о бухгалтерии и начинает сравнивать суммарно все налоги, которые существуют в РФ с подоходным налогом в какой-то другой стране.
То ли в школе не учили что апельсины надо сравнивать с апельсинами, а яблоки с яблоками, толи боты пишут под копирку - не поймёшь.
Мне кажется, вы слишком большой упор на квалификацию делаете. Действительно хороших инженеров не очень много, но ведь точно так же и хороших компаний, куда имеет смысл идти, не так много. Оба фактора друг друга нейтрализуют
Сам писал небольшой сервис по выгрузки данных из Kafka в S3 в parquet формате. Поэтому не понимаю зачем вам Spark для такой простой задачи. У вас какие-то сложные преобразования в процессе происходят?
В статье делается обзор in memory СУБД класса key-value
Ну ОК. Я лично увидел в этом недостаток статьи и некую недосказанность
Я прекрасно понимаю разницу между понятиями premature optimization и performance enginering
Я тогда не понимаю, зачем вы упомянули premature optimization всуе.
Для проведения нагрузочного тестирования есть полноценные инструменты. Нагрузочное тестирование имеет смысл на длинных запусках, когда временем на разовое установление TCP-соединения можно пренебречь, ведь мы же не устанавливаем каждый раз TCP соединение при обращении к БД при чтении или записи ключа
И какой же инструмент даёт наносекундные латенси?? Так же непонятно почему вы решили что redis-cli каждый раз открывает новое соединение. Вы считаете разработчиков редиса некомпетентными?
У меня простой тупой вопрос: какая библиотека и при каких условиях даёт латенси в 100нс при обращении к редис.
Если для Вас тюнинг TCP стека - это пустой звук, то вероятно Вы либо не владеете этой предметной областью, либо Вам это просто не требуется в силу специфики Вашей работы и масштаба информационных систем и ПО, которое вы разрабатываете и поддерживаете. Советую, все же изучить хотя бы для развития компетенций и глубокого понимания работы сетевых протоколов.
Повторю вопрос к экспертам по тюнингу TCP стека: что надо сделать чтобы хотя бы на localhost-е достичь задержки в 100нс
sqlite - это совершенно иной класс БД и никак не может быть альтернативой Redis по следующим причинам:
Я прекрасно знаю что такое SQLite и работал с ней не меньше вашего. Совершенно не обязательно расписывать её особенности. Я привёл её в качества контрпримера к очевидно абсурдному утверждению, что якобы SQL-движок сам по себе "всё замедляет".
Если вы прочитаете мой самый первый комментарии то увидите замечания, которые вы так и не смогли опровергнуть:
Цифры нарисованные на пирамиде высосаны из пальца и не соответствуют действительности чуть менее чем полностью
ценность этой БД для кэширования весьма ограничена и может быть оправдана в весьма специфичных случаях.
Рассчитывать что редис будет обрабатывать операции скопом - странная идея, ибо редис больше предназначен для быстрых и мелких операций: локи, распределённые счётчики и пр. Пакетная обработка больших объёмов чаще упирается в оборудование, чем в софт.
premature optimization - это одна из самых топовых плохих практик в программной инженерии. Обмазать все кэшированием там где надо и не надо в совокупности с непониманием как пользоваться инструментом - это путь к "успеху"
Вы, очевидно, не понимаете разницу между premature optimization и performance enginering-ом. Ну об этом ниже.
Конечно Вы правы, что в БД существуют инструменты внутреннего кэширования, но они достаточно примитивные и не всегда подходят под конкретные сценарии, а самое главное они неуправляемые, т.к. это для вас черный ящик.
У что у нас прям много возможностей повлиять на кеширование в редисе? По-поводу примитивности это ещё надо обосновать.
Да, действительно зачастую вполне достаточно использовать простенький LRU кэш на уровне приложения, а полноценный распределенный кэш на базе Redis будет избыточен.
Кэш может быть простенький, а может быть сложненький. Но если он на основе редиса, то придётся пожертвовать производительностью.
Среда запуска проходит тонкий тюнинг в части сетевого стека (selective acks, window scaling, congestion control, tw recycle, syn cookies, размеры буферов и многое другое), threaded io
Много буков, часть из которых не влияет на вызов к localhost-у, а часть не влияет на латенси. Почему-бы вам не продемонстрировать сие просто скопируя вывод команды reis-cli --latency?
В статье приведена масса примеров реальных сценариев использования
И какай из них подразумевает батчинг и наносекундные задержки?
Объясните мне зачем в Key-Value базе нужен SQL, который несет лишь накладные расходы - парсинг, компиляция, выполнение...
Здесь мы видим типичный пример "premature optimization". Очевидно вы не мерили сколько конкретно длятся "накладные расходы".
А я вот, например, не поленился и померил на совершенно примитивной SQLite c in-memory таблицей
Вставка: 5.719 микросекунд Итерация: 0.315 микросекунд на запись Запрос по ключу: 1.301 микросекунд
Как мы видим, на не "высоко-оптимизированом оборудовании" эти ваши "накладные расходы" на 3 порядка ниже, чем сетевые задержки.
Однако, суть и основной посыл в том, что вы дробите длинную операцию на несколько атомарных вызовов для итерирования по курсору, каждый из которых неблокирующий.
Я думаю, здесь следует признать, что медленное и проблемное итерирование является очевидным недостатком этой БД. И если в этом возникает необходимость, есть смысл выбрать другую.
При анализе производительности информационных систем наиболее частой проблемой и узким местом является именно база данных и диск
Это далеко не всегда так. Я достаточно много занимался перформанс инжинирингом в предыдущей компании и могу сказать что проблем с производительностью, вызванных злоупотреблением редиса, было намного больше чем от "медленных баз данных" или от кривых индексов. После замены редиса на локальные кэши производительность серьёзно возрастала. Это во-первых.
Во-вторых, с чего вы вообще решили, что при запросе одних и тех же данных базы данных будут дёргать диск? Они и так всё кэшируют в памяти. Не надо считать разработчиков баз данных идиотами.
И для этого идеально подходит кэш.
Кэш может и подходит, но не на основе редиса, он почти всегда слишком медленный для этого.
нет смысла городить свой доморощенный кэш на уровне приложению.
Я нигде не упоминал, что надо писать доморощенный кэш, не понимаю откуда вообще возникла подобная мысль. Вы всегда пишете свой кэш когда надо что-то закэшировать?
Обычно мы работаем с Redis с откликом как раз в диапазонах от 100 нс до 10 мкс.
Раскажите, как вы это делаете. Даже простой пинг будет выполняться дольше чем 100нс. Запускаем редис на линуксе. Затем на том же инстансе запускаем latency check. На моём лаптопе выдаёт 0.12 ms. Вот вам те же цифры со стек оверфлоу Я вас уверяю, что доступ к редису из производительной клиентской библиотеки (Jedis) будет иметь примерно такое же латенси.
Не понимаю ваш отсыл к SSD. Диск точно не заменит Redis как инструмент)
Да у вас просто все цифры неверные и запутывают читателя.
Я не писал про сценарий кэширования и батчинг в одном контексте.
Я бы предложил представить хоть сколько-нибудь реалистичные сценарии использования этой БД и от этого отталкиваться.
И не соглашусь, что SQL удобен в 100% случаев.
Для сравнения можно использовать популярные базы. Вы выбрали непопулярные.
Однако, суть и основной посыл в том, что вы дробите длинную операцию на несколько атомарных вызовов для итерирования по курсору, каждый из которых неблокирующий
Дробление улучшает latency, но делает throughput даже хуже. Основной посыл должен был бы быть, что обе операции вообще лучше избегать
Я не утверждал, что Redis используется исключительно для кэширования. Этот сценарий является одним из самых популярных, наряду с другими.
Мы использовали его для кеширования очень медленных операций - вызов third-party API. Кеширование редисом данных с высокопроизводительной БД почти наверняка будет бессмысленным. Для таких вещей годятся только локальные кэши
redis-cli --latency замеряет общую производительность, которая состоит из ряда фаз - сеть и установление TCP-соединения, THP latency, disk io latency если включен AOF, fork latency для RDB снэпшотов и т.д..
Ну вот видите, вы просто взяли самую быструю фазу и почему выдали её за конечную латенси, которая на практике никогда не будет достижима.
А визуальная пирамида дана для упрощенного и обобщенного представления о производительности различных компонентов и простоты восприятия этой информации
Эта пирамида только вводит в заблуждение: операции с SSD всегда будут быстрее, если только редис не находится на том же хосте. Указанные цифры совершенно нереалистичны, как для редиса так и SSD. PostgreSQL показан невероятно медленным, хотя SQL базы точно так же могут использовать in-memory таблицы.
Конечно, вы можете возразить, что сеть "съедает" все преимущество, но для этого есть pipelining.
Конечно сеть съедает все преимущества. Почему, кстати, в случае с SSD вы "pipelining" тупо проигнорировали? Указанные цифры для диска явно занижены, даже если мы пишем по одному байту.
Замер на единичной операции при которой тот же redis-cli потратит основное время на установку TCP-соединения абсолютно не имеет смысла.
Выше вы писали про кеширование, но в этом случае про какой batching может идти речь? Если же у нас тяжёлая пакетная обработка данных, то зачем нам вообще Redis? Читаем 100M c одного источника, 100M - с другого, как-то обрабатываем в оперативной памяти и выплёвываем в третий. Мне почему-то кажется что Redis - это больше про маленькие и быстрые операции (например rate limiting), чем про большие и жирные.
И, наконец, почему нет сравнения с SQL базам c in-memory движком/таблицами? Хотелось бы хотя бы иметь представление насколько игра стоит свеч, учитывая, что SQL-базы удобнее.
Между командами SCAN и KEYS нет разницы в алгоритмической сложности, если надо пройтись по всем ключам.
Утверждение, что редис используется в основном для кэша, высосано из пальца. Для кэша он как раз не особо полезен.
латенси операции в 100 ns не соответствует действительности. В этом легко убедиться выполнив redis-cli --latency на любом инстансе
Кэш на файловой системе будет быстрее редиса (но не будет распределённым). Намёк на то, что редис быстрее SSD, не соответствует действительности.
группировать команды можно только в том случае, если алгоритм работы с редис это позволяет. Пакетная обработка, разумеется, помогает не только с редисом, но и с любой другой БД. Тут вопрос скорее в эффективности алгоритмов вашего приложения.
Делать свою файловую систему даже и не пытались, и для наших задач POSIX совместимая файловая система явно бессмысленный оверхед
Это вы опрос среди разработчиков провели: что им нужно, а что нет?
По своему опыту с дата процессингом могу сказать: атомные операции и локи - это необходимость, симлинки и хардлинки - весьма желательно, листинг 25 миллионов объектов - никому не нужная блажь.
При этом S3 хранилище является сейчас стандартом для большей части как коммерческих, так и OpenSource решений (PostgreSQL, Clickhouse, Prometheus, Gitlab, Allure TestOps, ...)
С какой это поры S3 хранилище стало стандартом для PostgeSQL?? Про остальные вышеупомянутые системы - тоже весьма сомнительное утверждение.
строить систему хранения компании на единой платформе
Как можно построить систему хранения на платформе, которая не является универсальной? Вы же не будете базы данных в S3 хранить?
Ну и отвечая на вопрос - GlusterFS, SeaweedFS и прочие не смотрели, по ряду причин: на больших масштабах смущает уровень зрелости
Вы серьёзно считаете, что ваше самописное решение более зрелым чем GlusterFS, существующий уже много лет?
Не вы первые и не вы последние сталкиваетесь с хранением больших объёмов данных. Условный Lustre вполне успешно используется в суперкомпьютерах, а вам почему-то не хватает производительности.
В смысле? Просто монтируете как файловую систему со всеми POSIX плюшками: атомными операциями, локами, правами и пр. Зачем для доступа к неструктурированным данным городить S3? Тем более это - нестандартный протокол и вне контекста AWS малополезен.
Даже если вы свою файловую систему написали, то всё равно разумнее к ней fuse драйвер сделать, чем вкорячивать непонятный API.
Вполне допускаю, что вам зачем-то необходимо S3 хранилще. Но из данной статьи совершенно непонятно - зачем.
То есть сама идея обращаться к собственному хранилищу через S3 вызывает вопросы.
Отдельно порадовала невозможно сделать листинг из 25.000.000 объектов. Ну попробуйте хотя бы в RamFS такой фокус провернуть. Если у вас часто возникает необходимость делать листинг по всему хранилищу, то что-то у вас не так с алгоритмами.
Доставки куда? Если сервис упал, то что толку от этих сообщений в кафке? Вы потом будете чесать репу и думать как обработать сообщения вручную? А проигнорировать ошибку и при синхронном взаимодействии никто не мешает.
Я заметил что в некоторых организациях упавший сервис, проблемы с перфомансом или не работающее приложение считается в порядке вещей. Но это конечно не так.
А почему в Кафку? Асинхронное взаимодействие хорошо только там, где без него действительно никак. По-умолчанию, всегда надо использовать RPC. Асинхронщина убивает перформанс и сильно запутывает разработку, отладку и траблшутинг.
Взаимодействие через БД создаёт проблему, что очень сложно модифицировать БД которую используют несколько команд. Для этого собственно и придумали микросервисы - одна база одна команда, за неё отвечающая
А что не так с расположением элементов?
Я считаю, что Windows XP обладал самым красивым десктопом. Так что сравнение с ним - это скорее комплимент.
У иранцев, как мне рассказывали, оливье готовится по традиционному советскому рецепту с горошком и колбасой и многими считается национальным блюдом
Какая-то на редкость неактуальная статья. В Китае кризис перепроизводства, электрические машины не могут продать, цены на литий падают и литиевые шахты закрываются
И в это же самое время мы пишем про светлое будущее электромобилей. Я рекомендую подобным умникам вложить все свои деньги в литий и Теслу.
Мой опыт совершено другой: оценка данная за 15 минут не стоит ничего
Есть ещё один способ правильно оценить сроки - работает на ура. Дать сутки на то чтобы вникнуть в суть проблемы, разобраться с требованием и прикинуть, как решать задачу. Понятно, что если кто-то пытается за 15 минуть оценить задачу хоть в поинтах, хоть в попугаях, то это всё равно что ткнуть пальцем в небо.
Что касается T-shape, то есть вещи которые обязан знать любой разработчик. Для Java это будет Java, maven/gradle, Spring. Также все бэкэнд разработчики должны хорошо разбираться в сетях, linux, реляционных БД.
Те кто имеет пробелы в базовых вещах - пусть доучиваются
это прекрасно и в Windows (и MacOS) работает (как и ncdu).
Вы, очевидно, путаете ядро операционной системы и системные утилиты. Линус эти утилиты не писал и строго говоря с линуксом они никак не связаны.
Cinnamon с Windows XP темой - вполне красиво я считаю.
Каждый раз, как только речь заходит о налогах, обязательно вылезает какой-нибудь индивид с нулевым знанием о бухгалтерии и начинает сравнивать суммарно все налоги, которые существуют в РФ с подоходным налогом в какой-то другой стране.
То ли в школе не учили что апельсины надо сравнивать с апельсинами, а яблоки с яблоками, толи боты пишут под копирку - не поймёшь.
Мне кажется, вы слишком большой упор на квалификацию делаете. Действительно хороших инженеров не очень много, но ведь точно так же и хороших компаний, куда имеет смысл идти, не так много. Оба фактора друг друга нейтрализуют
Сам писал небольшой сервис по выгрузки данных из Kafka в S3 в parquet формате. Поэтому не понимаю зачем вам Spark для такой простой задачи. У вас какие-то сложные преобразования в процессе происходят?
Ну ОК. Я лично увидел в этом недостаток статьи и некую недосказанность
Я тогда не понимаю, зачем вы упомянули premature optimization всуе.
И какой же инструмент даёт наносекундные латенси?? Так же непонятно почему вы решили что redis-cli каждый раз открывает новое соединение. Вы считаете разработчиков редиса некомпетентными?
У меня простой тупой вопрос: какая библиотека и при каких условиях даёт латенси в 100нс при обращении к редис.
Повторю вопрос к экспертам по тюнингу TCP стека: что надо сделать чтобы хотя бы на localhost-е достичь задержки в 100нс
Я прекрасно знаю что такое SQLite и работал с ней не меньше вашего. Совершенно не обязательно расписывать её особенности.
Я привёл её в качества контрпримера к очевидно абсурдному утверждению, что якобы SQL-движок сам по себе "всё замедляет".
Если вы прочитаете мой самый первый комментарии то увидите замечания, которые вы так и не смогли опровергнуть:
Цифры нарисованные на пирамиде высосаны из пальца и не соответствуют действительности чуть менее чем полностью
ценность этой БД для кэширования весьма ограничена и может быть оправдана в весьма специфичных случаях.
Рассчитывать что редис будет обрабатывать операции скопом - странная идея, ибо редис больше предназначен для быстрых и мелких операций: локи, распределённые счётчики и пр.
Пакетная обработка больших объёмов чаще упирается в оборудование, чем в софт.
Вы, очевидно, не понимаете разницу между premature optimization и performance enginering-ом. Ну об этом ниже.
У что у нас прям много возможностей повлиять на кеширование в редисе? По-поводу примитивности это ещё надо обосновать.
Кэш может быть простенький, а может быть сложненький. Но если он на основе редиса, то придётся пожертвовать производительностью.
Много буков, часть из которых не влияет на вызов к localhost-у, а часть не влияет на латенси. Почему-бы вам не продемонстрировать сие просто скопируя вывод команды reis-cli --latency?
И какай из них подразумевает батчинг и наносекундные задержки?
Здесь мы видим типичный пример "premature optimization". Очевидно вы не мерили сколько конкретно длятся "накладные расходы".
А я вот, например, не поленился и померил на совершенно примитивной SQLite c in-memory таблицей
Вставка: 5.719 микросекунд
Итерация: 0.315 микросекунд на запись
Запрос по ключу: 1.301 микросекунд
Как мы видим, на не "высоко-оптимизированом оборудовании" эти ваши "накладные расходы" на 3 порядка ниже, чем сетевые задержки.
KeyDB
Я думаю, здесь следует признать, что медленное и проблемное итерирование является очевидным недостатком этой БД. И если в этом возникает необходимость, есть смысл выбрать другую.
Это далеко не всегда так. Я достаточно много занимался перформанс инжинирингом в предыдущей компании и могу сказать что проблем с производительностью, вызванных злоупотреблением редиса, было намного больше чем от "медленных баз данных" или от кривых индексов. После замены редиса на локальные кэши производительность серьёзно возрастала. Это во-первых.
Во-вторых, с чего вы вообще решили, что при запросе одних и тех же данных базы данных будут дёргать диск? Они и так всё кэшируют в памяти. Не надо считать разработчиков баз данных идиотами.
Кэш может и подходит, но не на основе редиса, он почти всегда слишком медленный для этого.
Я нигде не упоминал, что надо писать доморощенный кэш, не понимаю откуда вообще возникла подобная мысль. Вы всегда пишете свой кэш когда надо что-то закэшировать?
Раскажите, как вы это делаете. Даже простой пинг будет выполняться дольше чем 100нс.
Запускаем редис на линуксе. Затем на том же инстансе запускаем latency check. На моём лаптопе выдаёт 0.12 ms. Вот вам те же цифры со стек оверфлоу
Я вас уверяю, что доступ к редису из производительной клиентской библиотеки (Jedis) будет иметь примерно такое же латенси.
Да у вас просто все цифры неверные и запутывают читателя.
Я бы предложил представить хоть сколько-нибудь реалистичные сценарии использования этой БД и от этого отталкиваться.
Для сравнения можно использовать популярные базы. Вы выбрали непопулярные.
Дробление улучшает latency, но делает throughput даже хуже.
Основной посыл должен был бы быть, что обе операции вообще лучше избегать
Мы использовали его для кеширования очень медленных операций - вызов third-party API.
Кеширование редисом данных с высокопроизводительной БД почти наверняка будет бессмысленным. Для таких вещей годятся только локальные кэши
Ну вот видите, вы просто взяли самую быструю фазу и почему выдали её за конечную латенси, которая на практике никогда не будет достижима.
Эта пирамида только вводит в заблуждение: операции с SSD всегда будут быстрее, если только редис не находится на том же хосте.
Указанные цифры совершенно нереалистичны, как для редиса так и SSD.
PostgreSQL показан невероятно медленным, хотя SQL базы точно так же могут использовать in-memory таблицы.
Конечно сеть съедает все преимущества. Почему, кстати, в случае с SSD вы "pipelining" тупо проигнорировали? Указанные цифры для диска явно занижены, даже если мы пишем по одному байту.
Выше вы писали про кеширование, но в этом случае про какой batching может идти речь? Если же у нас тяжёлая пакетная обработка данных, то зачем нам вообще Redis? Читаем 100M c одного источника, 100M - с другого, как-то обрабатываем в оперативной памяти и выплёвываем в третий. Мне почему-то кажется что Redis - это больше про маленькие и быстрые операции (например rate limiting), чем про большие и жирные.
И, наконец, почему нет сравнения с SQL базам c in-memory движком/таблицами? Хотелось бы хотя бы иметь представление насколько игра стоит свеч, учитывая, что SQL-базы удобнее.
Между командами SCAN и KEYS нет разницы в алгоритмической сложности, если надо пройтись по всем ключам.
Утверждение, что редис используется в основном для кэша, высосано из пальца. Для кэша он как раз не особо полезен.
латенси операции в 100 ns не соответствует действительности. В этом легко убедиться выполнив redis-cli --latency на любом инстансе
Кэш на файловой системе будет быстрее редиса (но не будет распределённым). Намёк на то, что редис быстрее SSD, не соответствует действительности.
группировать команды можно только в том случае, если алгоритм работы с редис это позволяет. Пакетная обработка, разумеется, помогает не только с редисом, но и с любой другой БД. Тут вопрос скорее в эффективности алгоритмов вашего приложения.
Да, вы правы. Под Ceph я подразумевал CephFS.
Это вы опрос среди разработчиков провели: что им нужно, а что нет?
По своему опыту с дата процессингом могу сказать: атомные операции и локи - это необходимость, симлинки и хардлинки - весьма желательно, листинг 25 миллионов объектов - никому не нужная блажь.
С какой это поры S3 хранилище стало стандартом для PostgeSQL?? Про остальные вышеупомянутые системы - тоже весьма сомнительное утверждение.
Как можно построить систему хранения на платформе, которая не является универсальной? Вы же не будете базы данных в S3 хранить?
Вы серьёзно считаете, что ваше самописное решение более зрелым чем GlusterFS, существующий уже много лет?
Не вы первые и не вы последние сталкиваетесь с хранением больших объёмов данных.
Условный Lustre вполне успешно используется в суперкомпьютерах, а вам почему-то не хватает производительности.
В смысле? Просто монтируете как файловую систему со всеми POSIX плюшками: атомными операциями, локами, правами и пр. Зачем для доступа к неструктурированным данным городить S3? Тем более это - нестандартный протокол и вне контекста AWS малополезен.
Даже если вы свою файловую систему написали, то всё равно разумнее к ней fuse драйвер сделать, чем вкорячивать непонятный API.
Вполне допускаю, что вам зачем-то необходимо S3 хранилще. Но из данной статьи совершенно непонятно - зачем.
То есть сама идея обращаться к собственному хранилищу через S3 вызывает вопросы.
Отдельно порадовала невозможно сделать листинг из 25.000.000 объектов. Ну попробуйте хотя бы в RamFS такой фокус провернуть. Если у вас часто возникает необходимость делать листинг по всему хранилищу, то что-то у вас не так с алгоритмами.
Про гластер так ничего и не написали.