The OpenNET Project / Index page

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

Высокопроизводительный MySQL-движок TokuDB переведён в разряд открытых проектов

26.04.2013 10:48

Компания Tokutek открыла исходные тексты проекта TokuDB (Tokutek storage engine), в рамках которого развивается высокопроизводительный транзакционный движок хранения для MySQL и MariaDB. Вместо классических B-tree деревьев в TokuDB применяются рекурсивные индексы (Fractal Tree indexes), что в сочетании с хранением данных в сжатом виде, позволяет значительно оптимизировать операции ввода/вывода.

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

При проведении тестов, TokuDB опережает InnoDB при добавлении больших объемов данных более чем в 10 раз (InnoDB 1,555 записей в сек, TokuDB 16,437 записей в сек), но проигрывает по степени нагрузки на CPU при выборке данных. Недостаточная эффективность выборки данных компенсируется ситуациями когда требуется произвести выборку большого числа последовательно сохранённых записей. В некоторых тестах выигрыш в скорости добавления данных достигает 80 раз. Применяемые методы сжатия данных позволяют в разы уменьшить размер базы и индексов (в 6.2 раза по сравнению с InnoDB и в 5.5 раз по сравнению с MyISAM), в некоторых ситуациях степень сжатия данных может достигать 25 раз.

Из особенностей движка TokuDB также можно отметить:

  • Обеспечение требований ACID к выполнению транзакций (атомарность, согласованность, изолированность, долговечность);
  • Возможность изменения хранения схемы данных на лету, без перестроения хранилища;
  • Отсутствие эффекта фрагментации индексов после длительного времени работы базы (нет необходимости пересоздавать индексы для устранения фрагментации);
  • Гибкие средства ускорения выполнения запросов через использование индексов. Поддержка "горячего" добавления и изменения индексов;
  • Поддержка создания хранилищ для терабайт данных;
  • Поддержка создания горячих бэкапов без остановки работы;
  • Поддержка репликации интенсивно поступающих потоков данных на несколько slave-серверов без отставания появления данных на slave-системах;
  • Соответствие требованиям MVCC (Multi-Version Concurrency Control) по работе в многопользовательских системах с большим числом одновременных запросов;
  • Режим быстрого восстановления после сбоя;
  • Высокая эффективность поддержания хранилищ с десятками и сотнями миллионов записей. Отсутствуют проблемы при активном удалении записей в таких хранилищах;
  • Поддержка кластерных индексов, в которых непосредственно могут сохраняться любые данные из записей;
  • По выполняемым операциям индексы Fractal Tree indexes схожи в B-Tree и отличаются главным образом более оптимальным использованием кэшей и доступа к данным на накопителях на жестких магнитных дисках, за счёт преобразования операций случайного доступа в наборы последовательных запросов. Для SSD-накопителей использование TokuDB оправдано сокращением числа операций записи.

В настоящее время движок TokuDB уже используется проектом Mozilla для организации работы сервиса Datazilla, занимающегося сбором информации о производительности, автоматически отправляемой браузером Firefox, при включении соответствующих настроек. Разработчики MySQL и MariaDB приветствовали решение по открытию кода TokuDB, заявив, что такой шаг будет способствовать широкому внедрению TokuDB. Более того, разработчики MariaDB уже рассматривают возможность включения TokuDB в состав MariaDB и поставки данного движка в качестве штатного компонента.

