откуда вы берете й в kubernetes? :3

из рудокера же

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

а обязательно ФС? в какой-нибудь монге или кассандре блобы хранить тоже можно

а обязательно ФС? в какой-нибудь монге или кассандре блобы хранить тоже можно

в монге блобы хранить нельзя

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

AWS S3

AWS S3

маленькие файлы плохо там лежат

в монге блобы хранить нельзя

Binary

Binary

если вы когда-нибудь планируете извлечь свои данные - в монго их хранить нельзя

ну вопрос же не об этом

вопрос именно в этом. Хранилище должно быть надежным, это его основное качество. Скорость, удобство использования и настройки – это уже по желанию. Но надежность – ключевой параметр

minio как вариант

minio тот же aws s3)

Только локальный :-)

вопрос именно в этом. Хранилище должно быть надежным, это его основное качество. Скорость, удобство использования и настройки – это уже по желанию. Но надежность – ключевой параметр

ее никто не советовал (я не советовал)

ваще хранение блобов в БД это самый жесткий антипаттерн

после превращения бд в процессор очередей или процессинга кроном гигабайтных выборок)

зависит от бд; скажем в хбейзе хранить блобы это норм

или в почти любой "большой таблице"

ну удачи с индексатором)))

или обычной выборкой через *

кто захлебнется раньше - disk io или network io

а обязательно ФС? в какой-нибудь монге или кассандре блобы хранить тоже можно

(Проголосую против такого решения)

(Проголосую против такого решения)

почему в кассандре блобы плохо

потому что файлы и данные - это разные сущности

реплицировать это всё тоже то еще веселье

#whois Большой проект в банковской сфере. Фронт, девопс немного бэк. Спрашивайте. Изучаю кубер. Дефолтсити. Гугл. Всем привет.

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

потому что файлы и данные - это разные сущности

вы думаете в S3 фаши "файлы" как файлы хрянятся? :))

обычное ключ-значение, где ключ это путь до файла

реплицировать это всё тоже то еще веселье

с репликацией все эти распределенные базы как раз справляются

вы думаете в S3 фаши "файлы" как файлы хрянятся? :))

не блобами внутри бд

господа а hdfs бд или не?

а вот есть accumulo, поврех хдфс

селл секурити все дела

размер ячейки экзобайт

не блобами внутри бд

судя по гарантиям консистентности S3 там все точно так же как в Cassandra.

типа бд ну и там видать экзобайт и блобы вообще нельзя?

это не значит, что там кто-то хранит данные внутри бд

давайте сначала в кассандру завезем error code correction

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

а гарантии консистентности там тупо LWW + когда доедет, тогда доедет

тем, что кассандра будет еще по всем SST собирать запись

давайте сначала в кассандру завезем error code correction

это вопрос приложения. что положите в блоб то и будет. можно рядом и метадату и чексумы

тем, что кассандра будет еще по всем SST собирать запись

не будет

и я посмотрю как у вас блоб с десятком версий будет собираться

не будет

какие ваши доказательства?

какие ваши доказательства?

тем что ключ это partition key, т.е просто ключ в sst. из множества локальных sst кассанда быстро выберет те, что с блобом, т.к. блум фильтры есть на всех sst

так блоб-то не один

ты один раз записал, потом перезаписал

так блоб-то не один

один. версия меняет partition key, и вот блоб уже один :)

ты один раз записал, потом перезаписал

в S3 это опционально

если версия меняет партишен кей, то как я потом эту запись достану, не зная наперед версии?

маленькие файлы плохо там лежат

А подробнее?

в S3 это опционально

в кассандре зато это принудительно

то что один раз записалось - будет жить до компакта

и компакт с большими записями тоже будет всех радовать

то что один раз записалось - будет жить до компакта

прошлые версии официальным API разве можно достать?

А подробнее?

ну S3 хранит тоже файлы "частями"

у них своя схема разбиения

можно посомтреть в java sdk - TransferManager - там оптимизированый аплоад и даунлоад в файлы

какая разница можно или нельзя? SST пишется один раз, если я записал новую версию данных, старая никуда не делась

и компакт с большими записями тоже будет всех радовать

поскольку нету обновлелний записей, все компакты это просто копирования кучи sst в один

почему нет обновлений записей?

и по моим перформанс тестам - картиночки хранятся в S3 - пробелма возникает в IO именно с маенькими файлами

т.е. S3 приятнее все же с файлами побольше чем по 250кб работать

