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

[Сабина]

Точнее может MySQL уже придется выкинуть в помойку , в общем нужен совет коллектива.
В одной конторе собирались метрики с порядка 2000+ серверов, порядка 20 видов - bandwidth in, bandwidth out и нечто называемое rpo ( для сервера и всех его volumes) etc. Считывалось все это дело раз в 10 минут и потом агрегировалось в daily tables .
Теперь выкатили новые requirements - нужно это все собирать и хранить в raw виде чтобы юзеры могли вытащить каждый sample, zoom in, zoom out etc. В общем практически big data
Я написала себе программулину, которая моделирует объем данных и получается что если собирать их по прежнему в MySQL то без daily rollups не обойтись , иначе performance аналитических запросов вообще никакая, в сутки пишется порядка 40 миллионов рекордов. Пытаюсь переделать таблицы и партиции, играюсь с индексами, query tuning, но толк почти нулевой.

Что можно еще попробовать ? Из того что я накопала - Cassandra неплохо подходит для timeseries like data. Может сразу Хадуп / Спарк ?

[VladDod]

http://www.postgresql.org/" onclick="window.open(this.href);return false;

[Сабина]

http://www.postgresql.org/

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

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

[VladDod]

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

Без понятия. Я не слишком вникал, но ты навигацию на морской сейсмике представляешь? 40M записей - это менее часа на профиле.

[Сабина]

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

Без понятия. Я не слишком вникал, но ты навигацию на морской сейсмике представляешь? 40M записей - это менее часа на профиле.

Как же все наше морская сейсмика то . Тогда и правда стоит глянуть. Ты с этим работаеш на уровне кода или пользуешь?

PS. Во
https://news.ycombinator.com/item?id=8368509" onclick="window.open(this.href);return false;

Depending on how 'huge' your timeseries are, you might be pleasantly surprised with Postgres. Postgres scales to multiple TB just fine, and of course the software can be easier to write since you have SQL and ORMs to rely on. It's also an incredibly mature and stable software package, if you're worried about future-proofing.
Some (constantly-growing) timeseries can be stored on a per-row basis, while other (static or older) timeseries can be stored in a packed form (e.g. an array column).
I find that most of the time, "Big Data" isn't really all that big for modern hardware, and so going through all of the extra software work for specialized data stores isn't really all that necessary. YMMV, of course, depending on the nature of your queries.

[Сабина]

Кстати неплохой критерий - просто и со вкусом

Approximately, if you have something like 10+ billion items, use Cassandra.

[valchkou]

Из того что я накопала - Cassandra неплохо подходит для timeseries like data. Может сразу Хадуп / Спарк ?

подходит, но занятие не для слабонерных.
Это же надо все поднять, настроить и задизайнить.
Хотя поднять сам кластер из 5-6 нод уйдет дня 3 не более для новичка.
кстати http://www.datastax.com/products/datast ... -analytics" onclick="window.open(this.href);return false;
кассандра идет вместе со спарком, они даже будут запускаться вместе на одном хосте, одним нажатием кнопки.
Для не прод - бесплатно. Никаких лицензионных ключей или trial ограничений, можно попробовать.

[VladDod]

Ты с этим работаеш на уровне кода или пользуешь?

Пользую. Иногда надо что то достать или добавить - SQL из под скрипта ... на уровне "select, case, update".

[Сабина]

Какой partitioning в PostreSQL развесистый кто бы мог подумать?
http://www.postgresql.org/docs/9.1/stat ... oning.html" onclick="window.open(this.href);return false;

Каждую партицию по сути руками создавать надо да еше и insert trigger
hash partitioning тока в планах
https://wiki.postgresql.org/wiki/Table_partitioning" onclick="window.open(this.href);return false;

[mskmel]

Точнее может MySQL уже придется выкинуть в помойку , в общем нужен совет коллектива.
В одной конторе собирались метрики с порядка 2000+ серверов, порядка 20 видов - bandwidth in, bandwidth out и нечто называемое rpo ( для сервера и всех его volumes) etc. Считывалось все это дело раз в 10 минут и потом агрегировалось в daily tables .

