DevOps без Dev, с какой стороны подступиться?

Кластеризуй мне PostgreSQL как Kafka?

Шардирование в постгресе? Не, не слышал

И кстати при чем тут кафка? Ты шину вместо хранилища решил юзать? Может еще и очереди там поджойнишь?

Админ наверное.

Прости, но чот я с трудом верю, что в РФ где-то есть такие цифры

Вообще я знаю как минимум одно место с такими цифрами, такое в рекламе бывает. И там действительно далеко не всегда реляционная база внизу. Но и не монга, это уж точно. Чаще какая-нибудь хитрая варка пачки read-only бинарей с закосом под базу на манер кликхауса

Шардирование в постгресе? Не, не слышал

И как там с распределением нагрузки и репликацией? Можно куски базы растаскивать по разным нодам, и иметь разную репликациию?

И кстати при чем тут кафка?

Кафка тут как пример хорошо масштабируемого кластеризуемого сервиса. Какие же вы предсказуемые.

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

Слив засчитан. Хотя мог бы просто сказать, что ты в этом ничего не понимаешь, ничего зазорного в этом нет.

Админ - это очень обощенно.

Спасибо за ответы, стало попонятнее.

Можно куски базы растаскивать по разным нодам, и иметь разную репликациию?

Это зачем такое может понадобиться и как должно работать? Типа у меня первые сто записей в таблице лежат в двух репликах, а вторые сто - в десяти других репликах? Или речь про таблицы? Или про схемы? Или как вообще?

Это не наезд если что, реально интересно что имеется ввиду, какой дает профит и как применяется.

Кафка тут как пример хорошо масштабируемого кластеризуемого сервиса

Прям твоими словами - и как там с распределением нагрузки и репликацией? Тебя не смущает что чтение и запись партиции идут с лидера, а остальные реплики по факту standby?

В постгресе репликация и баланс зависят от того что ты для этого использовал. XL например умеет и чтение, и запись балансировать

Обзови партицию шардом, возьми очередь в кафке и базу в постгресе/мускуле, закрой названия и внезапно модель репликации окажется невероятно близкой. У кафки есть плюшки типа бутстрапа и более простого перешардирования, но по факту модель различается не так сильно.

кидает понты

разбрасывается категорическими утверждениями

без единого пруфа

засчитывает кому-то сливы

ну да, ну да

Это зачем такое может понадобиться и как должно работать?

Еще один, не видевший хайлоада. Да затем, что подавится иначе железка, на которой RDBMS.

Прям твоими словами - и как там с распределением нагрузки и репликацией? Тебя не смущает что чтение и запись партиции идут с лидера, а остальные реплики по факту standby?

Ты так говоришь, будто это что-то плохое. Кафке можно брокеров натолкать ровно столько, сколько тебе нужно и сколько у тебя сеть выдержит и автоматизация позволит (да, добавить/убрать брокер на лету - это очень веселая задача, а железо иногда мрет).

У кафки есть плюшки типа бутстрапа и более простого перешардирования, но по факту модель различается не так сильно

См. выше. Имеем три десятка (на самом деле больше, но не суть) брокеров/шардов. Один из 30 помер аппаратно. Как относительно безболезненно привести кластер в порядок без даунтайма? С кафкой это прокатывает. С Aerospike прокатывает, хотя и сильно медленнее (но там и импакт меньше, чем на кафке). А вот как быть с постгрей?

Это не наезд если что, реально интересно что имеется ввиду, какой дает профит и как применяется.

Или у видевших хайлоады запрещено рассказывать что они там видели?

ну да, ну да

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

Или у видевших хайлоады запрещено рассказывать что они там видели?

Сложно объяснить папуасам устройство цветного телевизора на пальцах. Нет, я сейчас не к тому, что здесь все тупые, кто не видел хайлоада. Я к тому, что пока ты увидишь, ты не поймешь, насколько различаются принципиально требования. Технологии-то похожи, говно вопрос. Они просто для другого и по-другому применяются.

что я видел и чего не видел — вообще не твое дело. есть очень простая вещь: утверждения

масштабируемые аппы на RDBMS не делаются

и

Никакая высоконагруженная хорошо распараллеленная система на RDBMS работать не будет

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

