MYSQL оптимизация

Приветствую

Ищу великого знатока Mysql и оптимизатора баз данных
Желательно знакомым с движком KVS
Всех почасовых админов прошу не беспокоить ибо нужен результат а не копание в серваке по времени
Оплату гарантирую

Можете в личку

Всем спасибо

привет

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


потому что оптимизровать в мускуле кроме как сделать индексы и задрать память до предела просто и почти нечего,
(а квс я уверен индексы итак правильно поставил на своих таблицы )

единственная "оптимизация" которая там возможная, перевести все таблицы в иннодб и поставить innodb_buffer_pool_size= на 80% от озу на серваке,
если это не помогает не поможет больше ничего, и конечно это должен быть железный сервер, а не вдс)

и то как мертвому приправа, на интенсивных некешированных запросах это все не поможет
либо просто удаляй старые данные ах.

все остальное это уже копания не в мускуле а в софте.

ну и, есть очень дельная база, которая справляется как с большими таблицами так и тайм-сайрес таблицами (то,где как раз мускул слаб и убог)

https://github.com/pingcap/tidb

и оно даже поддерживает протокол мускула (т.е. просто заменяешь сервер на новый, а софт ничего не поймет, в идеале)

xjam писал:

единственная "оптимизация" которая там возможная, перевести все таблицы в иннодб и поставить innodb_buffer_pool_size= на 80% от озу на серваке, если это не помогает не поможет больше ничего, и конечно это должен быть железный сервер, а не вдс)

Давно переведен на innodb
256 GB оперативы на серваке SSD диски, в общем мегамонстр сервак

xjam писал:

мускул никогда не подходил на вебсайтов,

И тем не менее КВС использует именно его и мои предложения сменить мускуль на что то более пригодное ответили мне что нужно все с нуля переделывать и на это никто не пойдет

И я когда начинал проект то не предполагал что он вырастет до таких масштабов чтобы впоследствии КВС мне сказали что я слишком крупный для их движка и в оптимизации они мне вряд ли помогут

Securom писал:

256 GB оперативы на серваке SSD диски, в общем мегамонстр сервак

Один что-ли? Выделенный под базу или используется и другими приложениями?
Взять несколько серверов и использовать часть под запись, а другие под чтение (увеличивая производительность каждой части соответственно растущим потребностям) уже предлагали?

Mika писал:

Один что-ли? Выделенный под базу или используется и другими приложениями?

Один чисто под базу

Mika писал:

Взять несколько серверов и использовать часть под запись, а другие под чтение (увеличивая производительность каждой части соответственно растущим потребностям) уже предлагали?

Некому предлагать
Вот и ищу кто запилит

А до этого какие оптимизации делались?

Вообще оптимизировать мускл дело такое...

Понятно, что нужны правильные индексы.

Подобрать значения буферов: чтения, сортировок, объединения.

open_files_limit (возможно в ОС надо поднять значения и для самого мускуля)

таймауты подобрать

число коннектов и кеш этих конектов

какой размер пула, чтобы все данные влезли, сколько инстансов

innodb_flush_method
innodb_flush_log_at_trx_commit
innodb_checksum_algorithm = crc32


на больших rps и данных рекомендуют
query_cache_type = 0

либо сбрасывать кеш периодически


ну и понятно что slow query log надо смотреть, иначе без толку будет. собрать лог и разобрать, например, pt-query-digest

ну и кроме мускула есть типа марии или перконы

все намного прозаичнее,
как же я был неправ, говоря, что у КВС с индексами все в порядке.

мало того, он при каждом запросе дергает процеслист сервера (зачем, можно хотя-бы кешить на 10 скеунд мля) только отключив это, нагрузка упала на 20%

они еще и индексы везде неправильно прописали, без обид, прям везде неправильно индексы стоят
а именно бОльшая часть индексов соединены вместе почему-то, хотя простой EXPLAIN показывает что индексы не используются.

Всем трафика.

Скорей всего оптимизацией здесь не обойтись, надо искать узкие места и переписывать их, вводить кеш на NoSQL, где можно.
Для начала надо проанализировать, что грузит. Может достаточно будет забанить ботов, китайцев. Может перенастроить или отключить часть некритичного функционала.

P.S. По части оптимизаций могу помочь. Например, сделать кеширование в Redis или переписать часть на С++ с применением FastCGI.

В Редис кешировать можно, но он загнуться может,, сам редис, это однопоточное, к сожалению, которое не выдерживает очень много интенсивных запросов.
похожий кеш, написанный на GO, работает в 100 раз быстрее примерно и не лочиться (каш разделяться по бакетам на основе захешированного ключа, что уменьшает лок)

У меня есть решение, которые синкает базу в память и понимает sql даже немного, однако не понимает субселекеты, которых в КВС дохера и больше, причем везде рекомендуют не юзать субзапросы их проше кешировать, но нет,

а индесы у них созданы , внимание, для СОРТИРОВКИ БАЗЫ (напр: активные юзеры сверху, неактивные снизу), хотя даже студенты знают, что для сортировки НУЖНО юзать ORDRE BY


в итоге половина базы лежит в статусе "Creating sort index", гугление показывает, что такое бывает тогда, когда есть субселекты и кривые индексы на сортировку как раз (т.е. праймари ключь у них - не то что надо)

пример:

CREATE TABLE `ktvs_tags_videos` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`tag_id` int(10) unsigned NOT NULL,
`video_id` int(10) unsigned NOT NULL,
`cr_dlist` bigint(20) unsigned NOT NULL DEFAULT '0',
`cr_ccount` bigint(20) unsigned NOT NULL DEFAULT '0',
`cr_cweight` decimal(20,4) unsigned NOT NULL DEFAULT '0.0000',
`cr_ctr` decimal(20,4) unsigned NOT NULL DEFAULT '0.0000',
PRIMARY KEY (`tag_id`,`video_id`),
UNIQUE KEY `id` (`id`),
KEY `video_id` (`video_id`),
KEY `cr_ctr` (`cr_ctr`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

На GO свое решение или что то из awesome go?

Стоит понимать что KVS - это массовая CMS и на ней запускаются многие тысячи проектов в самых разных сферах.
При этом KVS является конструктором и без изменений PHP кода возможно добавлять любые новые страницы с разным функционалом или менять текущие.
KVS обладает огромной универсальностью, но именно она и накладывает некоторые утяжеления вроде массы индексов т.к. учитываются множества вариантов использования.

В целом KVS легко справляется с 99% проектами уровня 300к траффика, тут главным образом проблема не в траффике, KVS его хорошо держит, а в обьеме базы данных. Конечно, если идет накопление сотен тысяч видео, уже возникает нагрузка на базу данных, тут уже многое зависит от конкретного проекта и конечно проекты с большим траффиком и большим количеством информации уже где-то требуют частного вмешательства.

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

В настоящее время мы завершаем 5.2.0 версию с огромным количеством поправок и постараемся после еще больше сконцентрироваться на оптимизации.

Также, справедливости ради, отметим что на KVS без поправок работают многие проекты с большим 1М траффиком, поэтому всё зависит от конкретного проекта. Мы же всегда открыты, новые версии выпускаются уже второй десяток лет, любым новым идеям и замечаниям всегда рады, продолжим в том же духе

freeek писал:

На GO свое решение или что то из awesome go?

Очень сложно писать на GO и не использовать что-то оттуда) например fasthttp