Код открыт под лицензией GPLv2. Изначально движок TokuDB развивался как проприетарный продукт, но компания Tokutek решилась на изменение бизнес-модели, которая теперь подразумевает разработку TokuDB как свободного проекта с предоставлением корпоративным заказчикам коммерческой версии TokuDB Enterprise Edition, которая отличается наличием сервиса технической поддержки, расширенными инструментами для резервного копирования и возможностью адаптации продукта под нужды заказчика.

  1. Главная ссылка к новости (http://www.tokutek.com/2013/04...)
  2. OpenNews: Стабильный релиз MySQL хранилища InfiniDB 1.0
  3. OpenNews: Для MySQL представлено распределённое хранилище Spider
  4. OpenNews: Для MySQL представлено новое хранилище XtraDB, основанное на InnoDB
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/36779-tokudb
Ключевые слова: tokudb, mysql
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (199) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:59, 26/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Интересно, если Заббикс на этот движок перенести - ему поможет?
     
     
  • 2.4, alp (?), 12:22, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Postgres ему точно поможет
     
     
  • 3.7, Andrey Mitrofanov (?), 13:00, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Postgres ему точно поможет

    Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера - половина~ хостов туда, половина сюда.

    Партишионинг я не осилил.

    Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные (для меня) основные процессы Z.

     
     
  • 4.9, sauron (??), 13:57, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    PostgeSQL хоть потюненый был? Или стоковый воткнули?
     
     
  • 5.10, Anonimous (?), 14:01, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Где описано как его "тюнить" для Zabbix?
     
     
  • 6.11, sauron (??), 14:07, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Где описано как его "тюнить" для Zabbix?

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

     
     
  • 7.35, anonymous (??), 16:07, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Где описано как его "тюнить" для Zabbix?
    > Вообще надо банальный тюнинг под сервер произвести. Если же тюнинг не осуществлялся,
    > то не удивительно что не помогло.

    Zabbix написан и заточен под mysql. Если вы не эксперт постгре, я бы не рекомендовал в принципе экспериментировать. Попытки завести заббикс на других базах вынудили меня в конечном итоге вернуться к mysql для заббикса.

     
     
  • 8.81, sauron (??), 06:28, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ЛОЛ ШТО Это как же он так внезапно стал заточен под MySQL Я вот там никаких оп... текст свёрнут, показать
     
     
  • 9.84, anonymous (??), 08:57, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А это не в контексте оптимизаций под mysql, а того, насколько криво написано под... текст свёрнут, показать
     
     
  • 10.102, sauron (??), 16:58, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы там выдыхайте иногда Я вообще в код ходил и смотрел Там разницы особой нет ... текст свёрнут, показать
     
     
  • 11.106, Аноним (-), 17:13, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    просто вы не видите этой разницы потому что например не знаете как зависят нагру... текст свёрнут, показать
     
     
  • 12.108, sauron (??), 18:20, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Конечно конечно Товарищ если вы начали оптимизировать свой софт под поведение Р... текст свёрнут, показать
     
     
  • 13.109, AlexAT (ok), 18:50, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А если не начали - то это очень плохой звоночек ... текст свёрнут, показать
     
     
  • 14.120, sauron (??), 06:17, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Оптимизировать под конкретную реализацию РСУБД на начальной стадии проектировани... текст свёрнут, показать
     
     
  • 15.122, AlexAT (ok), 07:29, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Имеет Потому что переоптимизировать всё на конечной стадии может уже и не получ... текст свёрнут, показать
     
     
  • 16.123, sauron (??), 07:39, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не имеет Стандарт SQL-92 и общие концепции не зря придумывали Он одинаково хре... большой текст свёрнут, показать
     
     
  • 17.124, AlexAT (ok), 08:16, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Угу Вот только есть особенности, которых этот стандарт совершенно не учитывает ... большой текст свёрнут, показать
     
     
  • 18.125, sauron (??), 08:22, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И какие такие критические особенности движка MySQL надо учитывать при разработке... большой текст свёрнут, показать
     
     
  • 19.126, AlexAT (ok), 11:20, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Несколько примеров - Использование LIMIT x,y нет в MSSQL, к примеру - Замена ... большой текст свёрнут, показать
     
     
  • 20.127, sauron (??), 11:53, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    вообще limit offset поддерживается в том числе и в MySQL и в PostgreSQL и Oracle... большой текст свёрнут, показать
     
  • 21.130, AlexAT (ok), 20:38, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В MSSQL - нет Всё, универсальности уже нет Специфика И в MySQL, и в PGSQL, и ... большой текст свёрнут, показать
     
  • 22.132, sauron (??), 21:13, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    MSSQL - это своя атмосфера В остальных есть Хорошо в большинстве случаев Все ... большой текст свёрнут, показать
     
  • 23.133, AlexAT (ok), 21:48, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А зря Иногда единственный способ обойти оптимизатор, не лезя в код собственно д... текст свёрнут, показать
     
  • 24.134, sauron (??), 06:18, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Чуваки из PostgreSQL против хинтов Они говорят что если у вас оптимизатор плохо... большой текст свёрнут, показать
     
  • 25.135, pavel_simple (ok), 07:33, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален подобие хинтов таки появилось http habrahabr ru post 1... текст свёрнут, показать
     
  • 26.137, AlexAT (ok), 08:11, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    О как Видать кого-то здорово припёрло как раз тем, о чём я ниже в 136 написал ... текст свёрнут, показать
     
  • 25.136, AlexAT (ok), 08:06, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот за что и не люблю академические поделки - так это за это самое а баба яга п... большой текст свёрнут, показать
     
  • 26.138, sauron (??), 08:16, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А специфика конкретных приложений затачивается уже указанием индексов Если вот ... большой текст свёрнут, показать
     
  • 27.139, AlexAT (ok), 08:21, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Именно И если надо обойти оптимизатор и сказать - вот этот, ь, индекс, и н... большой текст свёрнут, показать
     
  • 28.140, sauron (??), 08:34, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если у вас возникает такая надобность, то надо внимательно посмотреть на свою ба... большой текст свёрнут, показать
     
  • 29.141, pavel_simple (ok), 09:08, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    дело не в базе данyых, дело в том что постгрес использует оптимизатор который ра... текст свёрнут, показать
     
  • 30.142, pavel_simple (ok), 09:10, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    P S http www postgresql org docs 8 2 static geqo-pg-intro html 48 3 1 Futu... большой текст свёрнут, показать
     
  • 30.143, sauron (??), 09:10, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это на сильно не тривиальных выборках бывает и там покрутить можно для изменения... текст свёрнут, показать
     
  • 31.144, pavel_simple (ok), 09:18, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    говорю как есть, может у меня конечно чего с руками, НО мы втроём тут как-т... текст свёрнут, показать
     
  • 29.145, AlexAT (ok), 09:29, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее на оптимизатор, так как хинтинг даёт огромную разницу минуты - секунды ... большой текст свёрнут, показать
     
  • 30.146, sauron (??), 09:43, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Чаще бывает случай все же что приложение косое Я не спорю что сильно зависит от... большой текст свёрнут, показать
     
  • 31.153, AlexAT (ok), 18:03, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В том то и фокус Кроме уровня изоляции - есть еще особенности движка Блокировк... текст свёрнут, показать
     
  • 26.147, arisu (ok), 11:48, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    это мне напоминает спичи людей, которые утверждают, что лучше компилятора соптим... текст свёрнут, показать
     
  • 27.152, nagual (ok), 16:33, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Помниться Линукс ругался на gcc по поводу неочевидности оптимизации ... текст свёрнут, показать
     
  • 27.154, AlexAT (ok), 18:03, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Тут речь, увы, о минутах ... текст свёрнут, показать
     
  • 26.173, Кирилл (??), 15:56, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Лёша, это чушь Практически невозможно представить себе случая, когда ты сам смо... текст свёрнут, показать
     
  • 27.176, AlexAT (ok), 16:11, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не суди обо всех по себе Тчк ... текст свёрнут, показать
     
  • 28.182, Кирилл (??), 12:51, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я и не пытаюсь Не каждый имеет более, чем 10-ти летний опыт разработки и оптими... текст свёрнут, показать
     
  • 29.187, AlexAT (ok), 15:58, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Понты Организации и ФИО в студию - поглядим ... текст свёрнут, показать
     
  • 27.212, Аноним (-), 16:01, 13/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Тут на Оракле, у которого этот оптимизатор уж точно не полное г на больших сер... текст свёрнут, показать
     
  • 4.36, anonymous (??), 16:08, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Postgres ему точно поможет
    > Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не
    > считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера -
    > половина~ хостов туда, половина сюда.
    > Партишионинг я не осилил.
    > Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные
    > (для меня) основные процессы Z.

    Заббикс версии 1.8 или 2.+?

     
  • 4.46, XoRe (ok), 17:12, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Могу порекомендовать:

    autopartitioning для zabbix 2.x, самый простой и эффективный способ:
    https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning
    После него можно выключать housekeeper.
    И в крон прописать удалять партиции history_* старше месяца.

    autopartitioning помогает решить 2 проблемы:
    - база растет в разы медленнее
    - удаление старых данных происходит мгновенно

    Ещё Shmsetup для postgresql:
    http://leopard.in.ua/2011/02/05/nastrojka-shared-memory-dlya-postgresql-sovet

    Ну и в заббиксе поиграться с количеством pooler.

     
  • 4.66, AlexAT (ok), 21:48, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А для статистики - не скажете число итемов/триггеров? Просто интересно, насколько наша инсталляция крупная/мелкая.
     
     
  • 5.128, Andrey Mitrofanov (?), 12:47, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А для статистики - не скажете число итемов/триггеров?

    Свой офтопик про Zabbix + PgSQL я вынес из темы про TokuDB. http://www.opennet.ru/openforum/vsluhforumID13/848.html 2All: Присоединяйтесь.

     
  • 2.16, AlexAT (ok), 14:24, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Поможет. Проверено (сейчас 96735 item'ов, 27951 триггер, и это еще только начало).

    Но в заббиксе полно ногами писанных мест, которые требуют оптимизации специфично под MySQL.

    Зы. Заббикс очень хорошо уживается с MariaDB/TokuDB со включенными оптимизациями, кроме index_condition_pushdown.

     
  • 2.3, ананим (?), 12:20, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    MySQL-движки всегда были (и остаются) одними из самых высокопроизводительных среди реляционных субд.
    Колобки и буратины, с функциональностью не путаете?
     
     
  • 3.13, anonymous (??), 14:17, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Во отличии от других баз данных, в mysql с самого начала были storage engines, т... большой текст свёрнут, показать
     
     
  • 4.14, sauron (??), 14:20, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –6 +/
    > Postgresql. PG до сих пор в позиции догоняющего, но так как
    > более 20 ядер нужно не всем, то компромис быстрый, но мало
    > фичастый (mysql) и медленный, но реализующий то же что и коммерческие
    > базы (PG) для многих свежих проектов смещается в сторону PG.

    Про быстрый mysql поржал.

     
     
  • 5.18, AlexAT (ok), 14:27, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Про быстрый mysql поржал.

    Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и с учетом особенностей движка - оно летает на огромных базах.

     
     
  • 6.22, sauron (??), 14:38, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных
    > запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и
    > с учетом особенностей движка - оно летает на огромных базах.

    Увы умею. У него проблема есть, которую частично вот этот движок компенсирует. А именно отвратительная работа при интенсивной записи, которую люди всяко разно  Ну а так да конечно если вместо того чтобы взять нормальную СУБД, можно попрыгать вокруг оптимизации того как положить данные в MySQL.

     
     
  • 7.25, AlexAT (ok), 15:09, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нормальную - это какую?
    Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает пахнуть.
     
     
  • 8.27, sauron (??), 15:12, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да тот же PostgreSQL... текст свёрнут, показать
     
     
  • 9.30, pro100master (ok), 15:35, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    да так же он захлёбывается Другого быстрого способа быстрых вставок, кроме как ... текст свёрнут, показать
     
     
  • 10.34, sauron (??), 15:47, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Он начинает захлебываться позже чем MySQL А так да если надо много и быстро пис... текст свёрнут, показать
     
  • 10.40, Кирилл (??), 17:04, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Школьники, идите читайте про сам принцип работы того же Слона Почитайте, что та... текст свёрнут, показать
     
     
  • 11.45, Кирилл (??), 17:08, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    и пишутся ... текст свёрнут, показать
     
  • 9.42, Хрен с горы (?), 17:06, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Нет веры человеку у которого на аватарке аниме-фигня ... текст свёрнут, показать
     
     
  • 10.67, zed_0xff (?), 22:07, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    лол, молодец, яростно плюсую ЗЫ моргухтар превед ... текст свёрнут, показать
     
  • 10.72, Аноним (-), 23:49, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    сказал человек который вообще с ником хрен с горы ... текст свёрнут, показать
     
  • 9.48, AlexAT (ok), 17:23, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А TokuDB к нему уже прикрутили Есть предположение, что на конкретном железе и ... текст свёрнут, показать
     
     
  • 10.64, Аноним (-), 21:06, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Только почему-то самая большая и нагруженная база крутится под постгресом ... текст свёрнут, показать
     
     
  • 11.65, AlexAT (ok), 21:19, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У кого ... текст свёрнут, показать
     
     
  • 12.93, aurved (?), 11:27, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не знаю как насчет самой большой и нагруженной, но наверно имелось в виду Skype ... текст свёрнут, показать
     
     
  • 13.94, AlexAT (ok), 11:40, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Есть подозрение, что у википедии и фейсбука база куда побольше в плане объема по... текст свёрнут, показать
     
  • 13.95, Andrey Mitrofanov (?), 11:40, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Микросовтофаг попалился B google самая большая БД B и поговорил с хабрафаг... текст свёрнут, показать
     
  • 6.49, XoRe (ok), 17:24, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Про быстрый mysql поржал.
    > Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных
    > запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и
    > с учетом особенностей движка - оно летает на огромных базах.

    Затыки как раз и начинаются на огромных базах. Мы же все помним рекомендацию по тюнингу innodb? Желательно, чтобы все innodb таблицы помещались в innodb_buffer_pool_size.
    Т.е., когда все умещается в оперативку, все прекрасно.

     
     
  • 7.51, AlexAT (ok), 17:27, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Затыки как раз и начинаются на огромных базах.

    И именно для этих случаев есть TokuDB и возможность его прикрутить к MySQL.

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

    Своими глазами при анализе тормозов одной системы на этой неделе увидел, как ребятам из солидной конторы в их продукте удалось заткнуть в хлам MSSQL на таблице в 70000 строк из 5 числовых полей... Впрочем, тут виноват не MSSQL, и не таблица. А вполне себе очень даже руки того, кто эту алгоритмику писал.

     
     
  • 8.54, XoRe (ok), 17:29, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    С этим никто не спорит Мы обсуждаем вменяемую среду использования ... текст свёрнут, показать
     
     
  • 9.56, AlexAT (ok), 18:05, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Проблема в том, что про тормозной MySQL истерят как раз в основном пейсатели, ... текст свёрнут, показать
     
     
  • 10.114, XoRe (ok), 22:38, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Что же это вы всех сразу в пейсатели-чайники записали Мне кажется, подход ес... текст свёрнут, показать
     
     
  • 11.117, AlexAT (ok), 22:43, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    С такими базами и подходы уже специфичные Там де факто не важно - мускул или не... текст свёрнут, показать
     
     
  • 12.129, XoRe (ok), 15:11, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Честно говоря, не понял А вообще в том и дело, что pgsql показывает лучшие хара... текст свёрнут, показать
     
     
  • 13.131, AlexAT (ok), 21:05, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А что я делаю не так с моим сжатым объемом базы в TokuDB в 246 Гб 800 Гб несжа... текст свёрнут, показать
     
  • 13.157, AlexAT (ok), 00:16, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Мне тут на одном форуме вновь глаза открыли может ошиблись, конечно, но над... текст свёрнут, показать
     
     
  • 14.160, тень_pavel_simple (?), 09:28, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    коенчно вакуум никуда не делся, приборкой кто-то заниматься должен но то что бы... большой текст свёрнут, показать
     
  • 14.161, Andrey Mitrofanov (?), 10:02, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я понимаю, чо тебе не надо, но коли уж спросил прочитай по MVCC Вакуум из него... большой текст свёрнут, показать
     
     
  • 15.162, AlexAT (ok), 10:20, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за информацию Пусть будет Андрей простите, в исходном сообщении ошибс... большой текст свёрнут, показать
     
     
  • 16.163, sauron (??), 13:18, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Замечу что точно так же делается в PostgreSQL ... текст свёрнут, показать
     
     
  • 17.164, AlexAT (ok), 19:19, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Тогда зачем там VACUUM Под равномерный рост стагнация , например, предполагало... текст свёрнут, показать
     
     
  • 18.165, sauron (??), 19:26, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Смотря какой VACUUM Если FULL ANALYZE смотреть то он перестраивает таблицу с уд... текст свёрнут, показать
     
     
  • 19.166, AlexAT (ok), 19:36, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Таки новые данные запишутся на освобожденное место без фонового VACUUM С фоновы... текст свёрнут, показать
     
     
  • 20.171, Andrey Mitrofanov (?), 23:31, 06/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Если не повезёт zabbix и ленивый админ, как я, с автовакуумом по умолчани... текст свёрнут, показать
     
  • 21.172, AlexAT (ok), 23:41, 06/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Во, спасибо У InnoDB - сидит в отдельных файлах Новые данные сразу пишутся на ... текст свёрнут, показать
     
  • 19.174, Кирилл (??), 16:04, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Аналог хвоста данных отмены есть во всех СУБД с MVCC Реализация различна в Сло... текст свёрнут, показать
     
     
  • 20.177, AlexAT (ok), 16:14, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну да, просто неплохой способ загнать таблицу в блокировку, и получить timeout ... текст свёрнут, показать
     
  • 21.185, XoRe (ok), 15:25, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    vacuum ы разные бывают Просто vacuum работает без exclusive lock exclusive loc... текст свёрнут, показать
     
  • 22.190, AlexAT (ok), 16:15, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Уже веселее Но всё равно неприятно следующее VACUUM causes a substantial incre... текст свёрнут, показать
     
  • 23.209, XoRe (ok), 20:44, 15/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Для вас новость, что дефрагментация вызывает большой I O ... текст свёрнут, показать
     
  • 24.210, AlexAT (ok), 23:06, 15/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да нет, неприятно, что данная СУБД не умеет повторно использовать свободное мест... текст свёрнут, показать
     
  • 21.186, Кирилл (??), 15:40, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Там нет ни эскалации блокировок, ни эксклюзивного блокирования Единственно... текст свёрнут, показать
     
  • 5.75, nagual (ok), 01:49, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Postgresql. PG до сих пор в позиции догоняющего, но так как
    >> более 20 ядер нужно не всем, то компромис быстрый, но мало
    >> фичастый (mysql) и медленный, но реализующий то же что и коммерческие
    >> базы (PG) для многих свежих проектов смещается в сторону PG.
    > Про быстрый mysql поржал.

    Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ?

     
     
  • 6.175, Кирилл (??), 16:05, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ?

    Оракл на раве.

     
  • 5.78, Аноним (-), 02:51, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Про быстрый mysql поржал.

    Ахтунг, лошади на опеннете.

     
  • 4.17, бедный буратино (ok), 14:27, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Во отличии от других баз данных, в mysql с самого начала были storage engines

    Вопрос не в этом, совершенно. Вопрос в том, что даёт, и в чём ограничивает привязка к MySQL (и ещё в том, что есть mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры, а здравый смысл - позора?

     
     
  • 5.19, AlexAT (ok), 14:29, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Вопрос не в этом, совершенно. Вопрос в том, что даёт, и в
    > чём ограничивает привязка к MySQL (и ещё в том, что есть
    > mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и
    > зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры,
    > а здравый смысл - позора?

    Ну так идите и сделайте свой с нуля. Со всеми шахматами и поэтессами. Или все-таки коза баяна не стоит, и имеет смысл в качестве базиса для нового использовать готовое, и неплохо работающее?

     
     
  • 6.23, бедный буратино (ok), 14:38, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Ну так идите и сделайте свой с нуля.

    Фееричный диалог:

    - Использование обвязки MySQL для этого движка тормозит его работу?
    - Идите и сделайте свой с нуля

    не уступает лучшему творению жанра "У меня есть дома барабан, пойдёмте поеб...".

     
     
  • 7.26, AlexAT (ok), 15:10, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    "свой движок RDBMS"
    так понятнее? или буквы тоже объяснять?

     
     
  • 8.28, бедный буратино (ok), 15:19, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Заяц тоже стопсигнал ... текст свёрнут, показать
     
     
  • 9.73, Аноним (-), 23:50, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    только маленький еще ... текст свёрнут, показать
     
  • 5.21, anonymous (??), 14:34, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вас с какого курса филфака вытурили и как вы при этом попали в сферу ИТ?
     
     
  • 6.24, бедный буратино (ok), 14:39, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > как вы при этом попали в сферу ИТ?

    Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на то, чтобы что-то уметь, не хватило.


     
     
  • 7.31, AlexAT (ok), 15:36, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на
    > то, чтобы что-то уметь, не хватило.

    Заметно, между прочим... Только вот да - что вы при этом в сфере IT до сих пор делаете?

     
     
  • 8.74, Аноним (-), 23:50, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    По моим наблюдениям он больше всего занимается тем что бредит ... текст свёрнут, показать
     
     
  • 9.76, бедный буратино (ok), 02:18, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вините в этом свой узкий кругозор Когда рамки слишком узкие, а вещи, для понима... большой текст свёрнут, показать
     
  • 9.77, бедный буратино (ok), 02:27, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Можно, конечно, сказать, что они счастливы в этом узком мирке, но это же неправд... текст свёрнут, показать
     
     
  • 10.103, AlexAT (ok), 19:39, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И показал на своём сравнительном примере, что сообщество, в общем-то, милые и пр... текст свёрнут, показать
     
  • 4.39, Кирилл (??), 16:59, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Во отличии от других баз данных, в mysql с самого начала были
    > storage engines, т.к. возможность менять алгоритм хранения без написания SQL части
    > каждый раз.

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

    К слову, SQL-часть для InnoDB и близко не будет аналогичной в случае использования того же MyISAM. Если понимаешь, что делаешь.

     
     
  • 5.59, anonymous (??), 19:08, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    storage engine это API, много различных индексов есть во всех базах. Опять же это "индексов", а не полностью контроль над всеми данными
     
     
  • 6.150, Кирилл (??), 16:02, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > storage engine это API, много различных индексов есть во всех базах. Опять
    > же это "индексов", а не полностью контроль над всеми данными

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

     
  • 4.47, XoRe (ok), 17:20, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > - изначально разные группы разработчиков работали над storage engines и репликацией/sql
    > параллельно, что дало увеличенную скорость разработки и позволило сконцентрироваться
    > на вопросах производительности.

    Т.е. когда писал свое и в результате они обошли pgsql про очкам? :)

     
     
  • 5.60, anonymous (??), 19:12, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Т.е. когда писал свое и в результате они обошли pgsql про очкам?
    > :)

    Разработчики PG решили, что надо бы быстрее работать только после 8,
    почему все так упорно решили забыть что было с постгре в 5-7 версиях?
    MySQL тогда популярность набрал, а не сейчас.
    Почему выстрелили web проекты на mysql 3.23 а не на постгресе?
    Потому что mysql быстро развивался и был простым в использовании.
    А посгрес был идеальной базой данных, которую только некоторые джависты использовали, потому что все фичи энтерпрайза, кроме скорости работы на хорошем железе

     
     
  • 6.82, Evgueni (?), 06:38, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине: наличие версии под ОС Windows. Всё.
     
     
  • 7.83, бедный буратино (ok), 07:07, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине:
    > наличие версии под ОС Windows. Всё.

    Скорее даже набора "юный сайтостроитель.exe", который было легко развернуть.

    MS Visual InterDev был страшен, ужасен, невнятен, а юный сайтостроитель.exe внёс частичку невиданного доселе удобства - юниксвея, плейнтекста и быстрой разработки безо всякой мышиной возни. Да ещё без кряка.exe

     
  • 7.89, AlexAT (ok), 09:45, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине:
    > наличие версии под ОС Windows. Всё.

    И много проектов под Win/MySQL вы знаете?

     
     
  • 8.91, angra (ok), 10:14, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почти все пыхеры, с которыми я сталкивался, сидят под виндой, под ней же и разра... текст свёрнут, показать
     
     
  • 9.92, AlexAT (ok), 10:22, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не совсем понимаю - что в целом в этом плохого Если специфика приложения и язык... большой текст свёрнут, показать
     
     
  • 10.96, бедный буратино (ok), 11:42, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ваше мнение очень важно для нас ... текст свёрнут, показать
     
     
  • 11.97, AlexAT (ok), 11:43, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Аналогично ... текст свёрнут, показать
     
  • 10.98, кверти (ok), 12:45, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    топ менеджер компании компании БМВ ездит на мерсе, что тут плохого ну кроме тог... текст свёрнут, показать
     
     
  • 11.100, AlexAT (ok), 14:02, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Уверены Это не россия ... текст свёрнут, показать
     
  • 10.99, angra (ok), 13:59, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы уже забыли свой вопрос Напоминаю Или увидели слово пыхер и, забыв обо все... текст свёрнут, показать
     
     
  • 11.101, AlexAT (ok), 14:03, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Повторяю вопрос еще раз для особо тупых упертых много ли проектов __ПОД WIN MYS... текст свёрнут, показать
     
     
  • 12.104, angra (ok), 20:06, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я повторюсь, мне не сложно Продакшен под Linux MySQL, но разработка идет под Wi... текст свёрнут, показать
     
  • 6.107, Аноним (-), 17:23, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Почему выстрелили web проекты на mysql 3.23 а не на постгресе?
    > Потому что mysql быстро развивался и был простым в использовании.

    основная причина - потому что постгрес практически невозможно использовать на sharing hosting.

     
  • 4.53, Кирилл (??), 17:29, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    "Быстрый" MySQL быстрый только пока вообще не СУБД, а просто хрень для последовательной записи в файл. Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID.
     
     
  • 5.61, ананим (?), 20:32, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID.

    Новость не читай, быстро отвечай.

     
  • 4.151, Кирилл (??), 16:06, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/

    > PG до сих пор в позиции догоняющего, но так как
    > более 20 ядер нужно не всем, то компромис быстрый, но мало
    > фичастый (mysql) и медленный, но реализующий то же что и коммерческие
    > базы (PG) для многих свежих проектов смещается в сторону PG.

    Водораздел не там проводите: MySQL -- если ценность данных мусорная (в куда меньшей степени касается InnoDB, но InnoDB не блещет скоростью на фоне сходных решений); PG -- если данные всё же имеют какую-то ценность.

     

     ....большая нить свёрнута, показать (131)

  • 1.6, Аноним (-), 12:45, 26/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?
     
     
  • 2.15, anonymous (??), 14:22, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    и то и то может crash recovery.
    И то и то будет падать по assertion, в случае, если данные повреждены:
    - нарушение порядка записи/игнорирование fsync
    - нули вместо данных после востановления сбойного диска

    Разница только в том что для TokuDB пока ещё нет парсера сырых файлов, как для InnoDB и последней надежды получить данные в виде csv нет.

     
     
  • 3.32, AlexAT (ok), 15:37, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > И то и то будет падать по assertion, в случае, если данные
    > повреждены:
    > - нарушение порядка записи/игнорирование fsync
    > - нули вместо данных после востановления сбойного диска

    +1

    > Разница только в том что для TokuDB пока ещё нет парсера сырых
    > файлов, как для InnoDB и последней надежды получить данные в виде
    > csv нет.

    Backup rulez.

     
  • 2.20, AlexAT (ok), 14:30, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?

    А что у InnoDB не так? Ни по тому, ни по тому ничего фатального на нормальном железе не видел. Да и бэкапов никто не отменял.

     
  • 2.43, Кирилл (??), 17:06, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?

    Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет.

     
     
  • 3.68, Аноним (-), 22:25, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет.

    Да что Вы говорите?! Неуж-то и в самом деле нету? Вобще?

    Или Вы хотите сказать, что все таблицы всех баз по умолчанию хранятся в одном файле (ибо shared tablespace)?
    А если в конфиге написать innodb_file_per_table ?

     
     
  • 4.148, Кирилл (??), 15:56, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это по принципу написал на заборе *** и вот он.
    Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним файлом, хоть сотней. К тому же иннодб поддерживает принципы acid.
     
     
  • 5.155, AlexAT (ok), 18:04, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Это по принципу написал на заборе *** и вот он.
    > Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним
    > файлом, хоть сотней. К тому же иннодб поддерживает принципы acid.

    Чушь собачья. При innodb_file_per_table данные таблиц хранятся в отдельных неймспейсах.

     
     
  • 6.167, Кирилл (??), 11:55, 03/05/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Лёша, ты слышал звон, да не въехал откуда он. А этот звон из твоих штанов.
    Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств сегментов, которые к нему приписаны). А не физическое представление.
     
     
  • 7.168, AlexAT (ok), 17:40, 03/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств
    > сегментов, которые к нему приписаны). А не физическое представление.

    Я просто оставлю это здесь, дабы спугнуть любителей обсуждать сферических коней в вакууме:
    http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

     
     
  • 8.169, Кирилл (??), 15:30, 06/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Э, суть в том, что таблица это такая штука, где есть первая строка, за первой ст... текст свёрнут, показать
     
     
  • 9.170, AlexAT (ok), 19:11, 06/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Суть в том, что таблица СУБД - это не такая штука, как таблица на бумаге перва... большой текст свёрнут, показать
     
     
  • 10.178, Кирилл (??), 16:15, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Лёша, в жизни крутиться вокруг названий И называть таблицей нужно именно таблиц... большой текст свёрнут, показать
     
     
  • 11.179, AlexAT (ok), 16:21, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Всё крутится вокруг сути, а не вокруг названий Предположим дерьмо вдруг назвали... большой текст свёрнут, показать
     
     
  • 12.183, Кирилл (??), 13:01, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Суть разная -- и название разное Читай Кодда, лучше Дэйта, до просветления Лёх... текст свёрнут, показать
     
     
  • 13.188, AlexAT (ok), 15:59, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Печалька печальная Еще раз подтверждаешь, что от теоретика до практика - пропас... текст свёрнут, показать
     
     
  • 14.191, Кирилл (??), 04:02, 09/05/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Леха, увы, подобные сентенции -- про бесполезность теории -- обычно выдают в соб... текст свёрнут, показать
     
     
  • 15.192, arisu (ok), 04:05, 09/05/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а тут не бесполезность, тут 171 страшно далеки они от народа 187 потому что... текст свёрнут, показать
     
     
  • 16.195, nagual (ok), 18:09, 10/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это вы про автомобильТеслы на трех радиолампах За который его заперли под дома... текст свёрнут, показать
     
     
  • 17.196, arisu (ok), 18:27, 10/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а ещё он марсиан видел ... текст свёрнут, показать
     
  • 17.197, AlexAT (ok), 22:24, 10/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Да Тесла вообще-то практик был, 100 -й - он сначала внедрял идеи на основе сущес... текст свёрнут, показать
     
  • 15.193, arisu (ok), 04:06, 09/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    p s это не значит, что машина не нужна ... текст свёрнут, показать
     
  • 15.194, AlexAT (ok), 12:32, 09/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Теория не бесполезна, но вот слепое поклонение теории - удел недалеких, Кира Кр... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (22)

  • 1.8, Аноним (-), 13:06, 26/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Помимо открытия кода под GPLv2, они дали какие-нибудь обещания насчет своих патентов на этот движок? Или новая бизнес-модель заключается в патентном троллинге всех, кто по наивности начнет эту штуку использовать?
     
     
  • 2.69, Аноним (-), 22:37, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    форкать не выйдет :)
     
     
  • 3.70, Аноним (-), 22:37, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > форкать не выйдет :)

    fractal library

     
     
  • 4.71, Аноним (-), 22:40, 26/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> форкать не выйдет :)
    > fractal library

    Are 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).

     

  • 1.79, Онаним (?), 05:02, 27/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при этом очень редки)? Полезная штука?
     
     
  • 2.80, Аноним (-), 05:07, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Нет используй в таком случае InnoDB.

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

     
     
  • 3.88, AlexAT (ok), 09:44, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > TokuDB это типа хранилища для архивов или аналитики, где преобладает запись.
    > TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую
    > то аналитическую систему сбора

    Неправда. Она в целом хорошо справляется не только с записью, но и увеличивает параллелизм + несколько оптимизирует тяжелые выборки за счет структур на диске. Плюс сильная компрессия, которая позволяет балансировать между disk-bound и CPU-bound.

    А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column add/delete без остановки операций и блокировки таблицы. Впервые начали использовать TokuDB только из-за этого - потому, что новая аналитика постоянно требовала новых индексов.

     
     
  • 4.180, Кирилл (??), 16:22, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column
    > add/delete без остановки операций и блокировки таблицы.

    Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут же непредсказуемые фантомы.

     
     
  • 5.181, AlexAT (ok), 16:27, 07/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут
    > же непредсказуемые фантомы.

    См. сайт разработчика - там в презентациях все разжевано. Данные перемещаются большими блоками, все изменения добавляются к корню, и протаскиваются по нодам в фоновом режиме. Да, снизит скорость последующих выборок по нодам, но только однократно. Зато на таблицах в xxx Гб-Тб не имеем простоя при смене структуры.

    Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API _моментально_, старые транзакции завершаются со старой структурой, новые - идут с новой. Реальное изменение структуры идёт в фоне.

    Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри файла, структура самодефрагментирующаяся.

     
     
  • 6.184, Кирилл (??), 13:19, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API
    > _моментально_, старые транзакции завершаются со старой структурой, новые - идут с
    > новой. Реальное изменение структуры идёт в фоне.

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

    > Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри
    > файла, структура самодефрагментирующаяся.

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


     
     
  • 7.189, AlexAT (ok), 16:05, 08/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Моментально? Ну вот начал ты длинную транзакцию, в её процессе структура, ладно,
    > "таблиц" изменилась

    Ты почитай механизмы работы TokuDB, на практике посмотри. Там фокус как раз в том, что все изменения применяются по мере завершения транзакций, а новые транзакции изменения видят сразу.

    > прежняя структура где-то и как-то сохраняется?
    > Но этот механизм не ясен.

    Сам механизм ясен и прозрачен. Представь себе, что вся база - один большой сплошной лог (!!!). Который тихонько самодефрагментируется, вычищая ненужное, и реорганизуя записи в линейные структуры. Немножко упростил, но вот это и есть TokuDB.

    > Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть

    Там хитро - структура сама дефрагментируется в процессе штатного функционирования. Она устроена так, что не фрагментируется.


     
     
  • 8.198, Аноним (-), 18:14, 13/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не очень-то тихонько, на самом деле В последних бенчах на mysqlperformanceblog ... текст свёрнут, показать
     
     
  • 9.202, AlexAT (ok), 07:31, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вы вот об этом бенче - http www mysqlperformanceblog com 2013 05 07 benchmarki... текст свёрнут, показать
     
     
  • 10.207, Аноним (-), 23:45, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Конкретный бенч раскрывает конкретную сторону конкретной медали, что от него и т... большой текст свёрнут, показать
     
     
  • 11.208, AlexAT (ok), 07:21, 15/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Неправильный ответ Ведет себя оно в разы лучше InnoDB ... текст свёрнут, показать
     
     
  • 12.211, Аноним (-), 23:55, 15/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Так я же не сказал отвратительно , а всего лишь так себе ... текст свёрнут, показать
     
  • 4.201, Аноним (-), 18:33, 13/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Практически -- только Уже на UPDATE она медленней, а на INSERT ON DUPLICATE - с... большой текст свёрнут, показать
     
     
  • 5.205, AlexAT (ok), 08:21, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Практически -- только. Уже на UPDATE она медленней, а на INSERT ON
    > DUPLICATE - совсем всё плохо. Есть, правда, специальный случай апдейта "x
    > = x + c" где с - константа, специально оптимизированный в
    > Toku, остальное - в пролете.

    Да, очень сильно зависит от структуры таблицы. Я бы не сказал, что на UPDATE сложных таблиц с кучей индексов оно медленнее. Насчет оптимизации - сильно не хватает X = X + VALUE(X).

     
     
  • 6.206, Аноним (-), 23:36, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    обещали добавить
     
  • 2.85, AlexAT (ok), 09:33, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при
    > этом очень редки)? Полезная штука?

    Если у вас disk-bound workload - да. Структура индексов у TokuDB очень хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие, не привносящее диких тормозов, как у InnoDB.

    Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.

     
     
  • 3.86, Аноним (-), 09:40, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.

    в badoo СУБД на одних php скриптах :D

     
  • 3.87, Аноним (-), 09:43, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при
    >> этом очень редки)? Полезная штука?
    > Если у вас disk-bound workload - да. Структура индексов у TokuDB очень
    > хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие,
    > не привносящее диких тормозов, как у InnoDB.
    > Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.

    Один из очевидных плюсов очень мало настроек, в отличии от пары сотен тонких настроек innodb

     
     
  • 4.90, AlexAT (ok), 09:46, 27/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Один из очевидных плюсов очень мало настроек, в отличии от пары сотен
    > тонких настроек innodb

    Да, кстати. Очень универсальный двиг, работающий практически "из коробки".

     
  • 4.149, Кирилл (??), 15:59, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Один из очевидных плюсов очень мало настроек, в отличии от пары сотен
    > тонких настроек innodb

    Какой ещё "пары сотен"? )))) Всё настраивается не более чем десятком очевидных параметров.

     
  • 3.112, Аноним (-), 22:20, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom
     
     
  • 4.116, AlexAT (ok), 22:41, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom

    Это если CPU-bound из-за сложных выражений. А если он возник из-за объема данных / сортировки, то таким образом только шина в полку уложится, и результат будет отрицательный.

    Но вот для массивного REGEXP / LIKE по базе вполне себе интересно, если конечно умеет.

     
     
  • 5.119, Аноним (-), 23:18, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom
    > Это если CPU-bound из-за сложных выражений. А если он возник из-за объема
    > данных / сортировки, то таким образом только шина в полку уложится,
    > и результат будет отрицательный.

    Ну это и не CPU-bound а bus bound таки.

    > Но вот для массивного REGEXP / LIKE по базе вполне себе интересно,
    > если конечно умеет.

    Не надо бы базе LIKE поручать, нехорошо это, есть же более другие средства, хотя бы и встроенные типа FTS.

     
     
  • 6.121, AlexAT (ok), 07:27, 29/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну это и не CPU-bound а bus bound таки.

    Будет. Что еще хуже, чем CPU bound.

    > Не надо бы базе LIKE поручать, нехорошо это, есть же более другие
    > средства, хотя бы и встроенные типа FTS.

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

     
     
  • 7.156, Аноним (-), 21:17, 30/04/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>  я не могу представить себе задачу БД, которую можно поручить GPU. Упрётся в шину.

    Расчет шейдеров на карте онлайн игры

     
  • 7.199, Аноним (-), 18:17, 13/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Именно так. Просто помимо сложных выражений я не могу представить себе задачу
    > БД, которую можно поручить GPU. Упрётся в шину.

    Так дело в том что "сложных выражений" становится всё больше, дальше если с виду они и не особо сложные. Тот же JSON в Pg 9.3 - распарсить, что-то из него добыть и добытое опять в JSON чтоб отдать - очень даже CPU-bound будет.

     
     
  • 8.203, AlexAT (ok), 08:14, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужен Адовое нарушение собственно принципа структурирования РСУБД Чего-то п... текст свёрнут, показать
     

     ....большая нить свёрнута, показать (26)

  • 1.105, Аноним (-), 06:32, 28/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для перконы собрали двоичные и бинарные

    http://www.mysqlperformanceblog.com/2013/04/24/percona-server-5-5-30-with-tok

     
     
  • 2.110, ryoken (?), 19:40, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > собрали двоичные и бинарные

    Для тупых поясните... это уже не одно и тоже?

     

  • 1.111, yuris (??), 22:07, 28/04/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы всё равно упираются в 99% случаев в разбор SQL и составление планов выполнения запросов? Эти все улучшения будут иметь смысл только при очень простых запросах на больших объёмах данных, что в майсиквеле не так уж часто встречается.

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

     
     
  • 2.113, Аноним (-), 22:24, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Квантовый двигатель ?
     
  • 2.115, AlexAT (ok), 22:39, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы
    > всё равно упираются в 99% случаев в разбор SQL и составление
    > планов выполнения запросов? Эти все улучшения будут иметь смысл только при
    > очень простых запросах на больших объёмах данных, что в майсиквеле не
    > так уж часто встречается.

    ЧЕГО? На огромных базах ворклоуд либо cpu-bound, либо disk-bound. TokuDB сильно упрощает жизнь для disk-bound. "Разбор SQL и составление планов" на таких базах - 0.000001% времени, а то и меньше.

    > P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет
    > вогнать в ступор любую базу с любым двиглом.

    А вот это верно.

     
  • 2.118, Аноним (-), 23:13, 28/04/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > запросы всё равно упираются в 99% случаев в разбор SQL

    Откройте для себя prepared statement уже наконец.

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

    Как раз в MySQL оно только и встречается. Для сложных запросов там планировщика можно считать что просто нет, по сравнению с PostgreSQL.

     
     
  • 3.158, Crazy Alex (ok), 00:22, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я так понимаю, человек из веба, а особенно если где фреймворки с ORM - там оно именно так и выглядит - данных тянем мало, но в отдельных сущностях (которые каждый раз создаются заново) и много раз, причем 70% выборок - по первичному ключу.
     
     
  • 4.159, AlexAT (ok), 00:24, 01/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понимаю, человек из веба, а особенно если где фреймворки с
    > ORM - там оно именно так и выглядит - данных тянем
    > мало, но в отдельных сущностях (которые каждый раз создаются заново) и
    > много раз, причем 70% выборок - по первичному ключу.

    Да даже там разбор запроса - это ни о чём. В него упереться можно только на базах < pool size или на совсем хилых VPS/VDS.

     
     
  • 5.200, Аноним (-), 18:20, 13/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Да даже там разбор запроса - это ни о чём. В него
    > упереться можно только на базах < 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.html

     
     
  • 6.204, AlexAT (ok), 08:17, 14/05/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > "..>95% of the CPU time in reads is spent in the SQL
    > parser"
    > http://www.openldap.org/lists/openldap-devel/201203/msg00017.html

    а) это SQLite
    б) это < pool size

     
  • 6.214, anomymous (?), 11:50, 19/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а) это SQLite
    б) это OpenLDAP

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

     
  • 3.213, Denisss (?), 11:45, 19/02/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> запросы всё равно упираются в 99% случаев в разбор SQL
    > Откройте для себя prepared statement уже наконец.

    Какой нафиг prepared statement в web ? На каждую страницу, на каждый коннект они убиваются.

     

  • 1.215, Аноним (215), 12:16, 04/08/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    14.04.15
    В своём блоге команда Percona заявила о приобретении компании Tokutek, разработчика движка TokuDB для СУБД MySQL/MariaDB/Percona.

    Теперь даже ссылка из шапки ведёт на сайт Перконы :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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