The OpenNET Project / Index page

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



"Высокопроизводительный MySQL-движок TokuDB переведён в разря..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Подсказка: Для сортировки сообщений в нити по дате нажмите "Сортировка по времени, UBB".
. "Высокопроизводительный MySQL-движок TokuDB переведён в разря..." +1 +/
Сообщение от AlexAT (ok), 30-Апр-13, 08:06 
> Чуваки из PostgreSQL против хинтов. Они говорят что если у вас оптимизатор
> плохо строит план, то это или бага или у вас ошибка
> при проектировании.

Вот за что и не люблю академические поделки - так это за это самое "а баба яга против". Во-первых - идеальных оптимизаторов не бывает, баги есть у всех, угу. Во-вторых - в случае БД (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику, призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и специфику конкретных приложений могут не понять.

Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По двум причинам:

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

2. Если в оптимизаторе всё-таки встретилась бага. Или фича (см. выше про эмпирику). Ждать месяц, пока эту багу закроют - накладно. Могут и вообще закрывать отказаться - ибо в ущерб другим ворклоудам. Самому патчить - в движок БД своими руками, в одиночку, лезть страшновато, и, опять же - накладно. Исключения быть могут, но и причина должна быть куда более веской.

И если в некой СУБД этого делать не хотят по "академическим" мотивам, навязывая свой паттерн мышления - я просто не буду применять эту СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито. Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент.

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

Если честно - в заббиксе транзакции ничем не помогут производительности. Это так, попутный вывод на основе анализа его запросов при оптимизации. Наоборот - могут усугубить - за счет длительного блокирования.


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

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



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

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