Алексей
minio как вариант
🦠
minio тот же aws s3)
Алексей
Только локальный :-)
Grigory
🦠
ваще хранение блобов в БД это самый жесткий антипаттерн
🦠
после превращения бд в процессор очередей или процессинга кроном гигабайтных выборок)
Grigory
зависит от бд; скажем в хбейзе хранить блобы это норм
Grigory
или в почти любой "большой таблице"
🦠
ну удачи с индексатором)))
🦠
или обычной выборкой через *
🦠
кто захлебнется раньше - disk io или network io
Grigory
Etki
а обязательно ФС? в какой-нибудь монге или кассандре блобы хранить тоже можно
(Проголосую против такого решения)
Etki
потому что файлы и данные - это разные сущности
Etki
реплицировать это всё тоже то еще веселье
SmilingPanda
#whois Большой проект в банковской сфере. Фронт, девопс немного бэк. Спрашивайте. Изучаю кубер. Дефолтсити. Гугл.
Всем привет.
SmilingPanda
Вопрос селдующий - только начинаю разбираться с сабжом. Задача такая - есть сервера, около 100, надо на каждый развернуть какие-то докер контейнеры, но у каждого под каждый сервер - свои настройки (из гита, либо дефолтные общие). Подходит ли кубер для этого?
G72K
потому что файлы и данные - это разные сущности
вы думаете в S3 фаши "файлы" как файлы хрянятся? :))
G72K
обычное ключ-значение, где ключ это путь до файла
G72K
реплицировать это всё тоже то еще веселье
с репликацией все эти распределенные базы как раз справляются
Grigory
господа а hdfs бд или не?
Grigory
Grigory
а вот есть accumulo, поврех хдфс
Grigory
селл секурити все дела
Grigory
размер ячейки экзобайт
G72K
не блобами внутри бд
судя по гарантиям консистентности S3 там все точно так же как в Cassandra.
Grigory
типа бд ну и там видать экзобайт и блобы вообще нельзя?
Etki
это не значит, что там кто-то хранит данные внутри бд
Etki
давайте сначала в кассандру завезем error code correction
G72K
Вообще что от хранилища надо? придти к координатору, сказать хочу файл, координатор посчитает хэш, пошлет на ноду хранения (или сам пойдет), нода хранения спросит "тебе чего?" ответ "хэш такойто", "ну держи". чем не cassandra
Etki
а гарантии консистентности там тупо LWW + когда доедет, тогда доедет
Etki
тем, что кассандра будет еще по всем SST собирать запись
G72K
давайте сначала в кассандру завезем error code correction
это вопрос приложения. что положите в блоб то и будет. можно рядом и метадату и чексумы
Etki
и я посмотрю как у вас блоб с десятком версий будет собираться
G72K
какие ваши доказательства?
тем что ключ это partition key, т.е просто ключ в sst. из множества локальных sst кассанда быстро выберет те, что с блобом, т.к. блум фильтры есть на всех sst
Etki
так блоб-то не один
Etki
ты один раз записал, потом перезаписал
Etki
если версия меняет партишен кей, то как я потом эту запись достану, не зная наперед версии?
Gleb
Etki
то что один раз записалось - будет жить до компакта
Etki
и компакт с большими записями тоже будет всех радовать
G72K
то что один раз записалось - будет жить до компакта
прошлые версии официальным API разве можно достать?
Grigory
у них своя схема разбиения
Grigory
можно посомтреть в java sdk - TransferManager - там оптимизированый аплоад и даунлоад в файлы
Etki
какая разница можно или нельзя? SST пишется один раз, если я записал новую версию данных, старая никуда не делась
G72K
и компакт с большими записями тоже будет всех радовать
поскольку нету обновлелний записей, все компакты это просто копирования кучи sst в один
Etki
почему нет обновлений записей?
Grigory
и по моим перформанс тестам - картиночки хранятся в S3 - пробелма возникает в IO именно с маенькими файлами
Grigory
т.е. S3 приятнее все же с файлами побольше чем по 250кб работать
G72K
почему нет обновлений записей?
потому что новая версия новый ключ (это если версионирование видимое клиенту включено). если отключено, то да будут мерджи, но никто от хранилища блобов не ожидает сотен перезаписей в секунду)
Etki
никто от хранилища блобов не ожидает хранения старых записей при отключенном версионировании
Etki
и снова к тому же вопросу - если новая версия подразумевает новый партишен кей, то как можно получить последнюю версию, не зная ее порядковый номер?
G72K
никто от хранилища блобов не ожидает хранения старых записей при отключенном версионировании
как другие хранилища делают? перезаписывают на лету?
Etki
тут цефовики лучше ответят
Etki
но если на документ в среднем приходится десять обновлений, то вот этот вариант будет жрать размер документов * фактор репликации * 5
G72K
и снова к тому же вопросу - если новая версия подразумевает новый партишен кей, то как можно получить последнюю версию, не зная ее порядковый номер?
есть метадата по пути файла (тоже ключ), в ней можно хранить историю. точно так же как в S3 list хранит информацию о "директории" неизвестно насколько устаревшую by design
Etki
that's great
Etki
таким образом надо уже минимум две записи проскакать, чтобы начать что-либо читать
Etki
я уж молчу про то, что версионирование в eventual consistency вообще не впишется и без LWT будет очень сложно
G72K
но если на документ в среднем приходится десять обновлений, то вот этот вариант будет жрать размер документов * фактор репликации * 5
мне кажется все пришли к тому, что б писать рядом, а потом разбираться что главнее. блобы потому в mysql/postgresql и плохо хранить, потому что там каждая запись перезаписывается поверх (ну почти :) ) ,а это дорого
G72K
таким образом надо уже минимум две записи проскакать, чтобы начать что-либо читать
ну еще записи на права пользователй, еще записи о состояни региона, еще какие нибудь внутрнние записи и проч. одной никогда не обойтись если считать всё вместе
G72K
я уж молчу про то, что версионирование в eventual consistency вообще не впишется и без LWT будет очень сложно
цеф не дает версионирование, так? что-нибудь придумать можно и вы это знаете :)
Etki
понятия не имею что цеф дает
Etki
знаю только что он все-таки куда ближе по описываемому функционалу
Etki
и что кейс "ну давайте уже запихнем в кассандру" притягивается просто потому что в кассандру запихнуть интересно (и с этим я конечно спорить не могу)
G72K
и что кейс "ну давайте уже запихнем в кассандру" притягивается просто потому что в кассандру запихнуть интересно (и с этим я конечно спорить не могу)
нет кстати. правда думаю, что если брать любое готовое, то будет +- кассандра по сути. почистил зубы и решил, что пусть будут мерджи, зато никакой возни с метадатой отдельно
G72K
у всех этих кассандр фундаментальная проблема: нельзя терять больше чем N/2 нод. т.е. файктор репликации N == 5, то 3 ноды терять нельзя. при больших размерах как с этим справиться? Если надежность оборудования (не научные термин) 2%, то из 100 нод кластера 2 будут в отключке и того всё будет висеть не волоске :) при 200 нодах уже гарантировано все будет развалено постоянно. кто-то наверняка уже более умное что-то придумал
Etki
там не будет кассандры, потому что мерджить не надо вообще ничего
Etki
это не данные, это блобы, они заменяются целиком
Etki
кассандра может быть отрезанной от любого количества нод, пока координатор может достучаться хотя бы до одного владельца vnode, он произведет запись
Etki
когда кластер соберется, произойдет LWW-мердж