как Kafka

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

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

Ясно, понятно.

Ну и ладно, просто мне чтоб знать куда развиваться, что такое хайлоад вообще?

что я видел и чего не видел — вообще не твое дело. есть очень простая вещь: утверждения

Раз не видел, значит понятия не имеешь. За ликбезом обратись к руководителю или на профильные курсы.

Ну и ладно, просто мне чтоб знать куда развиваться, что такое хайлоад вообще?

Тут камрады уже писали про такое понятие, как rps - то бишь requests per second. Хайлоад начинается где-то в районе ситуации, когда пиковая нагрузка на что-либо в rps значительно (в разы, а как правило - в десятки, сотни и тысячи раз) превышает способность отдельного, пусть и очень мощного сервера обслужить такое количество rps. Тут-то и начинается веселье с кластеризацией, балансерами, репликацией (ибо ноды мрут) и т.д.

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

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

Да. У меня по умолчанию длиннее.

тролли, тролли

кругом тролли

тролли троллят

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

Да. У меня по умолчанию длиннее.

учитывая, как много ты об этом говоришь, в том числе там, где тебя об этом не спрашивают — сомневаюсь. но это твое дело.

категорические заявления делать, которые ты обосновать не можешь

DevOps без Dev, с какой стороны подступиться? (комментарий)

Можно куски базы растаскивать по разным нодам, и иметь разную репликациию?

Нужно. У каждого шарда свои реплики.

Кафка тут как пример хорошо масштабируемого кластеризуемого сервиса. Какие же вы предсказуемые.

Mirrormaker передает привет. Кластеризация кафки это маркетинговый балшит, при более-менее серьезном размере датасета оно превращается в тыкву.

Если это не HFT то ты трындишь скорее всего.

Имеем три десятка (на самом деле больше, но не суть) брокеров/шардов. Один из 30 помер аппаратно. 

Имели два десятка реплицированных шардов/партиций перконы (мускуль на стероидах), если одна дохла - failover на реплику проходил без проблем

Ты так говоришь, будто это что-то плохое

чтение с одного только мастера это блин очень больно когда тебе надо чуть больше чем очередь. Либо у тебя будет экспорт нагрузки из хранилища в код

Есть аппы, работающие в микросекундных задержках

Сорри, свежо питание, но серится с трудом. За 1мкс свет проходит 300 метров. 100мкс - среднее время ответа ссд. 10мкс - среднее время ответа памяти. Если только твоё приложение не возвращает число 42 из кеша проца - задержки всё-таки миллисекундные, особенно для клиентов

Mirrormaker передает привет. Кластеризация кафки это маркетинговый балшит, при более-менее серьезном размере датасета оно превращается в тыкву.

Ну-ка попробуй угадать, какого размера у нас кластеры - на сколько брокеров, какие брокеры (по железу), что между ними. Я об этом писал в разных местах на ЛОРе, если не поленишься - найдешь. А потом вместе решим, что буллшит, что нет.

Если это не HFT то ты трындишь скорее всего.

Это нечто родственное по требованиям к латентности - AdExchange

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

для клиентов - да, приведенный в пример апп отрабатывает от 0.5 до 2 миллисекунд, но внутри него тоже интересное происходит, и там уже десятки и сотни микросекунд.

чтение с одного только мастера это блин очень больно когда тебе надо чуть больше чем очередь. Либо у тебя будет экспорт нагрузки из хранилища в код

Топиков и партиций сильно больше, чем брокеров. Средняя нагрузка на сеть одного брокера - сотни мегабит в секунду и до нескольких гигабит во время ребаланса.

Топиков и партиций сильно больше, чем брокеров

Ок, представь что у тебя начала сетка шататься под одним из брокеров. Просадка пойдёт сразу по всем партициям где он лидер и никакой retry не спасёт. Который спас бы в случае чтения со слейвов

внутри него тоже интересное происходит, и там уже десятки и сотни микросекунд.

Из памяти и без сети вообще? Банальный свитч даст хорошую задержку даже находясь в той же стойке (если мы про микросекунды)

AdExchange

У вас что, показывающий код ходит по сети в кафку синхронно на каждый показ? Или это чисто брокер?

Кстати, AdExchange не БК часом?