Такую же задачу делали лет 10 назад на постгрессе для на порядок бОльшего количества устройств, тогда это делали шардингом, но железо было в те времена совсем медленное. Партиций или не было, или были совсем сырые (не помню уже).

"2000+ серверов, порядка 20 видов ... раз в 10 минут"
2000*20*10/60=6666 записей в секунду. Нагрузку именно по сохранению данных потянет обычный лэптоп.

Если народу читающего данные не много, и читают по одному серверу детали за кусок времени, то https://dev.mysql.com/doc/refman/5.1/en ... tions.html" onclick="window.open(this.href);return false;

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

[Сабина]

2000*20*10/60=6666 записей в секунду. Нагрузку именно по сохранению данных потянет обычный лэптоп.

Если народу читающего данные не много, и читают по одному серверу детали за кусок времени, то https://dev.mysql.com/doc/refman/5.1/en ... tions.html" onclick="window.open(this.href);return false;

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

Временные по дням ? Так наверное запросы медленнее будут выполняться потому что across several partitions? У нас большинство запросов идет за последнюю неделю, и один по всему списку (admin), мне казалось партиции должны быть минимум по месяцу. Субпартиции тоже сначала хотела сделать по имени хоста, но запросы идут в основном с customer account Id in where clause.
Надо будет попробовать и такой вариант по любому .

Я поменяла код и запустила крон собирать данные в Postgres, посмотрим что там к понедельнику будет, судя по прочитанному он именно с timeseries должен лучше майсиквела справляться.

А шардинг в чем именно состоял ? Многие под шардингом подразумевают те же партиции. Как я понимаю вы разбили на сервера которые каждый обслуживал определенный account range? Под это дело ведь и код нужно менять глобально ?
Пока тут стоит percona cluster но это просто для failover - две реплики одной и той же базы

[Easbayguy]

Точнее может MySQL уже придется выкинуть в помойку , в общем нужен совет коллектива.
В одной конторе собирались метрики с порядка 2000+ серверов, порядка 20 видов - bandwidth in, bandwidth out и нечто называемое rpo ( для сервера и всех его volumes) etc. Считывалось все это дело раз в 10 минут и потом агрегировалось в daily tables .
Теперь выкатили новые requirements - нужно это все собирать и хранить в raw виде чтобы юзеры могли вытащить каждый sample, zoom in, zoom out etc. В общем практически big data
Я написала себе программулину, которая моделирует объем данных и получается что если собирать их по прежнему в MySQL то без daily rollups не обойтись , иначе performance аналитических запросов вообще никакая, в сутки пишется порядка 40 миллионов рекордов. Пытаюсь переделать таблицы и партиции, играюсь с индексами, query tuning, но толк почти нулевой.

Что можно еще попробовать ? Из того что я накопала - Cassandra неплохо подходит для timeseries like data. Может сразу Хадуп / Спарк ?

Вот тут та и приходит попа, весело будет когда индех коррапнется.

[Сабина]

Да и еще все индексы дропнуть вроде не вариант. Нужен как минимум primary key по комбинации time stamp + metric Id + host name

[Сабина]

Eastbayguy, о какой попе речь и какой именно индекс должен корапнуться ?

[mskmel]

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

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

Я поменяла код и запустила крон собирать данные в Postgres, посмотрим что там к понедельнику будет, судя по прочитанному он именно с timeseries должен лучше майсиквела справляться.

Зачем прыгать с БД на БД даже не попробовав уже имеющуюся? Для mysql у вас уже есть специалисты.

А шардинг в чем именно состоял ? Многие под шардингом подразумевают те же партиции. Как я понимаю вы разбили на сервера которые каждый обслуживал определенный account range? Под это дело ведь и код нужно менять глобально ?

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

[Сабина]

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

