К чему это? Я вообще потерял ход ваших мыслей 😄

К чему это? Я вообще потерял ход ваших мыслей 😄

виртуальный

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

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

Конечно, ибо будет соержать больше одной ноды.

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

У нас видимо разный дефинишн “распределенных систем”:D

конечно, так смотрите, у вас 100 миллионов записей в секунду. Вы поставили еще одну ноду в режиме репликации. Что будет? тормозить сильнее)

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

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

да я вот об этом тоже задумался.. вхахв

Еще раз: Распределенная система хранения данных - это ЛЮБАЯ система, данные которой РАСПРЕДЕЛЕНЫ каким-то образом между нодами. Ничего про то, как они распределны, какой перформанс, какая репликация и т.д. в определении НЕТ.

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

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

Так я и не понимаю, о чем речь и что тогда имеется в виду под “распределенными данными” с вашей стороны.

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

Так я и не понимаю, о чем речь и что тогда имеется в виду под “распределенными данными” с вашей стороны.

Так я и не понимаю, о чем речь и что тогда имеется в виду под “распределенными данными” с вашей стороны.

Нет. Просто я видел на работе один огромный сервак. 60 CPU, 500 TB, 300 RAM Весит 50 кг. Когда я спросил зачем такой огромный мне сказали: С одного такого можно сделать виртуальный кластер с несколькими нодами. Если мы подключим еще один такой 50кг сервак, мы получим физический кластер. Как только 1 сервак закончился, мы занимаем 2, закончился 2, подключаем 3 и тд и тд.

Нет. Просто я видел на работе один огромный сервак. 60 CPU, 500 TB, 300 RAM Весит 50 кг. Когда я спросил зачем такой огромный мне сказали: С одного такого можно сделать виртуальный кластер с несколькими нодами. Если мы подключим еще один такой 50кг сервак, мы получим физический кластер. Как только 1 сервак закончился, мы занимаем 2, закончился 2, подключаем 3 и тд и тд.

Все верно, только если виртуализуешь хорошее правило иметь n+1 зеркало как с рейд массивом для отказоустойчивости

Нет. Просто я видел на работе один огромный сервак. 60 CPU, 500 TB, 300 RAM Весит 50 кг. Когда я спросил зачем такой огромный мне сказали: С одного такого можно сделать виртуальный кластер с несколькими нодами. Если мы подключим еще один такой 50кг сервак, мы получим физический кластер. Как только 1 сервак закончился, мы занимаем 2, закончился 2, подключаем 3 и тд и тд.

Нет. Просто я видел на работе один огромный сервак. 60 CPU, 500 TB, 300 RAM Весит 50 кг. Когда я спросил зачем такой огромный мне сказали: С одного такого можно сделать виртуальный кластер с несколькими нодами. Если мы подключим еще один такой 50кг сервак, мы получим физический кластер. Как только 1 сервак закончился, мы занимаем 2, закончился 2, подключаем 3 и тд и тд.

Но отказоустойчивость можно реализовать за счёт n+1 виртуальных машин и это возможно покроет часть рисков но не потерю рейд контроллера или матернки

Я о том, чтобы входящий запрос мог разгружен двумя единицами, а не одной

Тогда я понял разницу. 😁😁😁

Вот, значит речь о том, чтоб увеличить write-capacity, что вообще из другой оперы. Вариантов масса, самые очевидные, которые приходят в голову: - использование Multi-leader replication - использование Leaderless replication - замена B-tree based на LSM tree based решения.

А по поводу ограничения на коннекты, условный EC2 m4.2xlarge поддерживает до 494781 TCP соединений одновременно.

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

А по поводу ограничения на коннекты, условный EC2 m4.2xlarge поддерживает до 494781 TCP соединений одновременно.

ес2 амазон хвастался 1м+ соединениями как-то

Смотря какой инстанс же, м4 - не самые большие.

Сейчас даже проверил.

ну, тут уже углублденности, в которых я совсем дилетант)

Думаю какой-нибудь m5zn.12xlarge поддерживает и 10M+, надо посмотреть документацию.

Это 1 узел?

Доброц ночи ребята, не осуждайте сильно нужно ваше мнение Кароче прогуливал школу как мог двоечник жуткий нихера не знаю:) Потому что этот вопрос ни где не разбирался (можно ли стать кодером без школьной программы ?)

Хотелось бы побольше информации в чем будут самые большие затруднения,

Не понял

Думаю какой-нибудь m5zn.12xlarge поддерживает и 10M+, надо посмотреть документацию.

максимум другой стиль преподавания и подачи информации

а если не сложно, это же уже не сегодня будешь делать?) просто хотелось бы узнать про это хотя бы в двух словах

Особенно когда за 10 виде по 4 минуты ты узнаешь столько нового и задумываешься стоит вдаваться в подробности или пропускать

Что именно делать и про что именно узнать?

есть ли варианты у вас, например, по документации поддержки 10м+ коннекшинов делать = посмотреть доку

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

ну, мне жто интересно просто в техническом плане, потому что про это речь зашла от другого Михаила, так-то это вообще не нужно) Учитывая то, что и с небольшим количеством коннекшинов все работает прекрасно)

Вечером гляну, если не забуду.