|
|
3.7, Andrey Mitrofanov (?), 13:00, 26/04/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Postgres ему точно поможет
Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера - половина~ хостов туда, половина сюда.
Партишионинг я не осилил.
Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные (для меня) основные процессы Z.
| |
|
|
|
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 Я вот там никаких оп... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
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 - это своя атмосфера В остальных есть Хорошо в большинстве случаев Все ... большой текст свёрнут, показать | |
24.134, sauron (??), 06:18, 30/04/2013 [^] [^^] [^^^] [ответить] | +/– | Чуваки из PostgreSQL против хинтов Они говорят что если у вас оптимизатор плохо... большой текст свёрнут, показать | |
25.136, AlexAT (ok), 08:06, 30/04/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Вот за что и не люблю академические поделки - так это за это самое а баба яга п... большой текст свёрнут, показать | |
26.138, sauron (??), 08:16, 30/04/2013 [^] [^^] [^^^] [ответить] | +/– | А специфика конкретных приложений затачивается уже указанием индексов Если вот ... большой текст свёрнут, показать | |
28.140, sauron (??), 08:34, 30/04/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Если у вас возникает такая надобность, то надо внимательно посмотреть на свою ба... большой текст свёрнут, показать | |
29.145, AlexAT (ok), 09:29, 30/04/2013 [^] [^^] [^^^] [ответить] | +/– | Скорее на оптимизатор, так как хинтинг даёт огромную разницу минуты - секунды ... большой текст свёрнут, показать | |
30.146, sauron (??), 09:43, 30/04/2013 [^] [^^] [^^^] [ответить] | +/– | Чаще бывает случай все же что приложение косое Я не спорю что сильно зависит от... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.36, anonymous (??), 16:08, 26/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
>> Postgres ему точно поможет
> Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не
> считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера -
> половина~ хостов туда, половина сюда.
> Партишионинг я не осилил.
> Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные
> (для меня) основные процессы Z.
Заббикс версии 1.8 или 2.+?
| |
4.66, AlexAT (ok), 21:48, 26/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
А для статистики - не скажете число итемов/триггеров? Просто интересно, насколько наша инсталляция крупная/мелкая.
| |
|
|
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-движки всегда были (и остаются) одними из самых высокопроизводительных среди реляционных субд.
Колобки и буратины, с функциональностью не путаете?
| |
|
|
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 [^] [^^] [^^^] [ответить]
| +/– |
Нормальную - это какую?
Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает пахнуть.
| |
|
|
|
10.34, sauron (??), 15:47, 26/04/2013 [^] [^^] [^^^] [ответить] | –1 +/– | Он начинает захлебываться позже чем MySQL А так да если надо много и быстро пис... текст свёрнут, показать | |
|
9.48, AlexAT (ok), 17:23, 26/04/2013 [^] [^^] [^^^] [ответить] | +/– | А TokuDB к нему уже прикрутили Есть предположение, что на конкретном железе и ... текст свёрнут, показать | |
|
|
|
12.93, aurved (?), 11:27, 27/04/2013 [^] [^^] [^^^] [ответить] | –1 +/– | не знаю как насчет самой большой и нагруженной, но наверно имелось в виду Skype ... текст свёрнут, показать | |
|
|
|
|
|
|
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, и не таблица. А вполне себе очень даже руки того, кто эту алгоритмику писал.
| |
|
|
9.56, AlexAT (ok), 18:05, 26/04/2013 [^] [^^] [^^^] [ответить] | +3 +/– | Проблема в том, что про тормозной MySQL истерят как раз в основном пейсатели, ... текст свёрнут, показать | |
|
|
|
12.129, XoRe (ok), 15:11, 29/04/2013 [^] [^^] [^^^] [ответить] | +/– | Честно говоря, не понял А вообще в том и дело, что pgsql показывает лучшие хара... текст свёрнут, показать | |
|
|
|
15.162, AlexAT (ok), 10:20, 01/05/2013 [^] [^^] [^^^] [ответить] | +/– | Спасибо за информацию Пусть будет Андрей простите, в исходном сообщении ошибс... большой текст свёрнут, показать | |
|
|
|
|
|
21.185, XoRe (ok), 15:25, 08/05/2013 [^] [^^] [^^^] [ответить] | +1 +/– | vacuum ы разные бывают Просто vacuum работает без exclusive lock exclusive loc... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 ?
Оракл на раве.
| |
|
|
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 для этого движка тормозит его работу?
- Идите и сделайте свой с нуля
не уступает лучшему творению жанра "У меня есть дома барабан, пойдёмте поеб...".
| |
|
|
6.24, бедный буратино (ok), 14:39, 26/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> как вы при этом попали в сферу ИТ?
Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на то, чтобы что-то уметь, не хватило.
| |
|
7.31, AlexAT (ok), 15:36, 26/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на
> то, чтобы что-то уметь, не хватило.
Заметно, между прочим... Только вот да - что вы при этом в сфере IT до сих пор делаете?
| |
|
|
|
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 [^] [^^] [^^^] [ответить] | +/– | Не совсем понимаю - что в целом в этом плохого Если специфика приложения и язык... большой текст свёрнут, показать | |
|
|
|
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 -- если данные всё же имеют какую-то ценность.
| |
|
|
|
|
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 +/– |
Лёша, ты слышал звон, да не въехал откуда он. А этот звон из твоих штанов.
Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств сегментов, которые к нему приписаны). А не физическое представление.
| |
|
|
|
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 [^] [^^] [^^^] [ответить] | +/– | Всё крутится вокруг сути, а не вокруг названий Предположим дерьмо вдруг назвали... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
1.8, Аноним (-), 13:06, 26/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Помимо открытия кода под GPLv2, они дали какие-нибудь обещания насчет своих патентов на этот движок? Или новая бизнес-модель заключается в патентном троллинге всех, кто по наивности начнет эту штуку использовать?
| |
|
|
|
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.
> Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть
Там хитро - структура сама дефрагментируется в процессе штатного функционирования. Она устроена так, что не фрагментируется.
| |
|
|
|
10.207, Аноним (-), 23:45, 14/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).
| |
|
|
|
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
Какой ещё "пары сотен"? )))) Всё настраивается не более чем десятком очевидных параметров.
| |
|
|
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 будет.
| |
|
|
|
|
|
|
|
2.110, ryoken (?), 19:40, 28/04/2013 [^] [^^] [^^^] [ответить]
| +/– |
> собрали двоичные и бинарные
Для тупых поясните... это уже не одно и тоже?
| |
|
1.111, yuris (??), 22:07, 28/04/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы всё равно упираются в 99% случаев в разбор SQL и составление планов выполнения запросов? Эти все улучшения будут иметь смысл только при очень простых запросах на больших объёмах данных, что в майсиквеле не так уж часто встречается.
P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет вогнать в ступор любую базу с любым двиглом.
| |
|
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.
| |
|
|
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.
Теперь даже ссылка из шапки ведёт на сайт Перконы :)
| |
|