Еще раз о масштабировании MySQL

[mskmel]

6666 это уже совсем немало, тут SSD может столько не потянуть. Если даже данные по 100 байт то это добрых 0.5Г в секунду

6,666*100byte=666,600byte=667KByte.

[Сабина]

Предварительно проверив как mysql живет с большим количеством партиций, например 365 дней по 100-200 партиций на серверы.

Слушайте а как же вы работали с таким числом партиций ? Если 365 - это ж каждый день надо новую создавать ? У вас какая то логика была на запись для partition maintenance ?

[mskmel]

Слушайте а как же вы работали с таким числом партиций ? Если 365 - это ж каждый день надо новую создавать ? У вас какая то логика была на запись для partition maintenance ?

Hint: можно создавать раз в месяц но сразу 30 штук Логика была (есть). Она создаёт, архивирует, удаляет.
В Оракле есть interval partitions для этого, на сколько я знаю в mysql такое еще не изобрели.

Как я понял у вас уже есть и отлично работает агрегация, так оставьте её как есть, добавив еще одну структуру для хранения всех деталей по каждому клиенту\серверу. И лезть в неё тогда и только тогда когда юзер попросил эти детали.

2000серверов * 20метрик * 6раз * 24ч = 5,760,000
Это всего навсего 6млн записей в день (спасибо stenking за урок арифметики). Если это 100 байт на запись, то это каких то 600МБ в день на все серверы что есть.

Надо вам два года: 2 * 365 * 20метрик * 6раз * 24ч = 2,102,400 или 200МБ на сервер за 2 года. Какой бы глупый mysql не был, но всю историю всех метрик в худшем случае несколько секунд считать будет.

Зачем тут разные кассандры, кэши т.п. не совсем очевидно.

[Сабина]

Как я понял у вас уже есть и отлично работает агрегация, так оставьте её как есть, добавив еще одну структуру для хранения всех деталей по каждому клиенту\серверу. И лезть в неё тогда и только тогда когда юзер попросил эти детали.

2000серверов * 20метрик * 6раз * 24ч = 5,760,000
Это всего навсего 6млн записей в день (спасибо stenking за урок арифметики). Если это 100 байт на запись, то это каких то 600МБ в день на все серверы что есть.

Надо вам два года: 2 * 365 * 20метрик * 6раз * 24ч = 2,102,400 или 200МБ на сервер за 2 года. Какой бы глупый mysql не был, но всю историю всех метрик в худшем случае несколько секунд считать будет.

Зачем тут разные кассандры, кэши т.п. не совсем очевидно.

Дошли у меня руки до арифметики и все не так, ну как минимум видимо я что-то не так обьяснила

2 года * 365 дней * 2000 серверов * 20 метрик * 6 раз * 24 часа - для серверов
ПЛЮС
2 года * 365 дней * 2000 серверов * [1-5] sever volumes * 10 метрик * 6 раз * 24 часа - у каждого сервера еще считывается несколько метрик для каждого volume

А самое главное у них намечается рост числа хостов где то до 5000 засчет global customers, надо и на это рассчитывать.

Агрегация такая что какие то метрики надо брать MAX, какие то SUM, какие то AVG, какие то с latest timestamp.
Сейчас агрегация делается "скриптом", то есть при добавлении raw data делается апдейт в daily rollup.

Все метрики за секунды и близко не считаются.
Даже после того как я поменяла немного таблицы, а именно:
- timestamp is no longer "datetime" column type but bigint and holding UNIX timestamp
- added range partitioning by month
- added hash partitioning by account id

Ключ по комбинации: account id + asset id + metric id + timestamp, где asset может быть либо сервер либо volume. Он же индекс соотвественно.

Запросы где в where clause условие по account id и правда быстро проходят, как минимум on weekly data volume что я собрала с новой схемой. А вот запрос по всем эккаунтам ( admin view of all accounts & all metrics health) уже занимает 200 секунд. В explain plan ничего пока нет криминального, прямо не знаю что еще попробовать ?
Как я поняла в mysql нет хинта PARALLEL, то есть параллельный процессинг не поддерживает. Так что ваше предположение что он со всем справляется увы неверное

[mskmel]

2 года * 365 дней * 2000 серверов * [1-5] sever volumes * 10 метрик * 6 раз * 24 часа - у каждого сервера еще считывается несколько метрик для каждого volume

Так всё равно дневной объем 1-2ГБ
Думайте над датамоделью и алгоритмами, объемы детские, легко обсчитываемые серверами 10+ летней давности, которые были слабее текущих десктопов.

[kostik78]

+1 к предудущему посту.

[Сабина]

Временные по дням ? Так наверное запросы медленнее будут выполняться потому что across several partitions?

С чего они будут медленнее? Просканирует 7 партиций поменьше, вместо одной большой. ...
Но в твоём случае, если нет 100500 юзеров постоянно выбирающих статистику по своим хостам, шардинг не надо. Сохранить и иногда запрашивать небольшой кусок данных справится любая БД из тобой рассматриваемых.