почему нет обновлений записей?

потому что новая версия новый ключ (это если версионирование видимое клиенту включено). если отключено, то да будут мерджи, но никто от хранилища блобов не ожидает сотен перезаписей в секунду)

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

и снова к тому же вопросу - если новая версия подразумевает новый партишен кей, то как можно получить последнюю версию, не зная ее порядковый номер?

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

как другие хранилища делают? перезаписывают на лету?

тут цефовики лучше ответят

но если на документ в среднем приходится десять обновлений, то вот этот вариант будет жрать размер документов * фактор репликации * 5

и снова к тому же вопросу - если новая версия подразумевает новый партишен кей, то как можно получить последнюю версию, не зная ее порядковый номер?

есть метадата по пути файла (тоже ключ), в ней можно хранить историю. точно так же как в S3 list хранит информацию о "директории" неизвестно насколько устаревшую by design

that's great

таким образом надо уже минимум две записи проскакать, чтобы начать что-либо читать

я уж молчу про то, что версионирование в eventual consistency вообще не впишется и без LWT будет очень сложно

но если на документ в среднем приходится десять обновлений, то вот этот вариант будет жрать размер документов * фактор репликации * 5

мне кажется все пришли к тому, что б писать рядом, а потом разбираться что главнее. блобы потому в mysql/postgresql и плохо хранить, потому что там каждая запись перезаписывается поверх (ну почти :) ) ,а это дорого

таким образом надо уже минимум две записи проскакать, чтобы начать что-либо читать

ну еще записи на права пользователй, еще записи о состояни региона, еще какие нибудь внутрнние записи и проч. одной никогда не обойтись если считать всё вместе

я уж молчу про то, что версионирование в eventual consistency вообще не впишется и без LWT будет очень сложно

цеф не дает версионирование, так? что-нибудь придумать можно и вы это знаете :)

понятия не имею что цеф дает

знаю только что он все-таки куда ближе по описываемому функционалу

и что кейс "ну давайте уже запихнем в кассандру" притягивается просто потому что в кассандру запихнуть интересно (и с этим я конечно спорить не могу)

и что кейс "ну давайте уже запихнем в кассандру" притягивается просто потому что в кассандру запихнуть интересно (и с этим я конечно спорить не могу)

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

у всех этих кассандр фундаментальная проблема: нельзя терять больше чем N/2 нод. т.е. файктор репликации N == 5, то 3 ноды терять нельзя. при больших размерах как с этим справиться? Если надежность оборудования (не научные термин) 2%, то из 100 нод кластера 2 будут в отключке и того всё будет висеть не волоске :) при 200 нодах уже гарантировано все будет развалено постоянно. кто-то наверняка уже более умное что-то придумал

там не будет кассандры, потому что мерджить не надо вообще ничего

это не данные, это блобы, они заменяются целиком

у всех этих кассандр фундаментальная проблема: нельзя терять больше чем N/2 нод. т.е. файктор репликации N == 5, то 3 ноды терять нельзя. при больших размерах как с этим справиться? Если надежность оборудования (не научные термин) 2%, то из 100 нод кластера 2 будут в отключке и того всё будет висеть не волоске :) при 200 нодах уже гарантировано все будет развалено постоянно. кто-то наверняка уже более умное что-то придумал

откуда эта инфа?

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

когда кластер соберется, произойдет LWW-мердж

сори за оффтоп :) а чтобы создать сервис который будет роутить на внешние айпишники мне надо сначала эндпоинт вручную создать, а потом лейблами сервис к нему приписать… или в самом сервисе есть такая спецификация, а?

Service: spec.type=NodePort

не думаю что это поможет

Всем привет! Помогите пожалуйста решить проблему с ДНС в кубернете. поднял кластер, поднял куб-днс. в апи-сервере прописан сервис-днс на айпишник 10.3.0.254 куб-днс цепляется на этот айпишник своим сервисом. во все поды тыкался kebrctl logs - нигде ошибок не видать. но если тыкнуться в днс каким нибудь nslookup-ом то он не резолвит никакие поды((

Service: spec.type=NodePort

я наверно имел ввиду что-то вроде этого: apiVersion: v1 kind: Endpoints metadata: name: mongodb-external subsets: - addresses: - ip: 10.240.0.12 - ip: 10.240.0.13 - ip: 10.240.0.14 ports: - name: mongo port: 27017 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: mongodb-external spec: ports: - name: mongo protocol: TCP port: 27017

?