Компания Tokutek открыла (http://www.tokutek.com/2013/04/open-source-tokudb-resources/) исходные тексты проекта TokuDB (http://www.tokutek.com/products/tokudb-for-mysql/) (Tokutek storage engine), в рамках которого развивается высокопроизводительный транзакционный движок хранения для MySQL и MariaDB. Вместо классических B-tree деревьев в TokuDB применяются рекурсивные индексы (Fractal Tree indexes (http://www.tokutek.com/resources/technology/)), что в сочетании с хранением данных в сжатом виде, позволяет значительно оптимизировать операции ввода/вывода.Движок TokuDB оптимален в системах с интенсивной записью, когда требуется накапливать полученную в результате входящих запросов информацию и периодически генерировать на её основе отчёты. В качестве основных областей применения TokuDB называются конфигурации с большим числом запросов, связанных с добавлением, удалением и изменением данных, такие как социальные сети, анализ логов, рекламные сети и т.п.
При проведении тестов (http://www.tokutek.com/resources/benchmark-results/), TokuDB опережает (http://www.tokutek.com/resources/tokudb-vs-innodb/) InnoDB при добавлении больших объемов данных более чем в 10 раз (InnoDB 1,555 записей в сек, TokuDB 16,437 записей в сек), но проигрывает по степени нагрузки на CPU при выборке данных. Недостаточная эффективность выборки данных компенсируется ситуациями когда требуется произвести выборку большого числа последовательно сохранённых записей. В некоторых тестах выигрыш в скорости добавления данных достигает 80 раз. Применяемые методы сжатия данных позволяют в разы уменьшить размер базы и индексов (в 6.2 раза по сравнению с InnoDB и в 5.5 раз по сравнению с MyISAM), в некоторых ситуациях степень сжатия данных может достигать (http://www.tokutek.com/wp-content/uploads/2012/09/Tokutek-to...) 25 раз.<center><a href="http://www.tokutek.com/wp-content/uploads/2012/01/iibench.pn... src="http://www.opennet.me/opennews/pics_base/0_1366962602.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center>
Из особенностей (http://www.tokutek.com/2011/02/1773/) движка TokuDB также можно отметить:
- Обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность, долговечность); - Возможность изменения хранения схемы данных на лету, без перестроения хранилища; - Отсутствие эффекта фрагментации индексов после длительного времени работы базы (нет необходимости пересоздавать индексы для устранения фрагментации);- Гибкие средства ускорения выполнения запросов через использование индексов;- Поддержка создания хранилищ для терабайт данных;- Поддержка создания горячих бэкапов без остановки работы;- Поддержка репликации интенсивно поступающих потоков данных на несколько slave-серверов без отставания появления данных на slave-системах;- Соответствие требованиям MVCC (Multi-Version Concurrency Control) по работе в многопользовательских системах с большим числом одновременных запросов;- Режим быстрого восстановления после сбоя;- Высокая эффективность поддержания хранилищ с десятками и сотнями миллионов записей. Отсутствуют проблемы при активном удалении записей в таких хранилищах;- Поддержка кластерных индексов, в которых непосредственно сохраняются всех данные из записей;- По выполняемым операциям индексы Fractal Tree indexes схожи в B-Tree и отличаются главным образом более оптимальным использованием кэшей и доступа к данным на накопителях на жестких магнитных дисках, за счёт преобразования операций случайного доступа в наборы последовательных запросов. Для SSD-накопителей использование TokuDB оправдано сокращением числа операций записи.
В настоящее время движок TokuDB уже используется проектом Mozilla для организации работы сервиса Datazilla, занимающегося сбором информации о производительности, автоматически отправляемой браузером Firefox, при включении соответствующих настроек. Разработчики MySQL и MariaDB приветствовали (http://www.tokutek.com/2013/04/getting-interesting/) решение по открытию кода TokuDB, заявив, что такой шаг будет способствовать широкому внедрению TokuDB. Более того, компания MariaDB уже рассматривает возможность включения TokuDB в состав MariaDB и поставки данного движка в качестве штатного компонента.Код открыт (https://github.com/Tokutek) под лицензией GPLv2. Изначально движок TokuDB развивался как проприетарный продукт, но компания Tokutek решилась на изменение бизнес-модели, которая теперь подразумевает разработку TokuDB как свободного проекта с предоставлением корпоративным заказчикам коммерческой версии TokuDB Enterprise Edition, которая отличается наличием сервиса технической поддержки, расширенными инструментами для резервного копирования и возможностью адаптации продукта под нужды заказчика.
URL: http://www.tokutek.com/2013/04/open-source-tokudb-resources/
Новость: http://www.opennet.me/opennews/art.shtml?num=36779
Интересно, если Заббикс на этот движок перенести - ему поможет?
Postgres ему точно поможет
> Postgres ему точно поможетНе-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера - половина~ хостов туда, половина сюда.
Партишионинг я не осилил.
Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные (для меня) основные процессы Z.
PostgeSQL хоть потюненый был? Или стоковый воткнули?
Где описано как его "тюнить" для Zabbix?
> Где описано как его "тюнить" для Zabbix?Вообще надо банальный тюнинг под сервер произвести. Если же тюнинг не осуществлялся, то не удивительно что не помогло.
>> Где описано как его "тюнить" для Zabbix?
> Вообще надо банальный тюнинг под сервер произвести. Если же тюнинг не осуществлялся,
> то не удивительно что не помогло.Zabbix написан и заточен под mysql. Если вы не эксперт постгре, я бы не рекомендовал в принципе экспериментировать. Попытки завести заббикс на других базах вынудили меня в конечном итоге вернуться к mysql для заббикса.
> Zabbix написан и заточен под mysql. Если вы не эксперт постгре, я
> бы не рекомендовал в принципе экспериментировать. Попытки завести заббикс на других
> базах вынудили меня в конечном итоге вернуться к mysql для заббикса.ЛОЛ ШТО? Это как же он так внезапно стал заточен под MySQL? Я вот там никаких оптимизаций под него не видел. Никаким особенным экспертом там быть не надо достаточно сделать оптимизацию под сервер
А это не в контексте оптимизаций под mysql, а того, насколько криво написано под postgre =)
> А это не в контексте оптимизаций под mysql, а того, насколько криво
> написано под postgre =)Вы там выдыхайте иногда. Я вообще в код ходил и смотрел. Там разницы особой нет. В том то и дело.
просто вы не видите этой разницы потому что например не знаете как зависят нагрузка на сервер и администрирование от количества insert/update/delete. то что хорошо для mysql плохо для postgres и наоборот. потому что это принципиально разные субд с разными подсистемами хранения.
Конечно конечно. Товарищ если вы начали оптимизировать свой софт под поведение РСУБД это очень плохой звоночек. А именно что или вы плохо спроектировали софт или же выбрали плохую РСУБД. И да замечу, что оптимизировать под количество операций записи надо под MySQL исключительно в силу того что ему плохеет от их большого количества. В случае PostgreSQL при той же нагрузке этого не наблюдается.
> Конечно конечно. Товарищ если вы начали оптимизировать свой софт под поведение РСУБД
> это очень плохой звоночек.А если не начали - то это очень плохой звоночек...
> А если не начали - то это очень плохой звоночек...Оптимизировать под конкретную реализацию РСУБД на начальной стадии проектирования просто не имеет смысла. Если же это надо делать, то лучше подумать о смене РСУБД. А не под тем как под нее заточить свой софт.
> Оптимизировать под конкретную реализацию РСУБД на начальной стадии проектирования просто
> не имеет смысла. Если же это надо делать, то лучше подумать
> о смене РСУБД. А не под тем как под нее заточить
> свой софт.Имеет. Потому что переоптимизировать всё на конечной стадии может уже и не получиться. Хороший пример - Zabbix. Одинаково хреново работает на всех СУБД, и очень тяжело допилить под конкретный двиг. Когда допиливаешь - такое ощущение, что ребята вообще абстрагировались от реаль^W оптимизации, и достигли нирваны в процессе написания.
Сохранить модульность при оптимизации под двиг - та еще задача. С другой стороны, законченному решению редко нужна поддержка более одной СУБД.
> Имеет. Потому что переоптимизировать всё на конечной стадии может уже и не
> получиться. Хороший пример - Zabbix.Не имеет. Стандарт SQL-92 и общие концепции не зря придумывали.
> Одинаково хреново работает на всех СУБД, и очень тяжело допилить под конкретный двиг.
> Когда допиливаешь - такое ощущение, что ребята вообще абстрагировались от реаль^W
> оптимизации, и достигли нирваны
> в процессе написания.Он одинаково хреново работает на всех СУБД потому что чуваки которые его писали, про что такое РСУБД не сном ни духом. Я в код его между прочим заглядывал. А MySQL существенно чувствительнее к таким ошибкам чем PostgreSQL. Oracle как раз является лидером среди РСУБД потому что еще менее чувствителен к таким ошибкам.
> Сохранить модульность при оптимизации под двиг - та еще задача. С другой
> стороны, законченному решению редко нужна поддержка более одной СУБД.В случае zabbix вот как раз проблемы не было. Там нет такой суровой необходимости оптимизировать под конкретную РСУБД. Надо знать про то как они работают и писать с учетом этих особенностей. К примеру начать уже использовать транзакции при записи данных. А они там даже не ночевали.
> Не имеет. Стандарт SQL-92 и общие концепции не зря придумывали.Угу. Вот только есть особенности, которых этот стандарт совершенно не учитывает. Например, собственно, механику работы движка, которую он никак не описывает.
Поэтому в общем случае голого стандарта достаточно только для микронных баз и примитивных паттернов доступа. Для всего остального начинается специфика.
> Он одинаково хреново работает на всех СУБД потому что чуваки которые его
> писали, про что такое РСУБД не сном ни духом.Да нет. Написано в целом достаточно нормально, вот только... как раз таки абстракция от движка БД не позволила использовать специфику. В итоге приходится пилить руками.
> Я в код его между прочим заглядывал.
Заглядывать - мало. Недавно этот код по сути ныне до ума довел, во всяком случае самые жесткие затыки в нашей боевой инсталляции исчезли. Правда патчем это толкать в оригинал бессмысленно, поскольку оно теперь MySQL-only.
> они работают и писать с учетом этих особенностей. К примеру начать
> уже использовать транзакции при записи данных. А они там даже не
> ночевали.Транзакции там только усугубят ситуацию. Основная проблема внутри заббикса - в "универсальных" удобных коду выборках, не учитывающих особенности движка. Причем в самых-самых критических местах. После переписывания десятка оных всё становится на места.
Если кто бьется до сих пор - даю наводку: в первую голову смотрите выборки, совмещающие functions и triggers. Там наибольшая загвоздка с оптимизацией.
> Угу. Вот только есть особенности, которых этот стандарт совершенно не учитывает. Например,
> собственно, механику работы движка, которую он никак не описывает.И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо.
> Поэтому в общем случае голого стандарта достаточно только для микронных баз и
> примитивных паттернов доступа. Для всего остального начинается специфика.Пример такой специфики в студию.
> Да нет. Написано в целом достаточно нормально, вот только... как раз таки
> абстракция от движка БД не позволила использовать специфику. В итоге приходится
> пилить руками.Вот не надо ля-ля. Код там ужасен. Я уж молчу что переключение между СУБД производится на стадии компиляции. Прям у нас движков абстракции под C нет. Тот же libdbi можно взять.
> Заглядывать - мало. Недавно этот код по сути ныне до ума довел,
> во всяком случае самые жесткие затыки в нашей боевой инсталляции исчезли.
> Правда патчем это толкать в оригинал бессмысленно, поскольку оно теперь MySQL-only.Это говорит о том что это хреновое решение. Фактически для исправления проблем у zabbix требуется запилить там нормальную работу с транзакциями. И это худо бедно начнет нормально работать в том числе и на MySQL.
> Транзакции там только усугубят ситуацию. Основная проблема внутри заббикса - в "универсальных"
> удобных коду выборках, не учитывающих особенности движка. Причем в самых-самых критических
> местах. После переписывания десятка оных всё становится на места.У zabbix основная проблема плохой работы на MySQL это массированные атомарные записи в базу. Если это переделать на транзакции станет заметно лучше. То что они читают все без разбора меньшее зло.
>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо.Несколько примеров:
- Использование LIMIT x,y (нет в MSSQL, к примеру)
- Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется с подзапросами)
- Для TokuDB - создание всех необходимых индексов, без оглядки на скорость модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс даже при обилии модификаций
- Правильное партиционирование таблиц
- Приведение типов столбцов в связках (в MySQL с этим очень строго)
- Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора (специфично для каждого движка)>> Поэтому в общем случае голого стандарта достаточно только для микронных баз и
>> примитивных паттернов доступа. Для всего остального начинается специфика.
> Пример такой специфики в студию.Пример специфики - например, избавление от full scan / больших range scan по мере возможности. В принципе актуально для любого движка. Партиционирование и использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборки и анализа в код (хранимки / клиент), максимизация использования индексов. Использование движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем сканирования). Построение покрывающих индексов. И так далее.
> Это говорит о том что это хреновое решение.
Предложите лучше для _большой_ сети (>2500 хостов).
> Фактически для исправления проблем у zabbix требуется запилить там нормальную работу с транзакциями.
И чем это поможет? Только давайте конкретно, без воды: где именно в заббиксе производительности поможет транзакционность?
> У zabbix основная проблема плохой работы на MySQL это массированные атомарные записи
> в базу.Не встретил даже на InnoDB. А на TokuDB это вообще не проблема. Вот не поверишь - ни разу не встал колом на записи, зато на чтении постоянно вставал колом в огромных range read.
Пока не переписал ряд запросов. Основная проблема там - это массированные range scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000 триггеров, причем встает раком...
>>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо.
> Несколько примеров:
> - Использование LIMIT x,y (нет в MSSQL, к примеру)вообще limit offset поддерживается в том числе и в MySQL и в PostgreSQL и Oracle
> - Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в
> ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется
> с подзапросами)explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в MySQL работают быстрее подзапросов.
> - Для TokuDB - создание всех необходимых индексов, без оглядки на скорость
> модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс
> даже при обилии модификацийЭто вообще специфика движка и к приложению никакого отношения не имеет.
> - Правильное партиционирование таблиц
Это тоже не имеет никакого отношения к приложению
> - Приведение типов столбцов в связках (в MySQL с этим очень строго)
Это уже вопросы к разработчикам.
> - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора
Это тоже не имеет никакого отношения к приложению.
> Пример специфики - например, избавление от full scan / больших range scan
> по мере возможности. В принципе актуально для любого движка. Партиционирование и
> использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборкиЭто точно так же делается на PosgtreSQL различия минимальны.
> и анализа в код (хранимки / клиент), максимизация использования индексов. Использование
> движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree
> отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц
> для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем
> сканирования). Построение покрывающих индексов. И так далее.Это может делятся уже и после того как приложение запущено и это вот как раз при разработке вообще можно не учитывать.
> Предложите лучше для _большой_ сети (>2500 хостов).
К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно не мешает ему иметь ужасный код в основе ;)
> И чем это поможет? Только давайте конкретно, без воды: где именно в
> заббиксе производительности поможет транзакционность?Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL.
У нас чинилось переходом на PostgreSQL, где с записью все лучше.
> Не встретил даже на InnoDB. А на TokuDB это вообще не проблема.TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как работа housekeeper приводила к стоянию колом MySQL сервера. Да и в целом нагрузка на сервер была больше.
> Вот не поверишь - ни разу не встал колом на записи,
> зато на чтении постоянно вставал колом в огромных range read.Вот увы не поверю. Основная проблема это запись. Которая затем выливается в проблемы при чтении.
> Пока не переписал ряд запросов. Основная проблема там - это массированные range
> scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000
> триггеров, причем встает раком...Основная проблема криворукость писателей zabbix которые часто даже в explain не удосуживаются посмотреть.
> вообще limit offset поддерживается в том числе и в MySQL и в
> PostgreSQL и OracleВ MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL, и в PGSQL, и в Oracle.
> explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в
> MySQL работают быстрее подзапросов.Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые.
> Это вообще специфика движка и к приложению никакого отношения не имеет.
Мы же о специфике и говорили? Ее надо учитывать, если хочется получить результат выше среднего в сложных условиях и по пересеченной местности. Если средний или около того - то сойдёт что угодно.
>> - Правильное партиционирование таблиц
> Это тоже не имеет никакого отношения к приложениюИмеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне быть написаны с учётом оного.
>> - Приведение типов столбцов в связках (в MySQL с этим очень строго)
> Это уже вопросы к разработчикам.Именно. В MSSQL не так строго. Но это - специфика.
>> - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора
> Это тоже не имеет никакого отношения к приложению.Имеет, причём 100%.
> Это может делятся уже и после того как приложение запущено и это
> вот как раз при разработке вообще можно не учитывать.Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со стабильностью, увы.
>> Предложите лучше для _большой_ сети (>2500 хостов).
> К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно
> не мешает ему иметь ужасный код в основе ;)Если он по фичам лучше всего - то это не "хреновое решение"? Да, оно может и ужасно по коду, но при этом оно минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже, в общем, не блещут - ресурсов им надо немеряно.
> Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL.
Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да и в InnoDB их нет, если не злоупотреблять столбцами и индексами, и сознательно строить базу с максимальным обходом блокировок.
> У нас чинилось переходом на PostgreSQL, где с записью все лучше.У нас все проще - после переписывания нескольких запросов всё встало на места с чтением. А с записью проблем не было и нет.
Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать не буду.
> TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как
> работа housekeeper приводила к стоянию колом MySQL сервера.Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки обрабатывают по 1 элементу за 1 раз, хотя можно было оптом обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились, может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел - но его вообще в статистике не видно.
> Вот увы не поверю. Основная проблема это запись.
У нас ситуация иная. Колом вставало именно чтение, причем записи в этот момент не было. Несколько переписанных запросов - и больше колом не встает ничего.
> В MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL,
> и в PGSQL, и в Oracle.MSSQL - это своя атмосфера. В остальных есть.
> Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые.
Хорошо в большинстве случаев.
> Мы же о специфике и говорили? Ее надо учитывать, если хочется получить
> результат выше среднего в сложных условиях и по пересеченной местности. Если
> средний или около того - то сойдёт что угодно.Все вами перечисленное может быть уже сделано по месту. Лучше уделить больше внимания проектированию самой базы и архитектуры программы.
> Имеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне
> быть написаны с учётом оного.Вот приложение про партицирование знать особо ничего не должно. Его просто делают под типичные запросы.
> Имеет, причём 100%.Не имеет так-как может быть добавлено после разработки приложения. И указывать в приложении использовать вот этот индекс не нужно и часто вообще вредно. Из-за этого к примеру нет хинтов в PostgreSQL.
> Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или
> как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со
> стабильностью, увы.Вполне совместимый если у вас нормально спроектирована СУБД.
> Если он по фичам лучше всего - то это не "хреновое решение"?
Хреновое, так-как можно сделать и оптимальнее.
> Да, оно может и ужасно по коду, но при этом оно
> минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже,
> в общем, не блещут - ресурсов им надо немеряно.С ПО вообще все сложно. Отличные приложения встречаются, но редко.
> Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да
> и в InnoDB их нет, если не злоупотреблять столбцами и индексами,
> и сознательно строить базу с максимальным обходом блокировок.В TokuDB не будет. А вот в InnoDB сталкивался, правда это было года три назад, там еще у InnoDB были серьезные проблемы с масштабируемостью.
> Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать
> не буду.Да где-то как у вас.
> Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки
> обрабатывают по 1 элементу за 1 раз, хотя можно было оптом
> обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились,
> может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел
> - но его вообще в статистике не видно.Да нет удаляли они уже тогда пачками. Но это плохо сказывалось на работу записи.
> У нас ситуация иная. Колом вставало именно чтение, причем записи в этот
> момент не было. Несколько переписанных запросов - и больше колом не
> встает ничего.Ну черт знает. Я только могу резюмировать, что после перехода на PostgreSQL про прыганья вокруг СУБД шоб работало я забыл.
> Из-за этого к примеру нет хинтов в PostgreSQL.А зря. Иногда единственный способ обойти оптимизатор, не лезя в код собственно движка СУБД. Иногда - нужный, поскольку я например местами куда лучше эвристики оптимизатора знаю, как лучше тот или иной запрос сгрести с диска :) А стохастика в MSSQL вообще убивает xD
> В TokuDB не будет. А вот в InnoDB сталкивался, правда это было
> года три назад, там еще у InnoDB были серьезные проблемы с
> масштабируемостью.Ну да, три года назад - и я с Вами согласился бы :)
> Да нет удаляли они уже тогда пачками. Но это плохо сказывалось на
> работу записи.Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за этого года два назад на заббих было положено ровно на год :)
> А зря. Иногда единственный способ обойти оптимизатор, не лезя в код собственно
> движка СУБД. Иногда - нужный, поскольку я например местами куда лучше
> эвристики оптимизатора знаю, как лучше тот или иной запрос сгрести с
> диска :) А стохастика в MSSQL вообще убивает xDЧуваки из PostgreSQL против хинтов. Они говорят что если у вас оптимизатор плохо строит план, то это или бага или у вас ошибка при проектировании.
> Ну да, три года назад - и я с Вами согласился быВполне может быть что в крайних версиях MySQL и MariaDB это пофиксили. Но там еще много других претензий есть, так что я пока лучше PostgreSQL буду использовать и не знать головной боли.
> Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом
> DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за
> этого года два назад на заббих было положено ровно на год
> :)Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций.
>[оверквотинг удален]
> при проектировании.
>> Ну да, три года назад - и я с Вами согласился бы
> Вполне может быть что в крайних версиях MySQL и MariaDB это пофиксили.
> Но там еще много других претензий есть, так что я пока
> лучше PostgreSQL буду использовать и не знать головной боли.
>> Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом
>> DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за
>> этого года два назад на заббих было положено ровно на год
>> :)
> Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций.подобие хинтов таки появилось
http://habrahabr.ru/post/169751/
> подобие хинтов таки появилось
> http://habrahabr.ru/post/169751/О как. Видать кого-то здорово припёрло как раз тем, о чём я ниже в #136 написал.
Жалко только, что костыль - де-факто - unsupported модуль. Его надо в основную ветку проталкивать.
> Чуваки из PostgreSQL против хинтов. Они говорят что если у вас оптимизатор
> плохо строит план, то это или бага или у вас ошибка
> при проектировании.Вот за что и не люблю академические поделки - так это за это самое "а баба яга против". Во-первых - идеальных оптимизаторов не бывает, баги есть у всех, угу. Во-вторых - в случае БД (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику, призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и специфику конкретных приложений могут не понять.
Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По двум причинам:
1. Если я точно знаю, что мой набор данных быстрее соберется именно вот с этого вот боку, а иные варианты проектирования - еще хуже в обозримом круге вариантов - то зачем мне все усилия оптимизатора по приоритизации таблиц и индексов, к примеру? Тем более, что он часто ошибается.
2. Если в оптимизаторе всё-таки встретилась бага. Или фича (см. выше про эмпирику). Ждать месяц, пока эту багу закроют - накладно. Могут и вообще закрывать отказаться - ибо в ущерб другим ворклоудам. Самому патчить - в движок БД своими руками, в одиночку, лезть страшновато, и, опять же - накладно. Исключения быть могут, но и причина должна быть куда более веской.
И если в некой СУБД этого делать не хотят по "академическим" мотивам, навязывая свой паттерн мышления - я просто не буду применять эту СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито. Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент.
> Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций.
Если честно - в заббиксе транзакции ничем не помогут производительности. Это так, попутный вывод на основе анализа его запросов при оптимизации. Наоборот - могут усугубить - за счет длительного блокирования.
> Вот за что и не люблю академические поделки - так это за
> это самое "а баба яга против". Во-первых - идеальных оптимизаторов не
> бывает, баги есть у всех, угу. Во-вторых - в случае БД
> (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику,
> призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением
> данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор
> плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и
> специфику конкретных приложений могут не понять.А специфика конкретных приложений затачивается уже указанием индексов. Если вот это надо быстро то стоит делать материализированный виев.
> Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По
> двум причинам:
> 1. Если я точно знаю, что мой набор данных быстрее соберется именно
> вот с этого вот боку, а иные варианты проектирования - еще
> хуже в обозримом круге вариантов - то зачем мне все усилия
> оптимизатора по приоритизации таблиц и индексов, к примеру? Тем более, что
> он часто ошибается.В MySQL часто. В PostgreSQL существенно реже.
> И если в некой СУБД этого делать не хотят по "академическим" мотивам,
> навязывая свой паттерн мышления - я просто не буду применять эту
> СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито.
> Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент.Да сколько угодно. Проблема только в том что MySQL все еще хуже по фичам чем PostgreSQL ивсе так же плохо держит нагрузку.
> Если честно - в заббиксе транзакции ничем не помогут производительности. Это так,
> попутный вывод на основе анализа его запросов при оптимизации. Наоборот -
> могут усугубить - за счет длительного блокирования.Какого еще длительного блокирования? Ну пишу я себе там в потоке ни у ладно. Блокировка таблицы в MySQL возникает только при самом высоком уровне изоляции или при применении MyISAM. А вот его применять пожалуй не стоит.
> А специфика конкретных приложений затачивается уже указанием индексов.Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, индекс, и ничего кроме" - очень даже нужны хинты/форсирование.
> В MySQL часто. В PostgreSQL существенно реже.
"Часто", "реже" - это всё относительно, и зависит от приложения / структуры БД. У меня есть большая табличка, аналитическая выборка из которой ломает шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что все три берут самый очевидный вариант плана запроса, который совершенно неоптимален с точки зрения доступа к диску. И переструктурировать ее некуда - там явных внутренних связей просто нет, + символьные поля переменной длины. С форсированием конкретного индекса (раза в два больше строк в скане, зато на порядок меньше время выполнения) же вся аналитика бегает очень неплохо.
> Да сколько угодно. Проблема только в том что MySQL все еще хуже
> по фичам чем PostgreSQL ивсе так же плохо держит нагрузку.Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах вижу - ситуация прямо обратная.
> Какого еще длительного блокирования? Ну пишу я себе там в потоке ни
> у ладно.Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же части индекса - уже не пройдут, и будут ждать выполнения твоей транзакции. А до момента COMMIT может пройти много времени.
Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи на транзакцию. Например при высоком параллелизме обновления одних и тех же таблиц. Zabbix в его нынешнем виде - как раз тот случай.
Хотя - да, его бы переписать с прямой записи в таблицы на каждый чих на очередь обновления - и он нормально бы с транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в этом направлении там уже есть, но пока что не везде.
> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь,
> индекс, и ничего кроме" - очень даже нужны хинты/форсирование.Если у вас возникает такая надобность, то надо внимательно посмотреть на свою базу данных.
> "Часто", "реже" - это всё относительно, и зависит от приложения / структуры
> БД. У меня есть большая табличка, аналитическая выборка из которой ломает
> шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что
> все три берут самый очевидный вариант плана запроса, который совершенно неоптимален
> с точки зрения доступа к диску. И переструктурировать ее некуда -
> там явных внутренних связей просто нет, + символьные поля переменной длины.
> С форсированием конкретного индекса (раза в два больше строк в скане,
> зато на порядок меньше время выполнения) же вся аналитика бегает очень
> неплохо.А не надо так делать и все будет хорошо.
> Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах
> вижу - ситуация прямо обратная.Пруфлинк на что? Что MySQL хуже держит нагрузки? Вы уйдите с форумов про MySQL и сразу найдете.
> Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части
> индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же
> части индекса - уже не пройдут, и будут ждать выполнения твоей
> транзакции. А до момента COMMIT может пройти много времени.И? Ну не будет в выборке у меня этих данных и все.
> Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи
> на транзакцию. Например при высоком параллелизме обновления одних и тех же
> таблиц. Zabbix в его нынешнем виде - как раз тот случай.И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :)
> Хотя - да, его бы переписать с прямой записи в таблицы на
> каждый чих на очередь обновления - и он нормально бы с
> транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в
> этом направлении там уже есть, но пока что не везде.Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД работать.
>> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь,
>> индекс, и ничего кроме" - очень даже нужны хинты/форсирование.
> Если у вас возникает такая надобность, то надо внимательно посмотреть на свою
> базу данных.дело не в базе данyых, дело в том что постгрес использует оптимизатор который работает на т.н. "генетических алгоритмах", это немного из области ИИ, и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ отменяют того, что оптимизатор выдаёт кривой план.
>>> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь,
>>> индекс, и ничего кроме" - очень даже нужны хинты/форсирование.
>> Если у вас возникает такая надобность, то надо внимательно посмотреть на свою
>> базу данных.
> дело не в базе данyых, дело в том что постгрес использует оптимизатор
> который работает на т.н. "генетических алгоритмах", это немного из области ИИ,
> и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ
> отменяют того, что оптимизатор выдаёт кривой план.P.S.
http://www.postgresql.org/docs/8.2/static/geqo-pg-intro.html
"
48.3.1. Future Implementation Tasks for PostgreSQL GEQOWork is still needed to improve the genetic algorithm parameter settings. In file src/backend/optimizer/geqo/geqo_main.c, routines gimme_pool_size and gimme_number_generations, we have to find a compromise for the parameter settings to satisfy two competing demands:
Optimality of the query plan
Computing time
At a more basic level, it is not clear that solving query optimization with a GA algorithm designed for TSP is appropriate. In the TSP case, the cost associated with any substring (partial tour) is independent of the rest of the tour, but this is certainly not true for query optimization. Thus it is questionable whether edge recombination crossover is the most effective mutation procedure.
"
т.е. поле для работы есть. местами обширное.
> дело не в базе данyых, дело в том что постгрес использует оптимизатор
> который работает на т.н. "генетических алгоритмах", это немного из области ИИ,
> и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ
> отменяют того, что оптимизатор выдаёт кривой план.Это на сильно не тривиальных выборках бывает и там покрутить можно для изменения поведения.
>> дело не в базе данyых, дело в том что постгрес использует оптимизатор
>> который работает на т.н. "генетических алгоритмах", это немного из области ИИ,
>> и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ
>> отменяют того, что оптимизатор выдаёт кривой план.
> Это на сильно не тривиальных выборках бывает и там покрутить можно для
> изменения поведения.говорю как есть, может у меня конечно чего с руками, НО...
мы (втроём) тут как-то раз пытались поправить кривой план, опыт с постресом на больших объёмах у всех ближе к 10 годам.... ммм... так вот неасилили.
пришлось дополнительно рихтовать сервер-сайд чтобы зафиксировать логику запроса, разница по времени: или 1.3 мс или 1 мин.15 сек. -- ну т.е. крайне чувствительная.
> Если у вас возникает такая надобность, то надо внимательно посмотреть на свою
> базу данных.Скорее на оптимизатор, так как хинтинг даёт огромную разницу (минуты -> секунды). Суть в том, что это оптимизатор для помощи приложению, а не приложение для оптимизатора. Соответственно подстраивать нужно оптимизатор. За исключением случаев, когда приложение действительно косое.
> А не надо так делать и все будет хорошо.
Угу, и аналитика будет ворочаться по 5+ минут вместо 1-2 секунд. Очень хорошо. Я считаю себя несколько умнее оптимизатора в данном вопросе, поскольку мой результат лучше.
> И? Ну не будет в выборке у меня этих данных и все.
Да нет - не в выборке не будет, а запись встанет колом до завершения блокирующей транзакции.
> И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :)И не только MySQL.
> Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД
> работать.Еще раз: как именно ускорит? За счет какой магии? Хотелось бы обоснования, потому что неочевидно.
> Скорее на оптимизатор, так как хинтинг даёт огромную разницу (минуты -> секунды).
> Суть в том, что это оптимизатор для помощи приложению, а не
> приложение для оптимизатора. Соответственно подстраивать нужно оптимизатор. За исключением
> случаев, когда приложение действительно косое.Чаще бывает случай все же что приложение косое.
> Угу, и аналитика будет ворочаться по 5+ минут вместо 1-2 секунд. Очень
> хорошо. Я считаю себя несколько умнее оптимизатора в данном вопросе, поскольку
> мой результат лучше.Я не спорю что сильно зависит от данных.
> Да нет - не в выборке не будет, а запись встанет колом
> до завершения блокирующей транзакции.Не встанет если у вас не максимальный уровень изоляции.
> И не только MySQL.
Ему особенно. То что PostgreSQL переживает даже не подавившись, может вызывать снижение производительности у MySQL.
> Еще раз: как именно ускорит? За счет какой магии? Хотелось бы обоснования,
> потому что неочевидно.Ускоряется за счет уменьшения накладных расходов. К примеру загрузить 2 тысячи итемов в одной транзакции и 2 тысячи итемов без указания в одной транзакции это две большие разницы.
> Не встанет если у вас не максимальный уровень изоляции.В том то и фокус. Кроме уровня изоляции - есть еще особенности движка. Блокировка страниц индексов именно страницами наблюдается во многих движках.
это мне напоминает спичи людей, которые утверждают, что лучше компилятора соптимизируют ассемблер. иногда одни даже правы, но почти никогда в этом смысла нет. а если уж сильно хочется, то всегда можно поправить исходник постгреса, добавив себе нужную фичу.но лучше, конечно, чтобы описаной тобой возможности не было. потому что на одного умного DBA, который выиграет свою 0.1 секунду, будет 100500 идиотов, которые своими «оптимизациями» запорют всё и вся.
> это мне напоминает спичи людей, которые утверждают, что лучше компилятора соптимизируют
> ассемблер.Помниться Линукс ругался на gcc по поводу неочевидности оптимизации :))
> но лучше, конечно, чтобы описаной тобой возможности не было. потому что на
> одного умного DBA, который выиграет свою 0.1 секундуТут речь, увы, о минутах...
Лёша, это чушь. Практически невозможно представить себе случая, когда ты сам сможешь спланировать запрос лучше, чем коммерческий планировщик запроса.
> Лёша, это чушь. Практически невозможно представить себе случая, когда ты сам сможешь
> спланировать запрос лучше, чем коммерческий планировщик запроса.Не суди обо всех по себе. Тчк.
Я и не пытаюсь. Не каждый имеет более, чем 10-ти летний опыт разработки и оптимизации производительности различных СУБД, как я.
> Я и не пытаюсь. Не каждый имеет более, чем 10-ти летний опыт
> разработки и оптимизации производительности различных СУБД, как я.Понты. Организации и ФИО в студию - поглядим.
Тут на Оракле, у которого этот оптимизатор уж точно не полное г. на "больших серверах" постоянно приходится использовать хинты т.к. 1 из 100 запросов "напрямую" не отрабатывает за разумное время, и выигрыш бывает не на секунды. Ситуации когда у вас есть набор таблиц и нужна определённая выборка в течении ограниченного времени ( а не пары дней/недель что-бы как тут предлагали исходники поправить ) по нескольку раз в месяц случаются, и очень радует что в Оракле такая возможность есть, хоть по умолчанию использование её и не приветствуется ).
>> Postgres ему точно поможет
> Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не
> считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера -
> половина~ хостов туда, половина сюда.
> Партишионинг я не осилил.
> Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные
> (для меня) основные процессы Z.Заббикс версии 1.8 или 2.+?
Могу порекомендовать:autopartitioning для zabbix 2.x, самый простой и эффективный способ:
https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_au...
После него можно выключать housekeeper.
И в крон прописать удалять партиции history_* старше месяца.autopartitioning помогает решить 2 проблемы:
- база растет в разы медленнее
- удаление старых данных происходит мгновенноЕщё Shmsetup для postgresql:
http://leopard.in.ua/2011/02/05/nastrojka-shared-memory-dlya.../Ну и в заббиксе поиграться с количеством pooler.
А для статистики - не скажете число итемов/триггеров? Просто интересно, насколько наша инсталляция крупная/мелкая.
> А для статистики - не скажете число итемов/триггеров?Свой офтопик про Zabbix + PgSQL я вынес из темы про TokuDB. http://www.opennet.me/openforum/vsluhforumID13/848.html 2All: Присоединяйтесь.
Поможет. Проверено (сейчас 96735 item'ов, 27951 триггер, и это еще только начало).Но в заббиксе полно ногами писанных мест, которые требуют оптимизации специфично под MySQL.
Зы. Заббикс очень хорошо уживается с MariaDB/TokuDB со включенными оптимизациями, кроме index_condition_pushdown.
MySQL-движки всегда были (и остаются) одними из самых высокопроизводительных среди реляционных субд.
Колобки и буратины, с функциональностью не путаете?
Во отличии от других баз данных, в mysql с самого начала были storage engines, т.к. возможность менять алгоритм хранения без написания SQL части каждый раз.Что привело к:
- появился InnoDB
- появился NDB
- появился Spider
- появился PBXT
- изначально разные группы разработчиков работали над storage engines и репликацией/sql параллельно, что дало увеличенную скорость разработки и позволило сконцентрироваться на вопросах производительности. Долгое время mysql был самой быстрой из распространённых баз данных (например для запросов по PK, часто используемых в web) и легко масштабируемым на больше чем 1 процессор, в отличии от Postgresql. PG до сих пор в позиции догоняющего, но так как более 20 ядер нужно не всем, то компромис быстрый, но мало фичастый (mysql) и медленный, но реализующий то же что и коммерческие базы (PG) для многих свежих проектов смещается в сторону PG.
> Postgresql. PG до сих пор в позиции догоняющего, но так как
> более 20 ядер нужно не всем, то компромис быстрый, но мало
> фичастый (mysql) и медленный, но реализующий то же что и коммерческие
> базы (PG) для многих свежих проектов смещается в сторону PG.Про быстрый mysql поржал.
> Про быстрый mysql поржал.Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и с учетом особенностей движка - оно летает на огромных базах.
> Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных
> запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и
> с учетом особенностей движка - оно летает на огромных базах.Увы умею. У него проблема есть, которую частично вот этот движок компенсирует. А именно отвратительная работа при интенсивной записи, которую люди всяко разно Ну а так да конечно если вместо того чтобы взять нормальную СУБД, можно попрыгать вокруг оптимизации того как положить данные в MySQL.
Нормальную - это какую?
Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает пахнуть.
> Нормальную - это какую?
> Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает
> пахнуть.Да тот же PostgreSQL
да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как в память, пока не придумали. Бестолковый холивар.
> да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как
> в память, пока не придумали. Бестолковый холивар.Он начинает захлебываться позже чем MySQL. А так да если надо много и быстро писать, то в память потом пачкой на диск.
> да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как
> в память, пока не придумали. Бестолковый холивар.Школьники, идите читайте про сам принцип работы того же Слона. Почитайте, что такое транзакция, двойная запись, векторы повторного исполнения и отката, когда сервер считает, что запись произошла, и вообще куда и откуда читаются данные.
> Школьники, идите читайте про сам принцип работы того же Слона. Почитайте, что
> такое транзакция, двойная запись, векторы повторного исполнения и отката, когда сервер
> считает, что запись произошла, и вообще куда и откуда читаются данные.... и пишутся.
Нет веры человеку у которого на аватарке аниме-фигня.
лол, молодец, яростно плюсую )))ЗЫ моргухтар превед!! )))
> Нет веры человеку у которого на аватарке аниме-фигня....сказал человек который вообще с ником "хрен с горы" :)
> Да тот же PostgreSQLА TokuDB к нему уже прикрутили?
Есть предположение, что на конкретном железе и конкретной базе ежепятиминутного пополнения в 150+ гиг с аналитическими выборками оно тупо захлебнется.
Во всяком случае, InnoDB захлебнулся еще на 50+ гиг.
Только почему-то самая большая и нагруженная база крутится под постгресом.
> Только почему-то самая большая и нагруженная база крутится под постгресом.У кого?
не знаю как насчет самой большой и нагруженной, но наверно имелось в виду Skype
> не знаю как насчет самой большой и нагруженной, но наверно имелось в
> виду SkypeЕсть подозрение, что у википедии и фейсбука база куда побольше в плане объема полезных данных и понагруженнее...
Ну или тогда давайте сравнивать с гуглом :)
> не знаю как
> в виду SkypeМикросовтофаг попалился. google://самая большая БД и поговорил с хабрафагом.
>> Про быстрый mysql поржал.
> Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных
> запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и
> с учетом особенностей движка - оно летает на огромных базах.Затыки как раз и начинаются на огромных базах. Мы же все помним рекомендацию по тюнингу innodb? Желательно, чтобы все innodb таблицы помещались в innodb_buffer_pool_size.
Т.е., когда все умещается в оперативку, все прекрасно.
> Затыки как раз и начинаются на огромных базах.И именно для этих случаев есть TokuDB и возможность его прикрутить к MySQL.
Я не про такие затыки. Я про написанные ногами запросы, которые заткнут любой движок.
Своими глазами при анализе тормозов одной системы на этой неделе увидел, как ребятам из солидной конторы в их продукте удалось заткнуть в хлам MSSQL на таблице в 70000 строк из 5 числовых полей... Впрочем, тут виноват не MSSQL, и не таблица. А вполне себе очень даже руки того, кто эту алгоритмику писал.
> Я не про такие затыки. Я про написанные ногами запросы, которые заткнут
> любой движок.С этим никто не спорит.
Мы обсуждаем вменяемую среду использования.
> С этим никто не спорит.
> Мы обсуждаем вменяемую среду использования.Проблема в том, что про "тормозной MySQL" истерят как раз в основном пейсатели, прочитавшие книжку "MS(My,нужное вписать)SQL для чайников", и реально пишущие крэп. При этом MySQL какбэ и не виноват :)
>> С этим никто не спорит.
>> Мы обсуждаем вменяемую среду использования.
> Проблема в том, что про "тормозной MySQL" истерят как раз в основном
> пейсатели, прочитавшие книжку "MS(My,нужное вписать)SQL для чайников", и реально пишущие
> крэп. При этом MySQL какбэ и не виноват :)Что же это вы всех сразу в "пейсатели-чайники" записали.
Мне кажется, подход "если ругается на mysql, значит нуб" несколько странен.
Я думаю, люди могут привести вполне конкретные аргументы.P.S.
По своему опыту я заметил, что проблемы начинаются при размерах базы от 500 гб.
> P.S.
> По своему опыту я заметил, что проблемы начинаются при размерах базы от
> 500 гб.С такими базами и подходы уже специфичные. Там де факто не важно - мускул или не мускул - там важно правильное построение доступа к базе.
> построение доступа к базеЧестно говоря, не понял)
А вообще в том и дело, что pgsql показывает лучшие характеристики на таких базах.
А на небольших базах до 10GB, согласен, mysql за счет простоты (и запихивания всей базы в ОЗУ) будет бегать очень резво.
> А на небольших базах до 10GB, согласен, mysql за счет простоты (и
> запихивания всей базы в ОЗУ) будет бегать очень резво.А что я делаю не так с моим сжатым объемом базы в TokuDB в 246 Гб (~800 Гб несжатых)? Аналитика бегает шустро, нареканий нет, на сервере (виртуалка) 8Gb RAM :)
Мне тут на одном форуме вновь "глаза открыли"... может ошиблись, конечно, но надо убедиться.Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический или нет) для отчистки таблиц и индексов?
Если да - для больших онлайновых баз оно неприменимо как факт, потому что: 1) встанет колом/раком по IOPS на первом же выполнении VACUUM (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть масса удаленных записей, сводя на нет оптимальность оных.
> Мне тут на одном форуме вновь "глаза открыли"... может ошиблись, конечно, но
> надо убедиться.
> Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический
> или нет) для отчистки таблиц и индексов?коенчно вакуум никуда не делся, приборкой кто-то заниматься должен. но то что было скажем в 7 ветке сравнивать с 9 .... этож совершенно разные вещи, я работу автовакуума на "больших онлайновых баз"'ах не замечаю по сравнению с основной нагрузкой.
> Если да - для больших онлайновых баз оно неприменимо как факт, потому
> что: 1) встанет колом/раком по IOPS на первом же выполнении VACUUM
> (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть
> масса удаленных записей, сводя на нет оптимальность оных.на самом деле на форумах такого увидеть можно -- жить расхочеться... фактически-же те-же gist индексы занимают не так много кода чтобы зафиксировать всю логику процесса в голове раз и на всегда.
> Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический
> или нет) для отчистки таблиц и индексов?Я понимаю, чо тебе не надо, но коли уж спросил: прочитай по MVCC. Вакуум из него прямо следует. И про "до сих пор": он там _будет _всегда, поскольку это основопологающее архитектурное решение.
Когда уменя была одна таблица из 1.5К пар логин-пароль, одна на весь инстанс Pg, я про вакуум ничего не слышал и мне тоже не надо было. Когда мне понадобилось админить забикс с 1000+ хостов, узнал много, чего, может, и не хотел бы.
> (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть
> масса удаленных записей, сводя на нет оптимальность оных.А вы "там у себя" при вставке записи _раздвигаете таблицу и все её индексы? А при удалении сжимаете? В онлайне?? Про транзакции и множ.доступ не будем -- я таких материй не понимат.
> он там _будет _всегда, поскольку это основопологающее архитектурное решение.Спасибо за информацию. Пусть будет.
> не надо было. Когда мне понадобилось админить забикс с 1000+ хостов,
> узнал много, чего, может, и не хотел бы.Андрей (простите, в исходном сообщении ошибся именем), 1000+ хостов - это не страшно. Я статистику по нашему заббиксу дал в соседней ветке, если хотите сравнить - взгляните.
> А вы "там у себя" при вставке записи _раздвигаете таблицу и все
> её индексы? А при удалении сжимаете? В онлайне??В InnoDB/TokuDB при удалении освобождаются страницы/части хранилища и индексов. Старые версии для MVCC хранятся в rollback-буфере. Если надо сжать - можно сделать ALTER/OPTIMIZE, но реальная необходимость оного при равномерном росте или стагнации объёма базы сводится к 0 - новые данные раскладываются на свободное место. И с MVCC всё в порядке.
> В InnoDB/TokuDB при удалении освобождаются страницы/части хранилища и индексов. Старые
> версии для MVCC хранятся в rollback-буфере. Если надо сжать - можно
> сделать ALTER/OPTIMIZE, но реальная необходимость оного при равномерном росте или стагнации
> объёма базы сводится к 0 - новые данные раскладываются на свободное
> место. И с MVCC всё в порядке.Замечу что точно так же делается в PostgreSQL.
> Замечу что точно так же делается в PostgreSQL.Тогда зачем там VACUUM? Под "равномерный рост/стагнация", например, предполагалось, что может быть удалено процентов 10 базы, но на следующий день это место уже заполнится новыми данными. Вопрос: без постоянного фонового VACUUM в PG база в таких условиях будет расти бесконечно или всё-таки нет?
>> Замечу что точно так же делается в PostgreSQL.
> Тогда зачем там VACUUM? Под "равномерный рост/стагнация", например, предполагалось, что
> может быть удалено процентов 10 базы, но на следующий день это
> место уже заполнится новыми данными. Вопрос: без постоянного фонового VACUUM в
> PG база в таких условиях будет расти бесконечно или всё-таки нет?Смотря какой VACUUM. Если FULL ANALYZE смотреть то он перестраивает таблицу с удалением пустых мест. А тот что работает в фоне автоматический просто оптимизирует то что там наосвобождали.
> Смотря какой VACUUM. Если FULL ANALYZE смотреть то он перестраивает таблицу с
> удалением пустых мест. А тот что работает в фоне автоматический просто
> оптимизирует то что там наосвобождали.Таки новые данные запишутся на освобожденное место без фонового VACUUM? С фоновым VACUUM? Или всегда будет расти? В мануале как-то очень скользко описано.
> Таки новые данные запишутся на освобожденное место без фонового VACUUM?Нет.
> С фоновым VACUUM?
Если не повезёт (=zabbix и ленивый админ, как я, с автовакуумом по умолчанию), то фоновый и не запустится, далее см.п.1.
> Или всегда будет расти? В мануале как-то очень скользко описано.
У моего предшественника Pg регулярно (раз в год?) рос до free space==0, дальнейшено оффлайна сервиса и poor man defrag-а/пылесоса в виде pgdump/pgrestore.
---Почитал, MVCC в MySQL есть. Куда девается бэк-лог, пока не вдавался.
>> Таки новые данные запишутся на освобожденное место без фонового VACUUM?
> Нет.Во, спасибо!
> ---Почитал, MVCC в MySQL есть. Куда девается бэк-лог, пока не вдавался.
У InnoDB - сидит в отдельных файлах. Новые данные сразу пишутся на место, старые вытаскиваются в лог. У TokuDB - более правильно - сначала пишется в лог, потом сливается на место.
Аналог хвоста данных отмены есть во всех СУБД с MVCC. Реализация различна (в Слоне это периодических Вакуум, в Оракле это содержание огромного пространства под сегменты отмены, в Инно тоже что-то вроде сегментов отмены). Вакуум сам по себе не плох и не хорош. Хотя в 9-той версии механизма вакуума очень грамотно завязан на планировщик ресурсов -- в результате нагрузка по содержанию данных отмены очень хорошо размазывается.
> Вакуум сам по себе не плох и не хорош. Хотя в 9-тойНу да, просто неплохой способ загнать таблицу в блокировку, и получить timeout. Всего-то лишь. Для мелких таблиц нормально, там шанс мал. Для громадных, и постоянно меняющихся - финиш.
>> Вакуум сам по себе не плох и не хорош. Хотя в 9-той
> Ну да, просто неплохой способ загнать таблицу в блокировку, и получить timeout.
> Всего-то лишь. Для мелких таблиц нормально, там шанс мал. Для громадных,
> и постоянно меняющихся - финиш.vacuum'ы разные бывают.
Просто vacuum работает без exclusive lock.
exclusive lock на таблицу кидает vacuum full.
Но на то он и full.
> http://www.postgresql.org/docs/9.1/static/sql-vacuum.htmlУже веселее. Но всё равно неприятно следующее:
VACUUM causes a substantial increase in I/O traffic, which might cause poor performance for other active sessions.
>> http://www.postgresql.org/docs/9.1/static/sql-vacuum.html
> Уже веселее. Но всё равно неприятно следующее:
> VACUUM causes a substantial increase in I/O traffic, which might cause poor
> performance for other active sessions.Для вас новость, что дефрагментация вызывает большой I/O? :)
> Для вас новость, что дефрагментация вызывает большой I/O? :)Да нет, неприятно, что данная СУБД не умеет повторно использовать свободное место без принудительного дефрага и просадки по I/O.
Нет. Там нет ни эскалации блокировок, ни эксклюзивного блокирования. Единственно, конечно ресурсы ввода/вывода и процессора отъедает. Хотя такое говорить тоже не слишком корректно. У того же Оракла на обслуживание механизма MVCC тоже уходит не мало ресурсов. Поэтому подобный механизм в Слоне не хуже прочих. Другое дело, что планировщик у него слабее, чем у того же Оракла.
>> Postgresql. PG до сих пор в позиции догоняющего, но так как
>> более 20 ядер нужно не всем, то компромис быстрый, но мало
>> фичастый (mysql) и медленный, но реализующий то же что и коммерческие
>> базы (PG) для многих свежих проектов смещается в сторону PG.
> Про быстрый mysql поржал.Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ?
> Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ?Оракл на раве.
> Про быстрый mysql поржал.Ахтунг, лошади на опеннете.
> Во отличии от других баз данных, в mysql с самого начала были storage enginesВопрос не в этом, совершенно. Вопрос в том, что даёт, и в чём ограничивает привязка к MySQL (и ещё в том, что есть mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры, а здравый смысл - позора?
> Вопрос не в этом, совершенно. Вопрос в том, что даёт, и в
> чём ограничивает привязка к MySQL (и ещё в том, что есть
> mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и
> зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры,
> а здравый смысл - позора?Ну так идите и сделайте свой с нуля. Со всеми шахматами и поэтессами. Или все-таки коза баяна не стоит, и имеет смысл в качестве базиса для нового использовать готовое, и неплохо работающее?
> Ну так идите и сделайте свой с нуля.Фееричный диалог:
- Использование обвязки MySQL для этого движка тормозит его работу?
- Идите и сделайте свой с нуляне уступает лучшему творению жанра "У меня есть дома барабан, пойдёмте поеб...".
"свой движок RDBMS"
так понятнее? или буквы тоже объяснять?
> "свой движок RDBMS"
> так понятнее? или буквы тоже объяснять?Заяц тоже стопсигнал.
> Заяц тоже стопсигнал.только маленький еще.
Вас с какого курса филфака вытурили и как вы при этом попали в сферу ИТ?
> как вы при этом попали в сферу ИТ?Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на то, чтобы что-то уметь, не хватило.
> Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на
> то, чтобы что-то уметь, не хватило.Заметно, между прочим... Только вот да - что вы при этом в сфере IT до сих пор делаете?
> сфере IT до сих пор делаете?По моим наблюдениям он больше всего занимается тем что бредит.
> По моим наблюдениям он больше всего занимается тем что бредит.Вините в этом свой узкий кругозор.
Когда рамки слишком узкие, а вещи, для понимания которых требуется и понимания специфики, и общая эрудиция - непонятны, тогда это просто узкий кругозор и недостаточное развитие. Но без этого было бы слишком скучно, слишком банально и слишком мало путей для качественного роста.
Если в двух словах, вы не понимаете умные вещи потому, что это умные вещи. Потому что моё наблюдение подсказывает, что речь подавляющего большинства персонажей здесь состоит ТОЛЬКО из шаблонов и стереотипов, где думать не надо вообще, а общая эрудиция связана с мааахонькой книжечкой, полной, вот тут уж истинно, бреда.
Работайте над собой. А надо мной не надо, надо мной уже поработали: http://pic.51t.ru/bur.jpg
> По моим наблюдениям он больше всего занимается тем что бредит.Можно, конечно, сказать, что они счастливы в этом узком мирке, но это же неправда.
Они злы, как собаки, на каждого встречного кидаются, весь свой арсенал гадостей демонстрируют при первой же возможности. Такое ощущение, что тут собралось не сообщество, а одни неудачники, которые каждого первого хотят обвинить во всех своих неудачах.
ps. НО ПРИШЁЛ БУРАТИНО... :)
>>> ps. НО ПРИШЁЛ БУРАТИНО... :)И показал на своём сравнительном примере, что сообщество, в общем-то, милые и прекрасные люди...
> Во отличии от других баз данных, в mysql с самого начала были
> storage engines, т.к. возможность менять алгоритм хранения без написания SQL части
> каждый раз.В других СУБД такая возможность тоже зачастую есть, только не преподноситься как нечто особенное. В том же Оракле полно разных типов "таблиц" и разных типов индексов, которые отличаются ни чуть не меньше, чем "движки" в MySQL.
К слову, SQL-часть для InnoDB и близко не будет аналогичной в случае использования того же MyISAM. Если понимаешь, что делаешь.
storage engine это API, много различных индексов есть во всех базах. Опять же это "индексов", а не полностью контроль над всеми данными
> storage engine это API, много различных индексов есть во всех базах. Опять
> же это "индексов", а не полностью контроль над всеми даннымиНе то что контроля, а самого подхода к формированию данных. В общем, доля общего в подходе, который диктует MySQL, ничтожна, чтобы кичиться этим и преподносить, как некую неповторимую особенность.
> - изначально разные группы разработчиков работали над storage engines и репликацией/sql
> параллельно, что дало увеличенную скорость разработки и позволило сконцентрироваться
> на вопросах производительности.Т.е. когда писал свое и в результате они обошли pgsql про очкам? :)
> Т.е. когда писал свое и в результате они обошли pgsql про очкам?
> :)Разработчики PG решили, что надо бы быстрее работать только после 8,
почему все так упорно решили забыть что было с постгре в 5-7 версиях?
MySQL тогда популярность набрал, а не сейчас.
Почему выстрелили web проекты на mysql 3.23 а не на постгресе?
Потому что mysql быстро развивался и был простым в использовании.
А посгрес был идеальной базой данных, которую только некоторые джависты использовали, потому что все фичи энтерпрайза, кроме скорости работы на хорошем железе
Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине: наличие версии под ОС Windows. Всё.
> Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине:
> наличие версии под ОС Windows. Всё.Скорее даже набора "юный сайтостроитель.exe", который было легко развернуть.
MS Visual InterDev был страшен, ужасен, невнятен, а юный сайтостроитель.exe внёс частичку невиданного доселе удобства - юниксвея, плейнтекста и быстрой разработки безо всякой мышиной возни. Да ещё без кряка.exe
> Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине:
> наличие версии под ОС Windows. Всё.И много проектов под Win/MySQL вы знаете?
Почти все пыхеры, с которыми я сталкивался, сидят под виндой, под ней же и разрабатывают, после чего заливают на линуксовый сервер по ftp(самые продвинутые про svn знают). Так что многие проекты работают под линуксом, но пишутся под виндой.
> Почти все пыхеры, с которыми я сталкивался, сидят под виндой, под ней
> же и разрабатывают, после чего заливают на линуксовый сервер по ftp(самые
> продвинутые про svn знают). Так что многие проекты работают под линуксом,
> но пишутся под виндой.Не совсем понимаю - что в целом в этом плохого? Если специфика приложения и языка позволяет вести разработку на одной платформе, а потом легко перенести на другую - это не минус, а огромный плюс. Тем более что "проекты работают под Linux". Т.е. это не Win-ориентированные проекты.
Я например тоже веду почти весь dev на PHP под виндой - ибо PHPEd есть только под винду, а это одна из лучших IDE. Но это не значит, что то, что я разрабатываю, на винду ориентировано, и вообще на винде запустится :)
Все тестирование и вся отладка личного проекта идут по SSH на линуховом сервере. Причем очень-очень специфичном, с модифицированным ядром и самописными модулями.
На работе - суть та же. На десктопе винда, а вся разработка (и не только на PHP) - под Linux. Т.е. кесарю кесарево...
> Я например тоже веду почти весь dev на PHP под виндой - ибо PHPEd есть только под винду, а это одна из лучших IDE.Ваше мнение очень важно для нас.
> Ваше мнение очень важно для нас.Аналогично.
>Не совсем понимаю - что в целом в этом плохого?топ менеджер компании компании БМВ ездит на мерсе, что тут плохого? ну кроме того, что работать он будет там недолго...
> топ менеджер компании компании БМВ ездит на мерсе, что тут плохого? ну
> кроме того, что работать он будет там недолго...Уверены? Это не россия.
Вы уже забыли свой вопрос? Напоминаю:
>И много проектов под Win/MySQL вы знаете?Или увидели слово "пыхер" и, забыв обо всем, бросились на защиту любимого языка? Не стоит утруждаться, мне в общем-то без разницы под какой ОС пишут пыхеры, хватает того, что они умудряются писать код, который работает под apache, но не под php-fpm или fcgi.
> Вы уже забыли свой вопрос? Напоминаю:
>>И много проектов под Win/MySQL вы знаете?Повторяю вопрос еще раз для особо тупых/упертых: много ли проектов __ПОД WIN/MYSQL__ вы знаете?
То, что озвучено выше - никакого отношения к проектам под Win/MySQL не имеет.
Я повторюсь, мне не сложно. Продакшен под Linux/MySQL, но разработка идет под Win/MySQL. Причем выбор между win и linux не связан с мускулом.
> Почему выстрелили web проекты на mysql 3.23 а не на постгресе?
> Потому что mysql быстро развивался и был простым в использовании.основная причина - потому что постгрес практически невозможно использовать на sharing hosting.
"Быстрый" MySQL быстрый только пока вообще не СУБД, а просто хрень для последовательной записи в файл. Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID.
>Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID.Новость не читай, быстро отвечай.
> PG до сих пор в позиции догоняющего, но так как
> более 20 ядер нужно не всем, то компромис быстрый, но мало
> фичастый (mysql) и медленный, но реализующий то же что и коммерческие
> базы (PG) для многих свежих проектов смещается в сторону PG.Водораздел не там проводите: MySQL -- если ценность данных мусорная (в куда меньшей степени касается InnoDB, но InnoDB не блещет скоростью на фоне сходных решений); PG -- если данные всё же имеют какую-то ценность.
Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?
и то и то может crash recovery.
И то и то будет падать по assertion, в случае, если данные повреждены:
- нарушение порядка записи/игнорирование fsync
- нули вместо данных после востановления сбойного дискаРазница только в том что для TokuDB пока ещё нет парсера сырых файлов, как для InnoDB и последней надежды получить данные в виде csv нет.
> И то и то будет падать по assertion, в случае, если данные
> повреждены:
> - нарушение порядка записи/игнорирование fsync
> - нули вместо данных после востановления сбойного диска+1
> Разница только в том что для TokuDB пока ещё нет парсера сырых
> файлов, как для InnoDB и последней надежды получить данные в виде
> csv нет.Backup rulez.
> Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?А что у InnoDB не так? Ни по тому, ни по тому ничего фатального на нормальном железе не видел. Да и бэкапов никто не отменял.
> Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет.
> Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет.Да что Вы говорите?! Неуж-то и в самом деле нету? Вобще?
Или Вы хотите сказать, что все таблицы всех баз по умолчанию хранятся в одном файле (ибо shared tablespace)?
А если в конфиге написать innodb_file_per_table ?
Это по принципу написал на заборе *** и вот он.
Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним файлом, хоть сотней. К тому же иннодб поддерживает принципы acid.
> Это по принципу написал на заборе *** и вот он.
> Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним
> файлом, хоть сотней. К тому же иннодб поддерживает принципы acid.Чушь собачья. При innodb_file_per_table данные таблиц хранятся в отдельных неймспейсах.
Лёша, ты слышал звон, да не въехал откуда он. А этот звон из твоих штанов.
Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств сегментов, которые к нему приписаны). А не физическое представление.
> Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств
> сегментов, которые к нему приписаны). А не физическое представление.Я просто оставлю это здесь, дабы спугнуть любителей обсуждать сферических коней в вакууме:
http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-table...
Э, суть в том, что таблица это такая штука, где есть первая строка, за первой строкой идёт вторая, и так далее (я думаю ты меня понял). Так вот, такого в ИнноДБ нет (как и большинстве взрослых РСУБД). Данные не хранятся последовательно, а хранятся в виде кучи. Чем иннодб радикально и отличается от ISAM-ов разных мастей.
> Э, суть в том, что таблица это такая штука, где есть первая
> строка, за первой строкой идёт вторая, и так далее (я думаю
> ты меня понял). Так вот, такого в ИнноДБ нет (как и
> большинстве взрослых РСУБД). Данные не хранятся последовательно, а хранятся в виде
> кучи. Чем иннодб радикально и отличается от ISAM-ов разных мастей.Суть в том, что таблица СУБД - это не такая штука, как таблица на бумаге ("первая, вторая, ..."). Такая штука годится только для диссертаций. В принципе, раздельное хранение как раз есть в TokuDB, но с большими оговорками. Таблица отдельно, индексы отдельно. Но не линейно, далеко не.
В современных СУБД "таблица" - это, как правило, таблица вместе с индексами, поскольку де факто они взаимозависимы. В одном файле хранится этот набор для таблицы или в разных - фактически без разницы. Главное, что не все таблицы в одном файле.
Почему, и "почему бы не"? Да потому, что вставка в середину того, что вы выше описали - это операция весьма себе ресурсоемкая. Или изменение длины строки в случае полей переменной длины. Плюс блобешники хранить накладно.
Лёша, в жизни крутиться вокруг названий. И называть таблицей нужно именно таблицу. Т.е. нечто вертикально упорядоченное. Вот в ISAM, в том числе и в MyISAM, именно такой подход и используется (именно из-за этого в ISAM данные легко добавлять в конец таблицы, но крайне сложно изменять или удалять откуда-то из середины). Поэтому там есть равенство между файлом и таблицей. В иннодб такого равенства нет и быть не может. Там просто есть ТП, в котором есть один файл и размер этого файла увеличивается по мере роста сегмента, который в нём хранится. Причём для простоты (которая хуже воровства) в ТП пихается один файл, а в одном файле размещается один сегмент ("таблица"-отношение или индекс). Причём нарастает этот файл "не построчно", а некими крупными кусками -- назовём их экстентами, которые могут и вообще данных не содержать. До поры до времени. Но равенство один кортеж = один файл надуманное. В том же инно в ТП может входить множество файлов, причём один сегмент (т.е. таблица-отношение) может быть размазан по множеству файлов.
> Лёша, в жизни крутиться вокруг названий.Всё крутится вокруг сути, а не вокруг названий. Предположим дерьмо вдруг назвали конфеткой. Вне зависимости от названия, я его есть не буду. За тех, у кого "всё вокруг названий" - не ручаюсь.
Еще раз повторюсь: "таблица" СУБД и "таблица" на бумаге - не одно и то же. Название одно, суть - разная.
> Т.е. нечто вертикально упорядоченное.
Ну так зачем ты в БД-то тогда лезешь вообще? Работай в Excel. И то структура файла у него не "вертикально упорядоченная". СУБД и придумали как раз для того, чтобы обойти ограничения "вертикальной упорядоченности" таблиц, дав возможность управлять данными линейной "вертикальной" структуры в нелинейном порядке, удобном для раскладывания и обработки.
> один сегмент (т.е. таблица-отношение) может быть размазан по множеству файлов.
Если "отношение" - это внутритабличная сущность - нет, не может.
> Еще раз повторюсь: "таблица" СУБД и "таблица" на бумаге - не одно
> и то же. Название одно, суть - разная.Суть разная -- и название разное.
Читай Кодда, лучше Дэйта, до просветления.
> Если "отношение" - это внутритабличная сущность - нет, не может.
Лёха, отношение это то, что ты упорно пытаешься называть таблицей (что таблицей не является, а является множеством кортежей). Сиречь: relation -- отношение. Отсюда и Реляционные СУБД. Так вот это отношение может занимать сколько угодно файлов в иннодб. Единственно -- отношение (или сегмент) не может разделяться между несколькими ТП. Тут в инно всё почти как у взрослых.
Печалька печальная. Еще раз подтверждаешь, что от теоретика до практика - пропасть немеряная. А потом смотришь на поделки таких теоретиков, и диву даешься.
Леха, увы, подобные сентенции -- про бесполезность теории -- обычно выдают в собеседнике неосилянта пэтэушника.
а тут не бесполезность, тут «страшно далеки они от народа». потому что ехать надо вчера, а высокотехнологичная суперэкономичная машина — только завтра, и то лишь в чертежах.
> а тут не бесполезность, тут «страшно далеки они от народа». потому что
> ехать надо вчера, а высокотехнологичная суперэкономичная машина — только завтра,
> и то лишь в чертежах.Это вы про автомобильТеслы на трех радиолампах ? За который его заперли под домашний арест до конца жизни ?
а ещё он марсиан видел!
> Это вы про автомобиль Теслы на трех радиолампах ? За который его заперли
> под домашний арест до конца жизни ?Да Тесла вообще-то практик был, 100%-й - он сначала внедрял идеи на основе существующей теории, потом исследовал результаты и улучшал. И не запирал его никто.
А вот галимые теоретики от его идей с переменным током тоже вначале отказывались, ибо "не по канонам". Правда, потом деваться стало некуда - мир шагнул без них :)
p.s. это не значит, что машина не нужна.
> Леха, увы, подобные сентенции -- про бесполезность теории -- обычно выдают в
> собеседнике неосилянта пэтэушника.Теория не бесполезна, но вот слепое поклонение теории - удел недалеких, Кира. Кроме того - любые теории являются сферическим конем, предметом рассмотрения и корректировки, а вот практика - она живая, ее потрогать можно.
Это не говорит о том, что практика без теории возможна. Это говорит о том, что если человек замкнулся на теорию в отрыве от практики - грош ему цена.
Помимо открытия кода под GPLv2, они дали какие-нибудь обещания насчет своих патентов на этот движок? Или новая бизнес-модель заключается в патентном троллинге всех, кто по наивности начнет эту штуку использовать?
форкать не выйдет :)
> форкать не выйдет :)fractal library
>> форкать не выйдет :)
> fractal libraryAre Fractal Tree indexes covered by patents?
Yes. MIT, Stony Brook University, and Rutgers have a patent that covers Fractal Tree indexes. We’ve obtained a license from them to use the patent in the GPL’d version of our software (see the product documentation for the details of the license).
А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при этом очень редки)? Полезная штука?
Нет используй в таком случае InnoDB.TokuDB это типа хранилища для архивов или аналитики, где преобладает запись.
TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую то аналитическую систему сбора
> TokuDB это типа хранилища для архивов или аналитики, где преобладает запись.
> TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую
> то аналитическую систему сбораНеправда. Она в целом хорошо справляется не только с записью, но и увеличивает параллелизм + несколько оптимизирует тяжелые выборки за счет структур на диске. Плюс сильная компрессия, которая позволяет балансировать между disk-bound и CPU-bound.
А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column add/delete без остановки операций и блокировки таблицы. Впервые начали использовать TokuDB только из-за этого - потому, что новая аналитика постоянно требовала новых индексов.
> А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column
> add/delete без остановки операций и блокировки таблицы.Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут же непредсказуемые фантомы.
> Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут
> же непредсказуемые фантомы.См. сайт разработчика - там в презентациях все разжевано. Данные перемещаются большими блоками, все изменения добавляются к корню, и протаскиваются по нодам в фоновом режиме. Да, снизит скорость последующих выборок по нодам, но только однократно. Зато на таблицах в xxx Гб-Тб не имеем простоя при смене структуры.
Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API _моментально_, старые транзакции завершаются со старой структурой, новые - идут с новой. Реальное изменение структуры идёт в фоне.
Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри файла, структура самодефрагментирующаяся.
> Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API
> _моментально_, старые транзакции завершаются со старой структурой, новые - идут с
> новой. Реальное изменение структуры идёт в фоне.Моментально? Ну вот начал ты длинную транзакцию, в её процессе структура, ладно, "таблиц" изменилась -- как транзакция вытащит согласованные по времени данные? Т.е. прежняя структура где-то и как-то сохраняется? Т. е. как я понял словарь данных имеет какой-то механизм, сохраняющий данные отмены подобных изменений структуры. Но этот механизм не ясен.
> Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри
> файла, структура самодефрагментирующаяся.Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть, либо редко -- но долго и всё разом. Можно и вообще дефрагментации не допускать, к примеру, за счёт избыточности пустого места в блоках.
> Моментально? Ну вот начал ты длинную транзакцию, в её процессе структура, ладно,
> "таблиц" измениласьТы почитай механизмы работы TokuDB, на практике посмотри. Там фокус как раз в том, что все изменения применяются по мере завершения транзакций, а новые транзакции изменения видят сразу.
> прежняя структура где-то и как-то сохраняется?
> Но этот механизм не ясен.Сам механизм ясен и прозрачен. Представь себе, что вся база - один большой сплошной лог (!!!). Который тихонько самодефрагментируется, вычищая ненужное, и реорганизуя записи в линейные структуры. Немножко упростил, но вот это и есть TokuDB.
> Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть
Там хитро - структура сама дефрагментируется в процессе штатного функционирования. Она устроена так, что не фрагментируется.
> Сам механизм ясен и прозрачен. Представь себе, что вся база - один
> большой сплошной лог (!!!). Который тихонько самодефрагментируется, вычищая ненужное,
> и реорганизуя записи в линейные структуры. Немножко упростил, но вот это
> и есть TokuDB.Не очень-то тихонько, на самом деле. В последних бенчах на mysqlperformanceblog хорооошая такая пила на графике insert'ов видна, с красиивыми такими провалами. Не так, конечно, ужасно как у LevelDB, где с какого-то момента compacting начинает съедать вообще всё и rps доходит до нуля, но таки.
> Не очень-то тихонько, на самом деле. В последних бенчах на mysqlperformanceblog хорооошая
> такая пила на графике insert'ов видна, с красиивыми такими провалами. Не
> так, конечно, ужасно как у LevelDB, где с какого-то момента compacting
> начинает съедать вообще всё и rps доходит до нуля, но таки.Вы вот об этом бенче - http://www.mysqlperformanceblog.com/2013/05/07/benchmarking-.../ ?
Таки да, чекпоинтинг бесплатным не бывает. У InnoDB в таких условиях всё вообще плохо - на первые 5 минут теста можно внимания не обращать - там таблица умещалась в память целиком. TokuDB оптимизирует именно работу с дисковой подсистемой и индексами, в случае CPU-bound/RBW-bound workloads лучше смотреть в сторону иных решений.
Вообще к указанному бенчу есть ряд серьезных нареканий - автор пытается по сути забить гвоздь микроскопом. Под такую задачу надо in-memory database, +, возможно, NoSQL, и TPS будут куда мягче и шелковистее.
По сути бенч - одна из стадий OLTP в чистом виде (ну и выбор железа и структуры таблиц намекают именно на OLTP), только вот слегка непонятен выбор последовательности процесса - гибрид высоких TPS на входе + rollup'а также на входе смотрится как-то неправильно.
Это не говорит о том, хорош или плох бенч - это просто замечания к тому, что в данном случае он не раскрывает всех сторон медали.
> Вообще к указанному бенчу есть ряд серьезных нареканий - автор пытается по
> сути забить гвоздь микроскопом. Под такую задачу надо in-memory database, +,
> возможно, NoSQL, и TPS будут куда мягче и шелковистее.Конкретный бенч раскрывает конкретную сторону конкретной медали, что от него и требуется. В данном случае - как оно ведет себя под жестким write load. Ответ - так себе.
На распространенных in-memory DB оно конечно график будет поровней и форма пилы другая (ибо иерархичность памяти никто не отменял, но ваятелям модным in-memory db про неё забыли рассказать), только вот персистенс будет уже сбоку и сколько улетит незаписанных данных при сбое -- ... А это типа бывает важно, не все же веб-апп "to-do list" на рельсах с редисом рисуют.
Что касается NoSQL - если не брать те где всё будет просто тупо медленней (Riak & Co.), то опять же, пила будет несколько иной формы ибо в том или ином виде они в большинстве своем SSTable-based - Cassandra etc. Ну а про LevelDB я выше написал.
> В данном случае - как оно ведет себя под жестким write load. Ответ - так себе.Неправильный ответ :) Ведет себя оно в разы лучше InnoDB.
Так я же не сказал "отвратительно", а всего лишь "так себе".
>> TokuDB это типа хранилища для архивов или аналитики, где преобладает запись.
>> TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую
>> то аналитическую систему сбора
> Неправда. Она в целом хорошо справляется не только с записью,Практически -- только. Уже на UPDATE она медленней, а на INSERT ON DUPLICATE - совсем всё плохо. Есть, правда, специальный случай апдейта "x = x + c" где с - константа, специально оптимизированный в Toku, остальное - в пролете.
> увеличивает параллелизм
Раньше всё плохо с этим было в Toku, хорошо если поправили.
> А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column
> add/delete без остановки операций и блокировки таблицы. Впервые начали использовать TokuDB
> только из-за этого - потому, что новая аналитика постоянно требовала новых
> индексов.Именно. Поэтому, как и сказано выше - идеально как логгер больших объемов + гибкая аналитика в одном флаконе. То есть ниша на самом деле рыночная - очень большая, огромная даже. В идеале -- это лавка, которая сидела на MySQL, объемы выросли (и вырастут еще больше, руководство прочитало статью про Big Data, да и вообще неплохо бы), и требования по аналитике тоже всё развесистей, и надо бы, с одной стороны, как-то с этим справляться, а с другой - строить вот прямо сразу кластеры с кассандрами и некому, и не на что, и некогда. Вывод - в краткосрочной перспективе прыгаем на TokuDB (тем более что можно постепенно это делать), в среднесрочной - присматриваемся к Vertica, в долгосрочной - ищем спецов по Big Data и дата сайентистов.
> Практически -- только. Уже на UPDATE она медленней, а на INSERT ON
> DUPLICATE - совсем всё плохо. Есть, правда, специальный случай апдейта "x
> = x + c" где с - константа, специально оптимизированный в
> Toku, остальное - в пролете.Да, очень сильно зависит от структуры таблицы. Я бы не сказал, что на UPDATE сложных таблиц с кучей индексов оно медленнее. Насчет оптимизации - сильно не хватает X = X + VALUE(X).
обещали добавить
> А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при
> этом очень редки)? Полезная штука?Если у вас disk-bound workload - да. Структура индексов у TokuDB очень хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие, не привносящее диких тормозов, как у InnoDB.
Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.
>>> Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.в badoo СУБД на одних php скриптах :D
>> А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при
>> этом очень редки)? Полезная штука?
> Если у вас disk-bound workload - да. Структура индексов у TokuDB очень
> хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие,
> не привносящее диких тормозов, как у InnoDB.
> Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.Один из очевидных плюсов очень мало настроек, в отличии от пары сотен тонких настроек innodb
> Один из очевидных плюсов очень мало настроек, в отличии от пары сотен
> тонких настроек innodbДа, кстати. Очень универсальный двиг, работающий практически "из коробки".
> Один из очевидных плюсов очень мало настроек, в отличии от пары сотен
> тонких настроек innodbКакой ещё "пары сотен"? )))) Всё настраивается не более чем десятком очевидных параметров.
Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom
> Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStromЭто если CPU-bound из-за сложных выражений. А если он возник из-за объема данных / сортировки, то таким образом только шина в полку уложится, и результат будет отрицательный.
Но вот для массивного REGEXP / LIKE по базе вполне себе интересно, если конечно умеет.
>> Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom
> Это если CPU-bound из-за сложных выражений. А если он возник из-за объема
> данных / сортировки, то таким образом только шина в полку уложится,
> и результат будет отрицательный.Ну это и не CPU-bound а bus bound таки.
> Но вот для массивного REGEXP / LIKE по базе вполне себе интересно,
> если конечно умеет.Не надо бы базе LIKE поручать, нехорошо это, есть же более другие средства, хотя бы и встроенные типа FTS.
> Ну это и не CPU-bound а bus bound таки.Будет. Что еще хуже, чем CPU bound.
> Не надо бы базе LIKE поручать, нехорошо это, есть же более другие
> средства, хотя бы и встроенные типа FTS.Именно так. Просто помимо сложных выражений я не могу представить себе задачу БД, которую можно поручить GPU. Упрётся в шину.
>> я не могу представить себе задачу БД, которую можно поручить GPU. Упрётся в шину.Расчет шейдеров на карте онлайн игры
> Именно так. Просто помимо сложных выражений я не могу представить себе задачу
> БД, которую можно поручить GPU. Упрётся в шину.Так дело в том что "сложных выражений" становится всё больше, дальше если с виду они и не особо сложные. Тот же JSON в Pg 9.3 - распарсить, что-то из него добыть и добытое опять в JSON чтоб отдать - очень даже CPU-bound будет.
> Тот же JSON в Pg 9.3Не нужен. Адовое нарушение собственно принципа структурирования РСУБД. Чего-то парсить и добывать оттуда - в общем, задача приложения.
Не против, если это делается в движке - но производительность этого логично будет ниже плинтуса. Так можно и XML в движок РСУБД притащить, и обработку изображений, звука, видео, и дифференциальные уравнения до кучи - чего уж там. Правда, нафига козе баян - ясно плоховато.
Для перконы собрали двоичные и бинарныеhttp://www.mysqlperformanceblog.com/2013/04/24/percona-serve.../
> собрали двоичные и бинарныеДля тупых поясните... это уже не одно и тоже?
Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы всё равно упираются в 99% случаев в разбор SQL и составление планов выполнения запросов? Эти все улучшения будут иметь смысл только при очень простых запросах на больших объёмах данных, что в майсиквеле не так уж часто встречается.P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет вогнать в ступор любую базу с любым двиглом.
Квантовый двигатель ?
> Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы
> всё равно упираются в 99% случаев в разбор SQL и составление
> планов выполнения запросов? Эти все улучшения будут иметь смысл только при
> очень простых запросах на больших объёмах данных, что в майсиквеле не
> так уж часто встречается.ЧЕГО? На огромных базах ворклоуд либо cpu-bound, либо disk-bound. TokuDB сильно упрощает жизнь для disk-bound. "Разбор SQL и составление планов" на таких базах - 0.000001% времени, а то и меньше.
> P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет
> вогнать в ступор любую базу с любым двиглом.А вот это верно.
> запросы всё равно упираются в 99% случаев в разбор SQLОткройте для себя prepared statement уже наконец.
> при очень простых запросах на больших объёмах данных, что в майсиквеле не
> так уж часто встречается.Как раз в MySQL оно только и встречается. Для сложных запросов там планировщика можно считать что просто нет, по сравнению с PostgreSQL.
Я так понимаю, человек из веба, а особенно если где фреймворки с ORM - там оно именно так и выглядит - данных тянем мало, но в отдельных сущностях (которые каждый раз создаются заново) и много раз, причем 70% выборок - по первичному ключу.
> Я так понимаю, человек из веба, а особенно если где фреймворки с
> ORM - там оно именно так и выглядит - данных тянем
> мало, но в отдельных сущностях (которые каждый раз создаются заново) и
> много раз, причем 70% выборок - по первичному ключу.Да даже там разбор запроса - это ни о чём. В него упереться можно только на базах < pool size или на совсем хилых VPS/VDS.
> Да даже там разбор запроса - это ни о чём. В него
> упереться можно только на базах < pool size или на совсем
> хилых VPS/VDS."..>95% of the CPU time in reads is spent in the SQL parser"
http://www.openldap.org/lists/openldap-devel/201203/msg00017...
> "..>95% of the CPU time in reads is spent in the SQL
> parser"
> http://www.openldap.org/lists/openldap-devel/201203/msg00017...а) это SQLite
б) это < pool size
а) это SQLite
б) это OpenLDAPМеханика запросов к БД в голове у тех, кто писал модули хранения данных к OpenLDAP (включая встроенные БД), как бы это помягче-то сказать, специфическая... Взгляните на код сами, ужаснитесь.
>> запросы всё равно упираются в 99% случаев в разбор SQL
> Откройте для себя prepared statement уже наконец.Какой нафиг prepared statement в web ? На каждую страницу, на каждый коннект они убиваются.
14.04.15
В своём блоге команда Percona заявила о приобретении компании Tokutek, разработчика движка TokuDB для СУБД MySQL/MariaDB/Percona.Теперь даже ссылка из шапки ведёт на сайт Перконы :)
