А вот если в ms flight simulator качать в меню 120 Гб игры, то угадайте, на сколько будет грузиться видеокарта не самого древнего поколения (и последнего тоже)?) Правильно, на 100%! Уж не знаю кто там на чем майнит, но в меню при этом кроме ползунка с процентом скачанного ничего не меняется, но тупо нет ограничения фпс) и это общий тренд, говорящий только о лени и неумении разработчиков и аналитиков заниматься качественно своим делом, либо о совсем других приоритетах со смещением в сторону hardware.
Мы проводили очень много тестов на эту тему, и основной вывод был — конкретно нам — пока лучше с маленьким кверикешем и с тюнингом размера попадающих в него элементов, чем без него. Разница по cpu в разы, несмотря на фрагментацию, блокировки и т.п. вещи.
Я думаю многие. Кто-то ещё на фортране пишет до сих пор :) и в нашем зоопарке софт на delphi вполне активно используется.
Конкретно в нашем случае, не будь кольца, обновление бы прошло, конечно, намного раньше.
Это уже не совсем бд) это сервис, который ещё и в память может вместить все. При таких вводных тут совсем другой подход. (Для подписчиков видимо интеграция через grpc?)
Но чем толще данные, тем больнее падение такой системы и время восстановления будет.
Регулярно думаем об облаках, но есть нюансы и ограничения: облака только российские (яндекс/mail/крок), а ещё лучше собственное где твои ресурсы точно не будут конкурировать с кем-нибудь ещё. С зарубежными намного больше рисков, какими бы удобными они ни были, хотя и их тоже рассматривали.
Насчёт вашего примера — одна большая нода с пассивным стендбаем — это скорее про оракл, для мускуля (даже если она будет очень толстая) — это плохо по целому ряду причин. Такую толстую ноду мускуля легко уронить в сегфолт простым сбросом кверикеша, или как она будет долго висеть в блокировках при большом рпс?.. Главный вопрос — как ее будут дальше скейлить на чтение при росте нагрузки x10? Из вашей схемы пока мне неочевиден 100% выигрыш, т.к. при больших объемах записи вам надо строить больше индексов для нескольких представлений, т.е. это некий tradeoff для случаев большого чтения, ценой удорожания записи. Но в целом интересный подход, для каких-то кейсов точно подойдёт.
Альтернативы смотрели, но далеко не все проходит требование по минимальным изменениям и совместимости со всеми уже имеющимися инструментами обслуживания. В случае с галерой — не понравилось ограничение по возможным движкам и ограничения скорости связанные с количеством мастеров (упирание в самый медленный). Видимо основная боль там — решение проблемы с консистентностью и эта проблема конечно у нас есть, но она для нас менее критична, чем скорость. для нового проекта использовать вполне можно, а вот можно ли вообще провернуть такую бесшовную миграцию — пока не уверен.
Такой проблемы с потерей данных, к счастью не было никогда. Худшее что происходило — меняли материнскую плату на тогда ещё железном сервере с мастером. К нашему счастью отказ материнки позволял нормально работать до поставки вендором.
А насчёт БД с поддержкой, у нас полно оракла и есть несколько саповских монстров типа ханы (не конкретно в ИМ eldorado, а в целом в мвидео-эльдорадо), но наличие поддержки не гарантирует отсутствие проблем ни в одной из них.
Приложению всегда можно сказать "иди в другой". Это можно и как фоллбэк при невозможности выполнения запроса юзать, и просто переключая настройки енва по срабатыванию мониторинга.
в этой части — да, сами примерно также когда-то мониторили. но сейчас от этого ушли, больше нет такой острой необходимости. сейчас мы мониторим все блокирующие запросы на мастерах (также как и долгие селекты), это получилось полезнее и позволяет еще до попадания в бинлог все найти и отреагировать.
В первую очередь это нужно чтобы любой мастер можно было выключить в любой момент и легко пережить аварию/обслуживание. Но это точно далеко не самый типичный сетап. Я про крайней мере не знаю пока никого, кто делал бы так же. а так да, у каждого треда свой поток applier'a. И немного это разгружает, т.к. часть запросов по бинлогу приходит как раз в row, но конечно не по общему объему записи.
у нас тайн нет. Стратегически — ничего не останется, уже существенная часть работает без него, да и последние апдейты php только повышают вероятность такого сценария. Остались самые тяжелые места для переноса. но на их распил до конца легко может уйти еще года 2-3.
получилось в статье совсем неочевидно, хотя картинку старался делать максимально детальной :) вот тут подробнее. в нашем кейсе потоки данных физически идут от разных мастеров, каждый поток стартует как обычная репликация, но работает с добавлением ко всем командам FOR CHANNEL='masterN'. На каждом слейве у нас сразу 4 мастера. И если транзакции с них при этом не имеют общих блокировок, то выполняются параллельно в рамках одного таймстемпа. ключевое для повышения параллельности обработки — slave_parallel_type и binlog_transaction_dependency_tracking, но как уже тут писали — не совсем безопасно и не стоит просто так крутить из дефолтов особенно в некоторых минорных версиях 5.7.
А вот если в ms flight simulator качать в меню 120 Гб игры, то угадайте, на сколько будет грузиться видеокарта не самого древнего поколения (и последнего тоже)?) Правильно, на 100%! Уж не знаю кто там на чем майнит, но в меню при этом кроме ползунка с процентом скачанного ничего не меняется, но тупо нет ограничения фпс) и это общий тренд, говорящий только о лени и неумении разработчиков и аналитиков заниматься качественно своим делом, либо о совсем других приоритетах со смещением в сторону hardware.
Есть можно, трусы главное не надевать)
То есть за отдачу разного контента поисковикам и пользователям улететь в бан не боитесь?)
Психи не только на работе, они вокруг нас, они внутри нас! Ааааа!
Я думаю многие. Кто-то ещё на фортране пишет до сих пор :) и в нашем зоопарке софт на delphi вполне активно используется.
Конкретно в нашем случае, не будь кольца, обновление бы прошло, конечно, намного раньше.
Это уже не совсем бд) это сервис, который ещё и в память может вместить все. При таких вводных тут совсем другой подход. (Для подписчиков видимо интеграция через grpc?)
Но чем толще данные, тем больнее падение такой системы и время восстановления будет.
Регулярно думаем об облаках, но есть нюансы и ограничения: облака только российские (яндекс/mail/крок), а ещё лучше собственное где твои ресурсы точно не будут конкурировать с кем-нибудь ещё. С зарубежными намного больше рисков, какими бы удобными они ни были, хотя и их тоже рассматривали.
Насчёт вашего примера — одна большая нода с пассивным стендбаем — это скорее про оракл, для мускуля (даже если она будет очень толстая) — это плохо по целому ряду причин. Такую толстую ноду мускуля легко уронить в сегфолт простым сбросом кверикеша, или как она будет долго висеть в блокировках при большом рпс?.. Главный вопрос — как ее будут дальше скейлить на чтение при росте нагрузки x10? Из вашей схемы пока мне неочевиден 100% выигрыш, т.к. при больших объемах записи вам надо строить больше индексов для нескольких представлений, т.е. это некий tradeoff для случаев большого чтения, ценой удорожания записи. Но в целом интересный подход, для каких-то кейсов точно подойдёт.
Альтернативы смотрели, но далеко не все проходит требование по минимальным изменениям и совместимости со всеми уже имеющимися инструментами обслуживания. В случае с галерой — не понравилось ограничение по возможным движкам и ограничения скорости связанные с количеством мастеров (упирание в самый медленный). Видимо основная боль там — решение проблемы с консистентностью и эта проблема конечно у нас есть, но она для нас менее критична, чем скорость. для нового проекта использовать вполне можно, а вот можно ли вообще провернуть такую бесшовную миграцию — пока не уверен.
Такой проблемы с потерей данных, к счастью не было никогда. Худшее что происходило — меняли материнскую плату на тогда ещё железном сервере с мастером. К нашему счастью отказ материнки позволял нормально работать до поставки вендором.
А насчёт БД с поддержкой, у нас полно оракла и есть несколько саповских монстров типа ханы (не конкретно в ИМ eldorado, а в целом в мвидео-эльдорадо), но наличие поддержки не гарантирует отсутствие проблем ни в одной из них.
Приложению всегда можно сказать "иди в другой". Это можно и как фоллбэк при невозможности выполнения запроса юзать, и просто переключая настройки енва по срабатыванию мониторинга.
В первую очередь это нужно чтобы любой мастер можно было выключить в любой момент и легко пережить аварию/обслуживание. Но это точно далеко не самый типичный сетап. Я про крайней мере не знаю пока никого, кто делал бы так же. а так да, у каждого треда свой поток applier'a. И немного это разгружает, т.к. часть запросов по бинлогу приходит как раз в row, но конечно не по общему объему записи.
вот тут подробнее. в нашем кейсе потоки данных физически идут от разных мастеров, каждый поток стартует как обычная репликация, но работает с добавлением ко всем командам FOR CHANNEL='masterN'. На каждом слейве у нас сразу 4 мастера. И если транзакции с них при этом не имеют общих блокировок, то выполняются параллельно в рамках одного таймстемпа. ключевое для повышения параллельности обработки — slave_parallel_type и binlog_transaction_dependency_tracking, но как уже тут писали — не совсем безопасно и не стоит просто так крутить из дефолтов особенно в некоторых минорных версиях 5.7.