Ок, представь что у тебя начала сетка шататься под одним из брокеров. Просадка пойдёт сразу по всем партициям где он лидер и никакой retry не спасёт. Который спас бы в случае чтения со слейвов

Сетка - то хрен с ней, обычно сторадж дохнет. Или весь брокер целиком. Уходят клиенты таки на другие брокеры, потому что деграднутые лидеры тушатся и кластер ребалансится.

Из памяти и без сети вообще? Банальный свитч даст хорошую задержку даже находясь в той же стойке (если мы про микросекунды)

Там Aerospike. Ну да сути не меняет. Апп бегает, задержки норм. Кстати, сильно помог переезд с vmware на kvm, задержки в сетевой части очень заметно уменьшились.

Кстати, AdExchange не БК часом?

Who is БК? Букмекерская контора? Нет.

Кстати, сильно помог переезд с vmware на kvm, задержки в сетевой части очень заметно уменьшились.

Вы ещё и на виртуалке живёте? И с микросекундами? Сдаётся мне гонишь ты, либо недоговариваешь сильно

Сетка - то хрен с ней, обычно сторадж дохнет.

По опыту сетку шатает куда чаще хардов. Прям в разы чаще. Очередь на свитчах встала из-за соседа - и привет

Вы ещё и на виртуалке живёте? И с микросекундами? Сдаётся мне гонишь ты, либо недоговариваешь сильно

Конкретно этот апп живет на виртуалках. Это не имеет ровно никакого принципиального значения.

По опыту сетку шатает куда чаще хардов. Прям в разы чаще. Очередь на свитчах встала из-за соседа - и привет

Говносетку - да. У нас - нет. Просто сетку должны проектировать сетевые инженеры, а не студенты за еду.

Это не имеет ровно никакого принципиального значения

Воу, прям оверхеда нет совсем. Если мы про микросекунды, то даже банальный пинг интерфейса виртуалки с её же хоста больше съест. А icmp это уже ниже некуда

Говносетку - да. У нас - нет.

Любую сетку периодически шатает, особенно нагруженную. А если ещё и часть данных от юзеров идёт, и если аппов больше одного и они размазаны по нодам, и ювелирно выверить все очереди вплоть до байта уже никак - шатает в десять раз чаще. Или ты с сетями никогда плотно не работал?

Воу, прям оверхеда нет совсем. Если мы про микросекунды, то даже банальный пинг интерфейса виртуалки с её же хоста больше съест. А icmp это уже ниже некуда

Если на хецнеровском десктопном железе и гентушечке такое делать, то почти уверен, что так и будет. В промышленных средах такого нет.

Любую сетку периодически шатает

Ну зашатай мне сетку с 2х10Г бондами на разные top of rack свитчи. Я посмотрю. Бывает, один свитчик виснет или дохнет раз в полгода, таки пофиг на него с высокой колокольни.

Бывает, один свитчик виснет или дохнет раз в полгода, таки пофиг на него с высокой колокольни

Очередь это не «дохнет». Это именно шатает.

Ну зашатай мне сетку с 2х10Г бондами на разные top of rack свитчи

Да в лёт. Начни с одной стойки на другую трафик гнать на резервное копирование нескольких ssd, и желательно прямо в пик нагрузки. Сетка будет рада. А если еще и извратиться и начать байты по разным машинам пихать - вообще улёт будет.

Если б ты начал говорить про всякие тонкости вроде миррора на n тачек с дропом всех ответов кроме первого или использования хитрого фарша типа hdmi вместо обычных сетевых кабелей - возможно я б поверил. Такие вещи применяются в реально больших дц, и сетка все равно шатается.

В промышленных средах такого нет.

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

Очередь это не «дохнет». Это именно шатает.

Нет таких проблем, извини. Даже во время ребаланса кафки - единственная неприятность это то, что пропускная способность свитчей забита в потолок. Но пакеты при этом не теряются.

хитрого фарша типа hdmi вместо обычных сетевых кабелей

Не, извини, колхоз-монтаж не применяем. Просто оптика. Вопросами веры не оперируем, исповедуем инженерный подход.

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

Ты сейчас теоретизируешь, пока все это тебе рекламу показывает. Ну ок, все лохи, один ты умный, так и решили. Великий строитель сетей на HDMI кабелях :-D