Большое спасибо за совет с дневными партициями. Квери ускорились где то в 5 раз. Вытащить все агрегированные метрики для эккаунта за одну неделю занимает 0.2 секунды, по всем эккаунтам все метрики - 20 секунд. Терпимо

[Сабина]

Кстати а как Амазонский редшифт по сравнению c просто postgres ? Есть смысл пользовать Redshift over Postgres cluster если очень важна performance ?

[Сабина]

http://www.postgresql.org/

А мне показалось что не может быть PostgreSQL настолько лучше MySQL в этом плане что глобально решит проблему.
А засчет чего там timeseries на порядки лучше обрабатываются ?

PS. Переделка таблиц и партиций немного помогла, теперь около 1 mln records per 24 hours

Да кстати Постгрес и правда немного побыстрее работал, но заметно стало только когда таблица выросла до 5 mlns records. Правда наши опсы дружно сказали нет

[Сабина]

2 года * 365 дней * 2000 серверов * [1-5] sever volumes * 10 метрик * 6 раз * 24 часа - у каждого сервера еще считывается несколько метрик для каждого volume

Так всё равно дневной объем 1-2ГБ
Думайте над датамоделью и алгоритмами, объемы детские, легко обсчитываемые серверами 10+ летней давности, которые были слабее текущих десктопов.

Кстати про объемы. У меня под VM 30 гигов выделено. Я сегодня скопировала одну таблицу с 3-мы raw metrics за неделю и диск юсадж подскочил от 98 до 100 процентов и база сдохла. Я это к тому что ваши подсчеты примерно верные

[Komissar]

2 года * 365 дней * 2000 серверов * [1-5] sever volumes * 10 метрик * 6 раз * 24 часа - у каждого сервера еще считывается несколько метрик для каждого volume

Так всё равно дневной объем 1-2ГБ
Думайте над датамоделью и алгоритмами, объемы детские, легко обсчитываемые серверами 10+ летней давности, которые были слабее текущих десктопов.

Согласен, с такими об'емами и mysql будет нормально бегать. Нельзя ли отпрофилировать и посмотреть, где именно тормоза?

[mskmel]

Правда наши опсы дружно сказали нет

Ещё бы! Если бы из-за каждого тормозящего запроса девелоперы бы просили поменять БД, то опсам бы 24*7 работать надо было.

[Сабина]

Правда наши опсы дружно сказали нет

Ещё бы! Если бы из-за каждого тормозящего запроса девелоперы бы просили поменять БД, то опсам бы 24*7 работать надо было.

Тут вы не совсем правы. Система себя изжила , без major refactoring всяко не обойтись, проблема совсем не только в нескольких запросах и new requirements. Вопрос только когда, но тут получается опсам спасибо что решили за всех. Мне проще, хоть с базой не возится, я не возражаю

[Сабина]

Местные орлы толкают новую идею DynamoDB. Никто не пробовал ?
По идее должно подойти joins не нужны, надо просто быстро читать. Мне ничего не стоит мой быстрый процесс на Java заставить писать в DynamoDB за оставшиеся дни. Начальник просит доделать backend part потому что остаются одно nodejs девелоперы работать над остальным

[XpoH]

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

[Сабина]

это же амазона поделка.
ее разве можно где-нибудь кроме амазоновского клауда пользовать?

Так я же писала что здешний менеджмент больше верит в uptime Amazon SQS чем своих серверов

[Леонид Ильич Брежнев]

Местные орлы толкают новую идею DynamoDB. Никто не пробовал ?
По идее должно подойти joins не нужны, надо просто быстро читать. Мне ничего не стоит мой быстрый процесс на Java заставить писать в DynamoDB за оставшиеся дни. Начальник просит доделать backend part потому что остаются одно nodejs девелоперы работать над остальным

Да, дайномо это очень хорошая noSQL база, написанная людьми, которые DB, including noSQL умеют писать.

[Сабина]

Кстати никто не хочет к ним на контракт ? Маленькая тихая компания в EastBay, приходить в 9 ухoдить в 5, надо по делам - нет вопросов.
Они считают что им нужен ДБА , но делать надо все то же что в этой теме описано. Да и еше спокойно относится к людям, которые любой код кроме своего, называют brain fart

[Сабина]

A попробовать MySQL Cluster https://www.mysql.com/products/cluster/faq.html#cluster" onclick="window.open(this.href);return false; не хотите ? И нам расскажете, как он масштабируется ?

А там и так percona, но кластер то для репликации

[АццкоМото]

забавно, что с посекундной статистикой bw in/bw out и прочего типа этого на несколько сот тысяч серверов на позапрошлой работе не было никаких проблем

[mskmel]

забавно, что с посекундной статистикой bw in/bw out и прочего типа этого на несколько сот тысяч серверов на позапрошлой работе не было никаких проблем

Не думаю что в твоём случае был один программист\ДБА\архитектор на всё.
А так да, 10+ лет назад без всяких кассандрохадупов Телко считало трафик, при чем не для "жалких" сот тысяч серверов, а десятков миллионов абонентов.