Да sharding не нужен я согласна. а вот с "иногда запрашивать" проблема. Сейчас вообще сделано так что просто волосы дыбом, все из-за того что база не тянет. UI code в каждой сессиии вытаскивает из вебсервиса 15-20К samples/rows и агрегирует на клиенте. Они до недавнего времени делали daily rollups, но по новым requirements нужно и raw data и aggregated причем минимум за два года.
При таком раскладе много чего нучно поменять - без caching at the service layer не обойтись, а самое главное оптимизировать object model и базу чтобы те хотя бы last 2 weeks data возврашали быстро.
PostgresSQL - потому что речь идет о microservices и там базу можно выбрать другую с нуля, не обязательно чтобы совпадала в базой которая в monolithic app

[stenking]

Тут без разницы какая база данных. 40М в сутки значит то так просто квирей не посчитаеш и нужно время. Т.е. даже если спарк в 10 раз быстрее будет то какая разница - все равно аналитика будет считается 10 минут вместо 2 часов.

Т.е. подходить нужно с позиций - а что именно нужно и если нужно дату быстро то делать промежуточные расчёты вперёд а если нужно считать on demand то делать что бы репорты в бэкграунде работали и юзеру потом нотификейшин слать.

Ну и для таких вещей я бы ещё https://www.elastic.co/products/elasticsearch" onclick="window.open(this.href);return false; посмотрел - он как раз предназначен что бы отвечать на вопросы типа а сколько серверов имело траффик за последние 2 дня больше чем за последние 2 недели

[Сабина]

Ну и для таких вещей я бы ещё https://www.elastic.co/products/elasticsearch" onclick="window.open(this.href);return false; посмотрел - он как раз предназначен что бы отвечать на вопросы типа а сколько серверов имело траффик за последние 2 дня больше чем за последние 2 недели

Интересная штука. Не на предмет использовать а чисто ознакомительно

[stenking]

Ну и для таких вещей я бы ещё https://www.elastic.co/products/elasticsearch" onclick="window.open(this.href);return false; посмотрел - он как раз предназначен что бы отвечать на вопросы типа а сколько серверов имело траффик за последние 2 дня больше чем за последние 2 недели

Интересная штука. Не на предмет использовать а чисто ознакомительно

Почему не использовать. Использовать его как раз нужно - он быстрый, поднимается с полпинка и шардается также. Т.е. он как раз и нужен что бы дату на лету обрабатывать а вот writes туда немного медленные. Другое дело что например сложная выборка по миллиарду записей это всегда долго и тут нужно смотреть как именно архитектуру сделать в зависимости от конкретных вопросов которые возникают к этой дате.

[stenking]

2000*20*10/60=6666 записей в секунду. Нагрузку именно по сохранению данных потянет обычный лэптоп.
.

2000*20/(10*60) = 66

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

[Сабина]

2000*20*10/60=6666 записей в секунду. Нагрузку именно по сохранению данных потянет обычный лэптоп.
.

2000*20/(10*60) = 66

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

Сохранить то не проблема как раз, проблема вытащить нужные варианты быстро. Там есть и запрос cross all accounts (admin) и по эккаунту - агрегированные за неделю по дням и latest.
Моя мысль была на каждый сервер ( account range) создать свой микросервис. А потом сделать REST endpoint ( API Gateway), который будет сначала из distirubted cache в основном ( Redis ?) вытаскивать aggregated for a day ( за предидущие дни недели, until yesterday inclusive) + latest and greatest for today из самого сервиса

[Сабина]

Почему не использовать.

Тут ops support нулевой. Народ умудряется один и тот же mysql deployment портачить каждый раз, что уж тут говорить про совсем незнакомый фреймворк

[stenking]

Почему не использовать.

Тут ops support нулевой. Народ умудряется один и тот же mysql deployment портачить каждый раз, что уж тут говорить про совсем незнакомый фреймворк

https://qbox.io/pricing" onclick="window.open(this.href);return false;

[Сабина]

https://qbox.io/pricing" onclick="window.open(this.href);return false;

Да, клауд у них "свой", как говорится "There is no cloud. It is just someone else's computer" (C)

[mskmel]

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

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