The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Высокопроизводительный MySQL-движок TokuDB переведён в разря..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Есть идеи по улучшению форума и сайта ? Пишите.
. "Высокопроизводительный MySQL-движок TokuDB переведён в разря..." –1 +/
Сообщение от sauronemail (??), 30-Апр-13, 08:34 
> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь,
> индекс, и ничего кроме" - очень даже нужны хинты/форсирование.

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

> "Часто", "реже" - это всё относительно, и зависит от приложения / структуры
> БД. У меня есть большая табличка, аналитическая выборка из которой ломает
> шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что
> все три берут самый очевидный вариант плана запроса, который совершенно неоптимален
> с точки зрения доступа к диску. И переструктурировать ее некуда -
> там явных внутренних связей просто нет, + символьные поля переменной длины.
> С форсированием конкретного индекса (раза в два больше строк в скане,
> зато на порядок меньше время выполнения) же вся аналитика бегает очень
> неплохо.

А не надо так делать и все будет хорошо.

> Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах
> вижу - ситуация прямо обратная.

Пруфлинк на что? Что MySQL хуже держит нагрузки? Вы уйдите с форумов про MySQL и сразу найдете.

> Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части
> индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же
> части индекса - уже не пройдут, и будут ждать выполнения твоей
> транзакции. А до момента COMMIT может пройти много времени.

И? Ну не будет в выборке у меня этих данных и все.

> Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи
> на транзакцию. Например при высоком параллелизме обновления одних и тех же
> таблиц. Zabbix в его нынешнем виде - как раз тот случай.

И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :)

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

Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД работать.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Высокопроизводительный MySQL-движок TokuDB переведён в разря..., opennews, 26-Апр-13, 11:59  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру