с такими вводными наверное не будет нормальных решений, кроме как не использовать триггеры и внешние ключи :) а насчет инструмента — мы юзаем gh-ost. всю таблицу он, конечно, сливает, но делает это умно — меедленно с контролем отставания по другим слейвам перетаскивает данные из основной таблицы. при этом он цепляется как еще один слейв к мастеру и читает поток изменений из бинлога, и эти изменения проигрываются и накатываются на таблицу-копию. Когда данные синхронизированы, вешает небольшую блокировку на несколько секунд и в этот момент ренеймит таблицы. Внешние ключи конечно не дадут такие махинации делать. по принципу очень похоже на pt-schema-change, но чуток поумнее.
40к rps мы привели просто как текущее значение, для общего понимания масштаба.
в высокий сезон это 1.5-2х от этих значений, но это скорее повод задуматься об оптимизации кода, чем об оптимизации кластера.
Про пересчет — есть несколько моментов. реалтайм обновление остатков и цен для нас не сильно больно сейчас (раньше на древнем железе с шпиндельными дисками было хуже), намного больнее для нас — полный пересчет индексов (и он архитектурно пока тоже нужен, т.к. далеко не все данные уходят в реалтайме).
Про МВ не скажу, там своя кухня на фронте. Про эльдорадо — нет никакой магии, есть список алиасов и автоматических преобразований слов. вся история поисков и статистика по словам естественно ведется. +еще во многих регионах работает внешний сервис anyquery, про его магию не в курсе, но думаю что примерно в эту же сторону работает, т.к. судя по отзывам тех кто работал в админке там много как раз такой ручной настройки. сам руками внутренности не щупал.
Мы посчитали такой переход менее рискованным, чтобы не наткнуться на новые грабли 8й версии, и про переход на 8ку можно будет еще статью написать. Просто чтобы некоторые баги поймать надо неделями гонять нагрузочные тесты :)
У нас тоже нет таких проблем, но мы всегда рассчитываем на худшее в действиях пользователей и готовимся заранее ) Можно несколькими костылями пошардить часть данных, но лучше и проще сделать нормальное решение рядом и вынести. Основная боль — это как раз из сильносвязанного монолита вычленить то, что можно будет сделать слабосвязанным. Сервис новый написать это где-то 5% трудозатрат имхо)
Статейки неплохие, спасибо! можем вам рассказать как делать большие альтеры без боли и влияния на пользователей в любое время :)
Тут не претендуем на объективность, он нам не понравился в ситуациях потери части транзакций или скипа части бинлога. проигрывание и восстановление может превратиться в боль, списки проигранных сетов тоже. В идеальном мире наверное да, но при нашем потоке изменений — пока не стали менять. Может быть когда-нибудь в будущем ещё потестим и включим, но пока не так уж хочется.
Им тоже писали и они входят в список тех кто либо не ответил, либо отказался, но мы специально в статье не указываем имен :)
Сейчас везде 5.7. До этого сначала было везде 5.5, потом слейвы 5.7+мастера 5.5, и самая боль про обновление мастеров (хотели сначала до 5.6 мягко, а получилось в итоге сразу на 5.7) — как раз в статье.
Фасеты на моей памяти никогда не были на mysql, раньше в монолите фасеты лежали в редисе, индексы для полнотекста в сфинксе, сейчас и для фасетов и для поиска — это отдельный сервис на джаве и под джавой уже лежит несколько индексов в эластике.
Одна нода приложения работает с одним мастером, но все ноды поделены на 4 «зоны», это просто 4 разных окружения, с немного отличающимися параметрами и своими инстансами кешей, например. Каждая зона работает со своим мастером, поэтому можно сказать что приложение в целом работает со всеми 4мя одновременно, т.к. все активные и работают параллельно. Выбор мастера — вопрос балансировки по этим зонам, тут конечно мы имеем возможность распределять веса и отправлять на любую из них нужную долю пользователей. и со стороны приложения, конечно можем в любой момент сказать в какой зоне какой мастер использовать.
Про federated — часть некритичных для логики данных (логи заказов, например) — вынесены в отдельный кластер mysql и под них делается отдельный коннект. чтобы иметь возможность делать джоины тех же данных заказов между разными БД, например, основную таблицу заказов сджоинить с логами, можно извращаться, а можно использовать federated таблицы (хотя это тоже извращение :)). Этот federated надо использовать очень осторожно, потому что любой запрос требующий поиска по таблице без первичного ключа приведет к тому, что вся таблица будет полностью копироваться по сети. точно также и в обратную сторону на отдельной реплике для аналитиков мы сделали и обратный проброс таблицы с логами в основную БД.
в высокий сезон это 1.5-2х от этих значений, но это скорее повод задуматься об оптимизации кода, чем об оптимизации кластера.
Статейки неплохие, спасибо! можем вам рассказать как делать большие альтеры без боли и влияния на пользователей в любое время :)
Тут не претендуем на объективность, он нам не понравился в ситуациях потери части транзакций или скипа части бинлога. проигрывание и восстановление может превратиться в боль, списки проигранных сетов тоже. В идеальном мире наверное да, но при нашем потоке изменений — пока не стали менять. Может быть когда-нибудь в будущем ещё потестим и включим, но пока не так уж хочется.
Им тоже писали и они входят в список тех кто либо не ответил, либо отказался, но мы специально в статье не указываем имен :)
Сейчас везде 5.7. До этого сначала было везде 5.5, потом слейвы 5.7+мастера 5.5, и самая боль про обновление мастеров (хотели сначала до 5.6 мягко, а получилось в итоге сразу на 5.7) — как раз в статье.
Фасеты на моей памяти никогда не были на mysql, раньше в монолите фасеты лежали в редисе, индексы для полнотекста в сфинксе, сейчас и для фасетов и для поиска — это отдельный сервис на джаве и под джавой уже лежит несколько индексов в эластике.
И для некоторых критичных данных, типа данных заказа, приложение может по оффсету сходить в любой "соседний" нужный мастер :)
Про federated — часть некритичных для логики данных (логи заказов, например) — вынесены в отдельный кластер mysql и под них делается отдельный коннект. чтобы иметь возможность делать джоины тех же данных заказов между разными БД, например, основную таблицу заказов сджоинить с логами, можно извращаться, а можно использовать federated таблицы (хотя это тоже извращение :)). Этот federated надо использовать очень осторожно, потому что любой запрос требующий поиска по таблице без первичного ключа приведет к тому, что вся таблица будет полностью копироваться по сети. точно также и в обратную сторону на отдельной реплике для аналитиков мы сделали и обратный проброс таблицы с логами в основную БД.