>highload
>ололо лекции от мыла
>жаба
Модер, закрывай тред и бань идиота.
Давай, маня, расскажи Нетфликсу, что джава не для хайлоада.
Здесь это почему-то популярное мнение, мол хайлоад - это обязательно кресты или пщ.
>хайлоад - это обязательно кресты
Тут всю доску надо закрывать в таком случае.
Ты для начала прочти что они пишут на Java, дуралей. Там типичные круды на спринге в формате микросервисов. Хайлоад там в кастомной сборке фрибсд и килотоннах C++ кода, который рулит доставкой контента.
В целом, конечно хайлоад это про архитектуру, а не языки...
Но бля, когда ежемесячный счёт авс начинает превышать зарплаты десятка программистов, начинается переписывание на более экономные на память языки, которые лучше утилизируют ресурсы. И да, это гошечка, раст и кресты.
>Хайлоад там в кастомной сборке фрибсд и килотоннах C++ кода, который рулит доставкой контента.
Откуда инфа?
Вбей в ютуб - Netflix FreeBSD и узри. Про C++ тоже найдешь.
Про твою Java там тоже достаточно презентаций с конференции Spring One, лол.
Но у нетфликса эликсир.
>этот пукнутый семен
Лол это мой первый пост в треде.
Они там еще TLS в ядро перенесли.
Есть у кого опыт kql, это который Реал тайм аналитика на кафке?
Что-то на форумах мнения попадаются, что оно говно, и нужен Спарк. Но почему?
Что-то на форумах мнения попадаются, что оно говно, и нужен Спарк. Но почему?
Нашел где спрашивать, лол.
Кидай свои варианты или уебывай
Ocпариваeшь нecправeдливый бан в кoтoрый раз? Лучшe ocпoрь правo мoчи eгo выдавать!
Если возникает вопрос, на чем дедать хайлоад - скорее всего хайлоад тебе НЕ НУЖЕН.
Тред мертв, но все же.
Аноны, очередной вопрос знающим, ну или теоретикам, на порассуждать.
Какая схема работы подойдёт лучше, для масштабируемой системы:
1. Сервер на котором сразу все. Nginx+flask+pgbouncer+postgresql. И таким образом набор этих сервисов раскинуть по все регионам.
2. Сервер на котором веб часть(Nginx+flask) и один(под каждый регион) отдельный сервер под бд(pgbouncer+postgresql).
Задача в том, что бы на каждый гео-регион поставить сервера, что бы юзеру был пинг получше.
Первый вариант проще всего доставлять и нихуя особо настраивать не надо. Но тогда больше шанс проеба при репликации мастер-мастер т.к. бд много получается.
Второй вариант сложнее настраивать, т.к. каждый раз надо будет для приложения прописывать вручную конкретный адрес бд которая подходит к его региону.
Деплой идёт докер-композом.
Неужели кубернетосы завозить надо?
Аноны, очередной вопрос знающим, ну или теоретикам, на порассуждать.
Какая схема работы подойдёт лучше, для масштабируемой системы:
1. Сервер на котором сразу все. Nginx+flask+pgbouncer+postgresql. И таким образом набор этих сервисов раскинуть по все регионам.
2. Сервер на котором веб часть(Nginx+flask) и один(под каждый регион) отдельный сервер под бд(pgbouncer+postgresql).
Задача в том, что бы на каждый гео-регион поставить сервера, что бы юзеру был пинг получше.
Первый вариант проще всего доставлять и нихуя особо настраивать не надо. Но тогда больше шанс проеба при репликации мастер-мастер т.к. бд много получается.
Второй вариант сложнее настраивать, т.к. каждый раз надо будет для приложения прописывать вручную конкретный адрес бд которая подходит к его региону.
Деплой идёт докер-композом.
Неужели кубернетосы завозить надо?
> т.к. каждый раз надо будет для приложения прописывать вручную конкретный адрес бд которая подходит к его региону
Про оркестрация не слышал, не? На каком-нибудь ansible, или что там сейчас модно, любая макака нужную роль напишет за пару тройку дней. Один раз составляешь инвентарник c айпишниками и конфигурацией этих твоих федерализуемых микрокластеров и по ней до/развёртываешь/обновляешь компоненты.
Ещё можешь посмотреть в сторону ластика, если у тебя в требованиях есть полнотекстовый поиск, там федерализация из каропки с 6 версии вроде бы.
> Неужели кубернетосы завозить надо?
> Про оркестрация не слышал, не?
Окаай.
Не уверен в адекватности оркестрации при 6-7 серверах.
> ластика
Падажи, антош, я не про это справшивал. Про полнотекстовый поиск я ничего не писал. Так-то он и в постгресе есть.
Вопрос в том, какой из подходов адекватней и лучше, п.1 или п.2, как думаешь?
Ну ты нашел где спросить, ей-богу. Встает вопрос, что для тебя важнее - репликация или уменьшение ебли с настройкой. Если не знаешь - кинь монетку пока она летит - поймешь, какую сторону тебе хочется
Уменьшение ебли с настройками важнее, т.к. репликация точно будет работать збс, хоть и могут быть проблемы, но по журналу транзакций все потом восстановится.
Но если я стартану новый сервер, к примеру, то бд в нем будет пустая, и понадобится время что бы синхронизировать новую бд и существующие. А это уже пиздецом попахивает.
Видимо выберу вариант с независимыми БД и еблей с настройками.
Ну вот и определились. Кря-кря!
представляю этот зоопарк из .нет/ява/нода сервисов, где каждый образ по 1гб, даже для самых милипиздрюческих задач
Нода столько не жрет, попрошу. Не зря ж она инвалида по функциональности напоминает.
> и один(под каждый регион) отдельный сервер под бд(pgbouncer+postgresql)
Охуеешь поддерживать. Возьми вместо postgresql - cockroachDB, там геопартишенинг из коробки есть, а со стороны приложения практически никакой разницы нет.
Поздно, уже сделал как описывал, пока норм.
Но изучу твою идею, спасибо, антош.
> 28 постов за 3.5 месяца
Ну да, куда уж типичнее.
Дай свое определение highload'а
все бизнесы, где проебались с планированием нагрузки.
(я не он)
Так в том то и дело, что в твоем определении нет ничего, что бы отрицало MySQL
Более-менее полезные материалы:
https://ruhighload.com/ - главный россиянский сайт по теме
https://www.youtube.com/playlist?list=PLrCZzMib1e9rZohs_FJg8MK52Ey494z40 - курс от Мыла
https://libgen.lc/item/index.php?md5=A12F1222BAC4AC823E6F1791916AF05F - мета-учебник
https://libgen.lc/item/index.php?md5=ADB1B34DC79C1AA7A2624EC0A12C819B - тонкии пердолинг Джавы