Не, извини, колхоз-монтаж не применяем

Так и запишем - у faang в цодах колхоз-монтаж. Продолжай. Меди, как ты можешь догадаться, пофиг что за сигнал тащить, и если есть куда менее капризный шнур, рассчитанный на 18 гигабит, и деньги на разработку - внезапно будет сильно проще жить.

Но пакеты при этом не теряются.

Различай задержки и потери пакетов

Ты сейчас теоретизируешь, пока все это тебе рекламу показывает

Вспоминая твой коммент про «букмекерскую контору», либо ты не в рф, либо вы слегка недоросли чтоб показывать «всю рекламу».

у faang в цодах колхоз-монтаж

То же мне новость. У них все крутится вокруг одноразового говна. Не говорю, что это неверный подход, но он, скажем так, весьма особенный.

Различай задержки и потери пакетов

Различаю, не переживай. Про приоретизацию трафика не слышал, да?

Вспоминая твой коммент про «букмекерскую контору», либо ты не в рф, либо вы слегка недоросли чтоб показывать «всю рекламу».

Я вроде как выше писал, что контора к РФ никакого отношения не имеет.

Смотря какая. YDB очень даже динамизируешь.

Твоя информация устарела лет на 5. Теперь делаются.

Вот например что это за динамические контейнеры на amazon, которые поднимаются по api когда нужны мощности, на них разварачивается некое ПО и идет переадресация запросов от пользователей или других подобных динамических сервисов?

Я могу тебе объяснить. Это когда амазон берет вычислительные ресурсы, продает их по цене х10 себестоимости, и делает скидку 40%, чтобы ты, дорогой лошара, смог сэкономить свои деньги. Зато ты сможешь нанять на рынке труда первого попавшегося девопса, у которого вместо мозгов — панель управления AWS, и при этом полученная система будет похожа на работоспособную.

При этом хитрожопые эффективные маркетологи и менеджеры придумали для тебя ценовую политику, которая на обложке покажет очень низкую цену за твои миллиарды запросов, при этом скромно в уголке дописав, что с тебя сдерут последние трусы за API шлюз. А поскольку цена мастрабируется линейно, то рост системы приведет к линейному росту затрат, и тогда ты внезапно поймешь, что я имел в виду под фразой «продает их по цене х10 себестоимости». Сначала сажают на иглу, а потом хрен соскочишь, когда уже сверхзатраты на разработку serverless были произведены, а собственной инфраструктуры нет и не будет.

По-настоящему масштабируемые аппы на RDBMS не делаются

Довожу до сведения: MongoDB теперь стала RDBMS, причем, с версии 4.2 — безальтернативно.

Ну-ка? Кластеризуй мне PostgreSQL как Kafka?

Как Kafka это когда после 50K партиций начинаем тормозить, а на 100K (типичный размер для крупного проекта) стоим колом? Спасибо, не надо! Они, кстати, наконец переписали свой синхронный контроллер в котором собственно всё всегда стоит колом?

Ты поднимаешь мощный сервак, которой одновременно может аж 100 пользователей обслужить, чтоб на всякий случай, и 99% времени он загружен на 10 процентов и ты просто так платишь деньги

Нет такого на реальных серверах. Я не говорю про клинические случаи. Обычно если у тебя загрузка выше штатной, например, по оперативке, то выносит кэши, и пользователи получают ответы медленнее, что в итоге приводит к естественному снижению нагрузки. Пользователь видит только снижение качества услуг. При грамотной организации нагрузки на процессор результат получается примерно аналогичный.

Конечно, если сервер сделан в стиле херак-херак, то делается жесткое ограничение по кол-во соединений запросов, и всё что выше просто жестко режется, потому что сервер начнет лавинообразно жрать больше оперативы, проца, и пропускной способности накопителей. Но даеж в этом случае снижение нагрузки все равно значит улучшение производительности. А теперь сравни это с AWS Lambda, у которой задержки обработки запроса могут доходить до 15 секунд! Да пользователь просто закроет сайт и пойдет ныть в поддержку или искать другой сервис.

Довожу до сведения: MongoDB теперь стала RDBMS, причем, с версии 4.2 — безальтернативно.

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