Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Высокопроизводительный MySQL-движок TokuDB переведён в разря..."	–1 +/–
Сообщение от opennews (??), 26-Апр-13, 11:59
Компания Tokutek открыла (http://www.tokutek.com/2013/04/open-source-tokudb-resources/) исходные тексты проекта TokuDB (http://www.tokutek.com/products/tokudb-for-mysql/) (Tokutek storage engine), в рамках которого развивается  высокопроизводительный транзакционный движок хранения для MySQL и MariaDB. Вместо классических B-tree деревьев в TokuDB применяются  рекурсивные индексы (Fractal Tree indexes (http://www.tokutek.com/resources/technology/)), что в сочетании с хранением данных в сжатом виде, позволяет значительно оптимизировать операции ввода/вывода. Движок TokuDB оптимален в системах с интенсивной записью, когда требуется накапливать полученную в результате входящих запросов информацию и периодически генерировать на её основе отчёты. В качестве основных областей применения TokuDB называются конфигурации с большим числом запросов, связанных с добавлением, удалением и изменением данных, такие как социальные сети, анализ логов, рекламные сети и т.п. При проведении тестов (http://www.tokutek.com/resources/benchmark-results/), TokuDB опережает (http://www.tokutek.com/resources/tokudb-vs-innodb/) InnoDB при добавлении больших объемов данных более чем в 10 раз (InnoDB 1,555 записей в сек, TokuDB 16,437 записей в сек), но проигрывает по степени нагрузки на CPU при выборке данных. Недостаточная эффективность выборки данных компенсируется ситуациями когда требуется произвести выборку большого числа последовательно сохранённых записей. В некоторых тестах выигрыш в скорости добавления данных достигает 80 раз. Применяемые методы сжатия данных позволяют в разы уменьшить размер базы и индексов (в 6.2 раза по сравнению с InnoDB и в 5.5 раз по сравнению с MyISAM), в некоторых ситуациях степень сжатия данных может достигать (http://www.tokutek.com/wp-content/uploads/2012/09/Tokutek-to...) 25 раз. <center><a href="http://www.tokutek.com/wp-content/uploads/2012/01/iibench.pn... src="http://www.opennet.dev/opennews/pics_base/0_1366962602.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center> Из особенностей (http://www.tokutek.com/2011/02/1773/) движка TokuDB также можно отметить: -  Обеспечении требований ACID к выполнению транзакций (атомарность, согласованность, изолированность, долговечность); -  Возможность изменения хранения схемы данных на лету, без перестроения хранилища; -  Отсутствие эффекта фрагментации индексов после длительного времени работы базы (нет необходимости пересоздавать индексы для устранения фрагментации);-  Гибкие средства ускорения выполнения запросов через использование индексов;-  Поддержка создания хранилищ для терабайт данных;-  Поддержка создания горячих бэкапов без остановки работы;-  Поддержка репликации интенсивно поступающих потоков данных на несколько slave-серверов без отставания появления данных на slave-системах;-  Соответствие требованиям MVCC (Multi-Version Concurrency Control) по работе в многопользовательских системах с большим числом одновременных запросов;-  Режим быстрого восстановления после сбоя;-  Высокая эффективность поддержания хранилищ с десятками и сотнями миллионов записей. Отсутствуют проблемы при активном удалении записей в таких хранилищах;-  Поддержка кластерных индексов, в которых непосредственно сохраняются всех данные из записей;-  По выполняемым операциям индексы Fractal Tree indexes схожи в B-Tree и отличаются главным образом более оптимальным использованием кэшей и доступа к данным на накопителях на жестких магнитных дисках, за счёт преобразования операций случайного доступа в наборы последовательных запросов. Для SSD-накопителей использование TokuDB оправдано сокращением числа операций записи. В настоящее время движок TokuDB уже используется проектом Mozilla для организации работы сервиса Datazilla, занимающегося сбором информации о производительности, автоматически отправляемой браузером Firefox, при включении соответствующих настроек. Разработчики MySQL и MariaDB приветствовали (http://www.tokutek.com/2013/04/getting-interesting/) решение по открытию кода TokuDB, заявив, что такой шаг будет способствовать широкому внедрению TokuDB. Более того, компания MariaDB уже рассматривает возможность включения TokuDB в состав MariaDB и поставки данного движка в качестве штатного компонента. Код открыт (https://github.com/Tokutek) под лицензией GPLv2. Изначально движок TokuDB развивался как проприетарный продукт, но компания  Tokutek решилась на изменение бизнес-модели, которая теперь подразумевает разработку TokuDB  как свободного проекта с предоставлением корпоративным заказчикам коммерческой версии TokuDB Enterprise Edition, которая отличается наличием сервиса технической поддержки, расширенными инструментами для резервного копирования и возможностью адаптации продукта под нужды заказчика. URL: http://www.tokutek.com/2013/04/open-source-tokudb-resources/ Новость: http://www.opennet.dev/opennews/art.shtml?num=36779
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (-), 26-Апр-13, 11:59	+6 +/–
Интересно, если Заббикс на этот движок перенести - ему поможет?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #16, #3

3. Сообщение от ананим (?), 26-Апр-13, 12:20	+4 +/–
MySQL-движки всегда были (и остаются) одними из самых высокопроизводительных среди реляционных субд. Колобки и буратины, с функциональностью не путаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #13

4. Сообщение от alp (?), 26-Апр-13, 12:22	+3 +/–
Postgres ему точно поможет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7

6. Сообщение от Аноним (-), 26-Апр-13, 12:45	+/–
Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #20, #43

7. Сообщение от Andrey Mitrofanov (?), 26-Апр-13, 13:00	+2 +/–
> Postgres ему точно поможет Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера - половина~ хостов туда, половина сюда. Партишионинг я не осилил. Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные (для меня) основные процессы Z.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #9, #36, #46, #66

8. Сообщение от Аноним (-), 26-Апр-13, 13:06	–1 +/–
Помимо открытия кода под GPLv2, они дали какие-нибудь обещания насчет своих патентов на этот движок? Или новая бизнес-модель заключается в патентном троллинге всех, кто по наивности начнет эту штуку использовать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69

9. Сообщение от sauron (??), 26-Апр-13, 13:57	+3 +/–
PostgeSQL хоть потюненый был? Или стоковый воткнули?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #10

10. Сообщение от Anonimous (?), 26-Апр-13, 14:01	+/–
Где описано как его "тюнить" для Zabbix?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #11

11. Сообщение от sauron (??), 26-Апр-13, 14:07	+3 +/–
> Где описано как его "тюнить" для Zabbix? Вообще надо банальный тюнинг под сервер произвести. Если же тюнинг не осуществлялся, то не удивительно что не помогло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #35

13. Сообщение от anonymous (??), 26-Апр-13, 14:17	+/–
Во отличии от других баз данных, в mysql с самого начала были storage engines, т.к. возможность менять алгоритм хранения без написания SQL части каждый раз. Что привело к: - появился InnoDB - появился NDB - появился Spider - появился PBXT - изначально разные группы разработчиков работали над storage engines и репликацией/sql параллельно, что дало увеличенную скорость разработки и позволило сконцентрироваться на вопросах производительности. Долгое время mysql был самой быстрой из распространённых баз данных (например для запросов по PK, часто используемых в web) и легко масштабируемым на больше чем 1 процессор, в отличии от Postgresql. PG до сих пор в позиции догоняющего, но так как более 20 ядер нужно не всем, то компромис быстрый, но мало фичастый (mysql) и медленный, но реализующий то же что и коммерческие базы (PG) для многих свежих проектов смещается в сторону PG.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #14, #17, #39, #47, #53, #151

14. Сообщение от sauron (??), 26-Апр-13, 14:20	–6 +/–
> Postgresql. PG до сих пор в позиции догоняющего, но так как > более 20 ядер нужно не всем, то компромис быстрый, но мало > фичастый (mysql) и медленный, но реализующий то же что и коммерческие > базы (PG) для многих свежих проектов смещается в сторону PG. Про быстрый mysql поржал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18, #75, #78

15. Сообщение от anonymous (??), 26-Апр-13, 14:22	+/–
и то и то может crash recovery. И то и то будет падать по assertion, в случае, если данные повреждены: - нарушение порядка записи/игнорирование fsync - нули вместо данных после востановления сбойного диска Разница только в том что для TokuDB пока ещё нет парсера сырых файлов, как для InnoDB и последней надежды получить данные в виде csv нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #32

16. Сообщение от AlexAT (ok), 26-Апр-13, 14:24	+3 +/–
Поможет. Проверено (сейчас 96735 item'ов, 27951 триггер, и это еще только начало). Но в заббиксе полно ногами писанных мест, которые требуют оптимизации специфично под MySQL. Зы. Заббикс очень хорошо уживается с MariaDB/TokuDB со включенными оптимизациями, кроме index_condition_pushdown.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

17. Сообщение от бедный буратино (ok), 26-Апр-13, 14:27	+/–
> Во отличии от других баз данных, в mysql с самого начала были storage engines Вопрос не в этом, совершенно. Вопрос в том, что даёт, и в чём ограничивает привязка к MySQL (и ещё в том, что есть mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры, а здравый смысл - позора?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #19, #21

18. Сообщение от AlexAT (ok), 26-Апр-13, 14:27	+4 +/–
> Про быстрый mysql поржал. Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и с учетом особенностей движка - оно летает на огромных базах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #22, #49

19. Сообщение от AlexAT (ok), 26-Апр-13, 14:29	+1 +/–
> Вопрос не в этом, совершенно. Вопрос в том, что даёт, и в > чём ограничивает привязка к MySQL (и ещё в том, что есть > mysql? простая обвязка для трансляции sql-запросов в понятный движку шёпот?), и > зачем ограничиваться этими ограничениями mysql? Стоит ли коза баяна, свечи игры, > а здравый смысл - позора? Ну так идите и сделайте свой с нуля. Со всеми шахматами и поэтессами. Или все-таки коза баяна не стоит, и имеет смысл в качестве базиса для нового использовать готовое, и неплохо работающее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #23

20. Сообщение от AlexAT (ok), 26-Апр-13, 14:30	+/–
> Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB? А что у InnoDB не так? Ни по тому, ни по тому ничего фатального на нормальном железе не видел. Да и бэкапов никто не отменял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

21. Сообщение от anonymous (??), 26-Апр-13, 14:34	+/–
Вас с какого курса филфака вытурили и как вы при этом попали в сферу ИТ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #24

22. Сообщение от sauron (??), 26-Апр-13, 14:38	+/–
> Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных > запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и > с учетом особенностей движка - оно летает на огромных базах. Увы умею. У него проблема есть, которую частично вот этот движок компенсирует. А именно отвратительная работа при интенсивной записи, которую люди всяко разно  Ну а так да конечно если вместо того чтобы взять нормальную СУБД, можно попрыгать вокруг оптимизации того как положить данные в MySQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #25

23. Сообщение от бедный буратино (ok), 26-Апр-13, 14:38	–3 +/–
> Ну так идите и сделайте свой с нуля. Фееричный диалог: - Использование обвязки MySQL для этого движка тормозит его работу? - Идите и сделайте свой с нуля не уступает лучшему творению жанра "У меня есть дома барабан, пойдёмте поеб...".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #26

24. Сообщение от бедный буратино (ok), 26-Апр-13, 14:39	+/–
> как вы при этом попали в сферу ИТ? Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на то, чтобы что-то уметь, не хватило.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #31

25. Сообщение от AlexAT (ok), 26-Апр-13, 15:09	+/–
Нормальную - это какую? Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает пахнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27

26. Сообщение от AlexAT (ok), 26-Апр-13, 15:10	+/–
"свой движок RDBMS" так понятнее? или буквы тоже объяснять?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #28

27. Сообщение от sauron (??), 26-Апр-13, 15:12	+1 +/–
> Нормальную - это какую? > Видели мы поделки на поделке от МС. Лучше не трогать, иначе начинает > пахнуть. Да тот же PostgreSQL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #30, #42, #48

28. Сообщение от бедный буратино (ok), 26-Апр-13, 15:19	–3 +/–
> "свой движок RDBMS" > так понятнее? или буквы тоже объяснять? Заяц тоже стопсигнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #73

30. Сообщение от pro100master (ok), 26-Апр-13, 15:35	+2 +/–
да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как в память, пока не придумали. Бестолковый холивар.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #34, #40

31. Сообщение от AlexAT (ok), 26-Апр-13, 15:36	+/–
> Не знаю. Видимо, ума на то, чтобы что-то делать, и рук на > то, чтобы что-то уметь, не хватило. Заметно, между прочим... Только вот да - что вы при этом в сфере IT до сих пор делаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #74

32. Сообщение от AlexAT (ok), 26-Апр-13, 15:37	+/–
> И то и то будет падать по assertion, в случае, если данные > повреждены: > - нарушение порядка записи/игнорирование fsync > - нули вместо данных после востановления сбойного диска +1 > Разница только в том что для TokuDB пока ещё нет парсера сырых > файлов, как для InnoDB и последней надежды получить данные в виде > csv нет. Backup rulez.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

34. Сообщение от sauron (??), 26-Апр-13, 15:47	–1 +/–
> да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как > в память, пока не придумали. Бестолковый холивар. Он начинает захлебываться позже чем MySQL. А так да если надо много и быстро писать, то в память потом пачкой на диск.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

35. Сообщение от anonymous (??), 26-Апр-13, 16:07	–1 +/–
>> Где описано как его "тюнить" для Zabbix? > Вообще надо банальный тюнинг под сервер произвести. Если же тюнинг не осуществлялся, > то не удивительно что не помогло. Zabbix написан и заточен под mysql. Если вы не эксперт постгре, я бы не рекомендовал в принципе экспериментировать. Попытки завести заббикс на других базах вынудили меня в конечном итоге вернуться к mysql для заббикса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #81

36. Сообщение от anonymous (??), 26-Апр-13, 16:08	+/–
>> Postgres ему точно поможет > Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не > считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера - > половина~ хостов туда, половина сюда. > Партишионинг я не осилил. > Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные > (для меня) основные процессы Z. Заббикс версии 1.8 или 2.+?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

39. Сообщение от Кирилл (??), 26-Апр-13, 16:59	+1 +/–
> Во отличии от других баз данных, в mysql с самого начала были > storage engines, т.к. возможность менять алгоритм хранения без написания SQL части > каждый раз. В других СУБД такая возможность тоже зачастую есть, только не преподноситься как нечто особенное. В том же Оракле полно разных типов "таблиц" и разных типов индексов, которые отличаются ни чуть не меньше, чем "движки" в MySQL. К слову, SQL-часть для InnoDB и близко не будет аналогичной в случае использования того же MyISAM. Если понимаешь, что делаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #59

40. Сообщение от Кирилл (??), 26-Апр-13, 17:04	+/–
> да так же он захлёбывается. Другого быстрого способа быстрых вставок, кроме как > в память, пока не придумали. Бестолковый холивар. Школьники, идите читайте про сам принцип работы того же Слона. Почитайте, что такое транзакция, двойная запись, векторы повторного исполнения и отката, когда сервер считает, что запись произошла, и вообще куда и откуда читаются данные.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #45

42. Сообщение от Хрен с горы (?), 26-Апр-13, 17:06	+3 +/–
Нет веры человеку у которого на аватарке аниме-фигня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #67, #72

43. Сообщение от Кирилл (??), 26-Апр-13, 17:06	–3 +/–
> Как у него с падениями и ремонтами таблиц? Лучше чем у InnoDB? Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #68

45. Сообщение от Кирилл (??), 26-Апр-13, 17:08	+/–
> Школьники, идите читайте про сам принцип работы того же Слона. Почитайте, что > такое транзакция, двойная запись, векторы повторного исполнения и отката, когда сервер > считает, что запись произошла, и вообще куда и откуда читаются данные. ... и пишутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

46. Сообщение от XoRe (ok), 26-Апр-13, 17:12	+/–
Могу порекомендовать: autopartitioning для zabbix 2.x, самый простой и эффективный способ: https://www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_au... После него можно выключать housekeeper. И в крон прописать удалять партиции history_* старше месяца. autopartitioning помогает решить 2 проблемы: - база растет в разы медленнее - удаление старых данных происходит мгновенно Ещё Shmsetup для postgresql: http://leopard.in.ua/2011/02/05/nastrojka-shared-memory-dlya.../ Ну и в заббиксе поиграться с количеством pooler.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

47. Сообщение от XoRe (ok), 26-Апр-13, 17:20	+/–
> - изначально разные группы разработчиков работали над storage engines и репликацией/sql > параллельно, что дало увеличенную скорость разработки и позволило сконцентрироваться > на вопросах производительности. Т.е. когда писал свое и в результате они обошли pgsql про очкам? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #60

48. Сообщение от AlexAT (ok), 26-Апр-13, 17:23	+/–
> Да тот же PostgreSQL А TokuDB к нему уже прикрутили? Есть предположение, что на конкретном железе и конкретной базе ежепятиминутного пополнения в 150+ гиг с аналитическими выборками оно тупо захлебнется. Во всяком случае, InnoDB захлебнулся еще на 50+ гиг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #64

49. Сообщение от XoRe (ok), 26-Апр-13, 17:24	+/–
>> Про быстрый mysql поржал. > Вы просто не умеете его готовить. Никакой движок не компенсирует ногами деланных > запросов и алгоритмов. А если запросы и алгоритмы пишутся правильно, и > с учетом особенностей движка - оно летает на огромных базах. Затыки как раз и начинаются на огромных базах. Мы же все помним рекомендацию по тюнингу innodb? Желательно, чтобы все innodb таблицы помещались в innodb_buffer_pool_size. Т.е., когда все умещается в оперативку, все прекрасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #51

51. Сообщение от AlexAT (ok), 26-Апр-13, 17:27	+/–
> Затыки как раз и начинаются на огромных базах. И именно для этих случаев есть TokuDB и возможность его прикрутить к MySQL. Я не про такие затыки. Я про написанные ногами запросы, которые заткнут любой движок. Своими глазами при анализе тормозов одной системы на этой неделе увидел, как ребятам из солидной конторы в их продукте удалось заткнуть в хлам MSSQL на таблице в 70000 строк из 5 числовых полей... Впрочем, тут виноват не MSSQL, и не таблица. А вполне себе очень даже руки того, кто эту алгоритмику писал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #54

53. Сообщение от Кирилл (??), 26-Апр-13, 17:29	–2 +/–
"Быстрый" MySQL быстрый только пока вообще не СУБД, а просто хрень для последовательной записи в файл. Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #61

54. Сообщение от XoRe (ok), 26-Апр-13, 17:29	+/–
> Я не про такие затыки. Я про написанные ногами запросы, которые заткнут > любой движок. С этим никто не спорит. Мы обсуждаем вменяемую среду использования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #56

56. Сообщение от AlexAT (ok), 26-Апр-13, 18:05	+3 +/–
> С этим никто не спорит. > Мы обсуждаем вменяемую среду использования. Проблема в том, что про "тормозной MySQL" истерят как раз в основном пейсатели, прочитавшие книжку "MS(My,нужное вписать)SQL для чайников", и реально пишущие крэп. При этом MySQL какбэ и не виноват :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #114

59. Сообщение от anonymous (??), 26-Апр-13, 19:08	+/–
storage engine это API, много различных индексов есть во всех базах. Опять же это "индексов", а не полностью контроль над всеми данными
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #150

60. Сообщение от anonymous (??), 26-Апр-13, 19:12	+/–
> Т.е. когда писал свое и в результате они обошли pgsql про очкам? > :) Разработчики PG решили, что надо бы быстрее работать только после 8, почему все так упорно решили забыть что было с постгре в 5-7 версиях? MySQL тогда популярность набрал, а не сейчас. Почему выстрелили web проекты на mysql 3.23 а не на постгресе? Потому что mysql быстро развивался и был простым в использовании. А посгрес был идеальной базой данных, которую только некоторые джависты использовали, потому что все фичи энтерпрайза, кроме скорости работы на хорошем железе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #82, #107

61. Сообщение от ананим (?), 26-Апр-13, 20:32	+/–
>Без транзакций. Без минимальной поддержки ключевых для СУБД принципов ACID. Новость не читай, быстро отвечай.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

64. Сообщение от Аноним (-), 26-Апр-13, 21:06	+/–
Только почему-то самая большая и нагруженная база крутится под постгресом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #65

65. Сообщение от AlexAT (ok), 26-Апр-13, 21:19	+1 +/–
> Только почему-то самая большая и нагруженная база крутится под постгресом. У кого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #93

66. Сообщение от AlexAT (ok), 26-Апр-13, 21:48	+/–
А для статистики - не скажете число итемов/триггеров? Просто интересно, насколько наша инсталляция крупная/мелкая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #128

67. Сообщение от zed_0xff (?), 26-Апр-13, 22:07	+/–
лол, молодец, яростно плюсую ))) ЗЫ моргухтар превед!! )))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

68. Сообщение от Аноним (-), 26-Апр-13, 22:25	+2 +/–
> Какими ещё "ремонтами таблиц"? В InnoDB таблиц вообще нет. Да что Вы говорите?! Неуж-то и в самом деле нету? Вобще? Или Вы хотите сказать, что все таблицы всех баз по умолчанию хранятся в одном файле (ибо shared tablespace)? А если в конфиге написать innodb_file_per_table ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #148

69. Сообщение от Аноним (-), 26-Апр-13, 22:37	+/–
форкать не выйдет :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #70

70. Сообщение от Аноним (-), 26-Апр-13, 22:37	+/–
> форкать не выйдет :) fractal library
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #71

71. Сообщение от Аноним (-), 26-Апр-13, 22:40	+/–
>> форкать не выйдет :) > 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).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

72. Сообщение от Аноним (-), 26-Апр-13, 23:49	+4 +/–
> Нет веры человеку у которого на аватарке аниме-фигня. ...сказал человек который вообще с ником "хрен с горы" :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

73. Сообщение от Аноним (-), 26-Апр-13, 23:50	+/–
> Заяц тоже стопсигнал. только маленький еще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

74. Сообщение от Аноним (-), 26-Апр-13, 23:50	+/–
> сфере IT до сих пор делаете? По моим наблюдениям он больше всего занимается тем что бредит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #76, #77

75. Сообщение от nagual (ok), 27-Апр-13, 01:49	+/–
>> Postgresql. PG до сих пор в позиции догоняющего, но так как >> более 20 ядер нужно не всем, то компромис быстрый, но мало >> фичастый (mysql) и медленный, но реализующий то же что и коммерческие >> базы (PG) для многих свежих проектов смещается в сторону PG. > Про быстрый mysql поржал. Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #175

76. Сообщение от бедный буратино (ok), 27-Апр-13, 02:18	+/–
> По моим наблюдениям он больше всего занимается тем что бредит. Вините в этом свой узкий кругозор. Когда рамки слишком узкие, а вещи, для понимания которых требуется и понимания специфики, и общая эрудиция - непонятны, тогда это просто узкий кругозор и недостаточное развитие. Но без этого было бы слишком скучно, слишком банально и слишком мало путей для качественного роста. Если в двух словах, вы не понимаете умные вещи потому, что это умные вещи. Потому что моё наблюдение подсказывает, что речь подавляющего большинства персонажей здесь состоит ТОЛЬКО из шаблонов и стереотипов, где думать не надо вообще, а общая эрудиция связана с мааахонькой книжечкой, полной, вот тут уж истинно, бреда. Работайте над собой. А надо мной не надо, надо мной уже поработали: http://pic.51t.ru/bur.jpg
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

77. Сообщение от бедный буратино (ok), 27-Апр-13, 02:27	–3 +/–
> По моим наблюдениям он больше всего занимается тем что бредит. Можно, конечно, сказать, что они счастливы в этом узком мирке, но это же неправда. Они злы, как собаки, на каждого встречного кидаются, весь свой арсенал гадостей демонстрируют при первой же возможности. Такое ощущение, что тут собралось не сообщество, а одни неудачники, которые каждого первого хотят обвинить во всех своих неудачах. ps. НО ПРИШЁЛ БУРАТИНО... :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #103

78. Сообщение от Аноним (-), 27-Апр-13, 02:51	+1 +/–
> Про быстрый mysql поржал. Ахтунг, лошади на опеннете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

79. Сообщение от Онаним (?), 27-Апр-13, 05:02	+/–
А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при этом очень редки)? Полезная штука?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #85

80. Сообщение от Аноним (-), 27-Апр-13, 05:07	+/–
Нет используй в таком случае InnoDB. TokuDB это типа хранилища для архивов или аналитики, где преобладает запись. TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую то аналитическую систему сбора
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #88

81. Сообщение от sauron (??), 27-Апр-13, 06:28	+/–
> Zabbix написан и заточен под mysql. Если вы не эксперт постгре, я > бы не рекомендовал в принципе экспериментировать. Попытки завести заббикс на других > базах вынудили меня в конечном итоге вернуться к mysql для заббикса. ЛОЛ ШТО? Это как же он так внезапно стал заточен под MySQL? Я вот там никаких оптимизаций под него не видел. Никаким особенным экспертом там быть не надо достаточно сделать оптимизацию под сервер
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #84

82. Сообщение от Evgueni (?), 27-Апр-13, 06:38	+1 +/–
Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине: наличие версии под ОС Windows. Всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #83, #89

83. Сообщение от бедный буратино (ok), 27-Апр-13, 07:07	+/–
> Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине: > наличие версии под ОС Windows. Всё. Скорее даже набора "юный сайтостроитель.exe", который было легко развернуть. MS Visual InterDev был страшен, ужасен, невнятен, а юный сайтостроитель.exe внёс частичку невиданного доселе удобства - юниксвея, плейнтекста и быстрой разработки безо всякой мышиной возни. Да ещё без кряка.exe
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

84. Сообщение от anonymous (??), 27-Апр-13, 08:57	+/–
А это не в контексте оптимизаций под mysql, а того, насколько криво написано под postgre =)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #102

85. Сообщение от AlexAT (ok), 27-Апр-13, 09:33	+/–
> А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при > этом очень редки)? Полезная штука? Если у вас disk-bound workload - да. Структура индексов у TokuDB очень хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие, не привносящее диких тормозов, как у InnoDB. Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #86, #87, #112

86. Сообщение от Аноним (-), 27-Апр-13, 09:40	+/–
>>> Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет. в badoo СУБД на одних php скриптах :D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85

87. Сообщение от Аноним (-), 27-Апр-13, 09:43	+1 +/–
>> А что если у меня просто таблицы и выборки огромные (инсерты/апдейты при >> этом очень редки)? Полезная штука? > Если у вас disk-bound workload - да. Структура индексов у TokuDB очень > хорошо помогает огромным выборкам из миллионов строк. Плюс очень эффективное сжатие, > не привносящее диких тормозов, как у InnoDB. > Для CPU-bound workload бесполезна. Впрочем, там ни один движок уже не поможет. Один из очевидных плюсов очень мало настроек, в отличии от пары сотен тонких настроек innodb
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #90, #149

88. Сообщение от AlexAT (ok), 27-Апр-13, 09:44	+1 +/–
> TokuDB это типа хранилища для архивов или аналитики, где преобладает запись. > TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую > то аналитическую систему сбора Неправда. Она в целом хорошо справляется не только с записью, но и увеличивает параллелизм + несколько оптимизирует тяжелые выборки за счет структур на диске. Плюс сильная компрессия, которая позволяет балансировать между disk-bound и CPU-bound. А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column add/delete без остановки операций и блокировки таблицы. Впервые начали использовать TokuDB только из-за этого - потому, что новая аналитика постоянно требовала новых индексов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #180, #201

89. Сообщение от AlexAT (ok), 27-Апр-13, 09:45	+/–
> Есть мнение, что проекты тогда выстреливали на MySQL исключительно по одной причине: > наличие версии под ОС Windows. Всё. И много проектов под Win/MySQL вы знаете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #91

90. Сообщение от AlexAT (ok), 27-Апр-13, 09:46	+/–
> Один из очевидных плюсов очень мало настроек, в отличии от пары сотен > тонких настроек innodb Да, кстати. Очень универсальный двиг, работающий практически "из коробки".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

91. Сообщение от angra (ok), 27-Апр-13, 10:14	+1 +/–
Почти все пыхеры, с которыми я сталкивался, сидят под виндой, под ней же и разрабатывают, после чего заливают на линуксовый сервер по ftp(самые продвинутые про svn знают). Так что многие проекты работают под линуксом, но пишутся под виндой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #92

92. Сообщение от AlexAT (ok), 27-Апр-13, 10:22	+/–
> Почти все пыхеры, с которыми я сталкивался, сидят под виндой, под ней > же и разрабатывают, после чего заливают на линуксовый сервер по ftp(самые > продвинутые про svn знают). Так что многие проекты работают под линуксом, > но пишутся под виндой. Не совсем понимаю - что в целом в этом плохого? Если специфика приложения и языка позволяет вести разработку на одной платформе, а потом легко перенести на другую - это не минус, а огромный плюс. Тем более что "проекты работают под Linux". Т.е. это не Win-ориентированные проекты. Я например тоже веду почти весь dev на PHP под виндой - ибо PHPEd есть только под винду, а это одна из лучших IDE. Но это не значит, что то, что я разрабатываю, на винду ориентировано, и вообще на винде запустится :) Все тестирование и вся отладка личного проекта идут по SSH на линуховом сервере. Причем очень-очень специфичном, с модифицированным ядром и самописными модулями. На работе - суть та же. На десктопе винда, а вся разработка (и не только на PHP) - под Linux. Т.е. кесарю кесарево...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #96, #98, #99

93. Сообщение от aurved (?), 27-Апр-13, 11:27	–1 +/–
не знаю как насчет самой большой и нагруженной, но наверно имелось в виду Skype
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #94, #95

94. Сообщение от AlexAT (ok), 27-Апр-13, 11:40	+/–
> не знаю как насчет самой большой и нагруженной, но наверно имелось в > виду Skype Есть подозрение, что у википедии и фейсбука база куда побольше в плане объема полезных данных и понагруженнее... Ну или тогда давайте сравнивать с гуглом :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

95. Сообщение от Andrey Mitrofanov (?), 27-Апр-13, 11:40	+/–
> не знаю как > в виду Skype Микросовтофаг попалился. google://самая большая БД и поговорил с хабрафагом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

96. Сообщение от бедный буратино (ok), 27-Апр-13, 11:42	+/–
> Я например тоже веду почти весь dev на PHP под виндой - ибо PHPEd есть только под винду, а это одна из лучших IDE. Ваше мнение очень важно для нас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #97

97. Сообщение от AlexAT (ok), 27-Апр-13, 11:43	+/–
> Ваше мнение очень важно для нас. Аналогично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

98. Сообщение от кверти (ok), 27-Апр-13, 12:45	+/–
>Не совсем понимаю - что в целом в этом плохого? топ менеджер компании компании БМВ ездит на мерсе, что тут плохого? ну кроме того, что работать он будет там недолго...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #100

99. Сообщение от angra (ok), 27-Апр-13, 13:59	+/–
Вы уже забыли свой вопрос? Напоминаю: >И много проектов под Win/MySQL вы знаете? Или увидели слово "пыхер" и, забыв обо всем, бросились на защиту любимого языка? Не стоит утруждаться, мне в общем-то без разницы под какой ОС пишут пыхеры, хватает того, что они умудряются писать код, который работает под apache, но не под php-fpm или fcgi.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #101

100. Сообщение от AlexAT (ok), 27-Апр-13, 14:02	+/–
> топ менеджер компании компании БМВ ездит на мерсе, что тут плохого? ну > кроме того, что работать он будет там недолго... Уверены? Это не россия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

101. Сообщение от AlexAT (ok), 27-Апр-13, 14:03	+/–
> Вы уже забыли свой вопрос? Напоминаю: >>И много проектов под Win/MySQL вы знаете? Повторяю вопрос еще раз для особо тупых/упертых: много ли проектов __ПОД WIN/MYSQL__ вы знаете? То, что озвучено выше - никакого отношения к проектам под Win/MySQL не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99 Ответы: #104

102. Сообщение от sauron (??), 27-Апр-13, 16:58	+/–
> А это не в контексте оптимизаций под mysql, а того, насколько криво > написано под postgre =) Вы там выдыхайте иногда. Я вообще в код ходил и смотрел. Там разницы особой нет. В том то и дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #106

103. Сообщение от AlexAT (ok), 27-Апр-13, 19:39	+/–
>>> ps. НО ПРИШЁЛ БУРАТИНО... :) И показал на своём сравнительном примере, что сообщество, в общем-то, милые и прекрасные люди...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

104. Сообщение от angra (ok), 27-Апр-13, 20:06	+/–
Я повторюсь, мне не сложно. Продакшен под Linux/MySQL, но разработка идет под Win/MySQL. Причем выбор между win и linux не связан с мускулом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

105. Сообщение от Аноним (-), 28-Апр-13, 06:32	+/–
Для перконы собрали двоичные и бинарные http://www.mysqlperformanceblog.com/2013/04/24/percona-serve.../
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #110

106. Сообщение от Аноним (-), 28-Апр-13, 17:13	+1 +/–
просто вы не видите этой разницы потому что например не знаете как зависят нагрузка на сервер и администрирование от количества insert/update/delete. то что хорошо для mysql плохо для postgres и наоборот. потому что это принципиально разные субд с разными подсистемами хранения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #108

107. Сообщение от Аноним (-), 28-Апр-13, 17:23	+/–
> Почему выстрелили web проекты на mysql 3.23 а не на постгресе? > Потому что mysql быстро развивался и был простым в использовании. основная причина - потому что постгрес практически невозможно использовать на sharing hosting.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

108. Сообщение от sauron (??), 28-Апр-13, 18:20	+1 +/–
Конечно конечно. Товарищ если вы начали оптимизировать свой софт под поведение РСУБД это очень плохой звоночек. А именно что или вы плохо спроектировали софт или же выбрали плохую РСУБД. И да замечу, что оптимизировать под количество операций записи надо под MySQL исключительно в силу того что ему плохеет от их большого количества. В случае PostgreSQL при той же нагрузке этого не наблюдается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #109

109. Сообщение от AlexAT (ok), 28-Апр-13, 18:50	+/–
> Конечно конечно. Товарищ если вы начали оптимизировать свой софт под поведение РСУБД > это очень плохой звоночек. А если не начали - то это очень плохой звоночек...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #120

110. Сообщение от ryoken (?), 28-Апр-13, 19:40	+/–
> собрали двоичные и бинарные Для тупых поясните... это уже не одно и тоже?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

111. Сообщение от yuris (??), 28-Апр-13, 22:07	–2 +/–
Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы всё равно упираются в 99% случаев в разбор SQL и составление планов выполнения запросов? Эти все улучшения будут иметь смысл только при очень простых запросах на больших объёмах данных, что в майсиквеле не так уж часто встречается. P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет вогнать в ступор любую базу с любым двиглом.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #113, #115, #118

112. Сообщение от Аноним (-), 28-Апр-13, 22:20	+/–
Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #116

113. Сообщение от Аноним (-), 28-Апр-13, 22:24	+/–
Квантовый двигатель ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

114. Сообщение от XoRe (ok), 28-Апр-13, 22:38	+/–
>> С этим никто не спорит. >> Мы обсуждаем вменяемую среду использования. > Проблема в том, что про "тормозной MySQL" истерят как раз в основном > пейсатели, прочитавшие книжку "MS(My,нужное вписать)SQL для чайников", и реально пишущие > крэп. При этом MySQL какбэ и не виноват :) Что же это вы всех сразу в "пейсатели-чайники" записали. Мне кажется, подход "если ругается на mysql, значит нуб" несколько странен. Я думаю, люди могут привести вполне конкретные аргументы. P.S. По своему опыту я заметил, что проблемы начинаются при размерах базы от 500 гб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #117

115. Сообщение от AlexAT (ok), 28-Апр-13, 22:39	+/–
> Неясно какой смысл в незначительном улучшении движка на некоторых операциях, если запросы > всё равно упираются в 99% случаев в разбор SQL и составление > планов выполнения запросов? Эти все улучшения будут иметь смысл только при > очень простых запросах на больших объёмах данных, что в майсиквеле не > так уж часто встречается. ЧЕГО? На огромных базах ворклоуд либо cpu-bound, либо disk-bound. TokuDB сильно упрощает жизнь для disk-bound. "Разбор SQL и составление планов" на таких базах - 0.000001% времени, а то и меньше. > P.S. Ирония в том, что криво составленный запрос, сгенерённый индусским кодом сможет > вогнать в ступор любую базу с любым двиглом. А вот это верно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

116. Сообщение от AlexAT (ok), 28-Апр-13, 22:41	+/–
> Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom Это если CPU-bound из-за сложных выражений. А если он возник из-за объема данных / сортировки, то таким образом только шина в полку уложится, и результат будет отрицательный. Но вот для массивного REGEXP / LIKE по базе вполне себе интересно, если конечно умеет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #119

117. Сообщение от AlexAT (ok), 28-Апр-13, 22:43	+/–
> P.S. > По своему опыту я заметил, что проблемы начинаются при размерах базы от > 500 гб. С такими базами и подходы уже специфичные. Там де факто не важно - мускул или не мускул - там важно правильное построение доступа к базе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #114 Ответы: #129

118. Сообщение от Аноним (-), 28-Апр-13, 23:13	+/–
> запросы всё равно упираются в 99% случаев в разбор SQL Откройте для себя prepared statement уже наконец. > при очень простых запросах на больших объёмах данных, что в майсиквеле не > так уж часто встречается. Как раз в MySQL оно только и встречается. Для сложных запросов там планировщика можно считать что просто нет, по сравнению с PostgreSQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #158, #213

119. Сообщение от Аноним (-), 28-Апр-13, 23:18	+/–
>> Для CPU-bound помогает в Постгресе GPU задействовать - https://wiki.postgresql.org/wiki/PGStrom > Это если CPU-bound из-за сложных выражений. А если он возник из-за объема > данных / сортировки, то таким образом только шина в полку уложится, > и результат будет отрицательный. Ну это и не CPU-bound а bus bound таки. > Но вот для массивного REGEXP / LIKE по базе вполне себе интересно, > если конечно умеет. Не надо бы базе LIKE поручать, нехорошо это, есть же более другие средства, хотя бы и встроенные типа FTS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116 Ответы: #121

120. Сообщение от sauron (??), 29-Апр-13, 06:17	+/–
> А если не начали - то это очень плохой звоночек... Оптимизировать под конкретную реализацию РСУБД на начальной стадии проектирования просто не имеет смысла. Если же это надо делать, то лучше подумать о смене РСУБД. А не под тем как под нее заточить свой софт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #122

121. Сообщение от AlexAT (ok), 29-Апр-13, 07:27	+/–
> Ну это и не CPU-bound а bus bound таки. Будет. Что еще хуже, чем CPU bound. > Не надо бы базе LIKE поручать, нехорошо это, есть же более другие > средства, хотя бы и встроенные типа FTS. Именно так. Просто помимо сложных выражений я не могу представить себе задачу БД, которую можно поручить GPU. Упрётся в шину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #156, #199

122. Сообщение от AlexAT (ok), 29-Апр-13, 07:29	+/–
> Оптимизировать под конкретную реализацию РСУБД на начальной стадии проектирования просто > не имеет смысла. Если же это надо делать, то лучше подумать > о смене РСУБД. А не под тем как под нее заточить > свой софт. Имеет. Потому что переоптимизировать всё на конечной стадии может уже и не получиться. Хороший пример - Zabbix. Одинаково хреново работает на всех СУБД, и очень тяжело допилить под конкретный двиг. Когда допиливаешь - такое ощущение, что ребята вообще абстрагировались от реаль^W оптимизации, и достигли нирваны в процессе написания. Сохранить модульность при оптимизации под двиг - та еще задача. С другой стороны, законченному решению редко нужна поддержка более одной СУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #123

123. Сообщение от sauron (??), 29-Апр-13, 07:39	+/–
> Имеет. Потому что переоптимизировать всё на конечной стадии может уже и не > получиться. Хороший пример - Zabbix. Не имеет. Стандарт SQL-92 и общие концепции не зря придумывали. > Одинаково хреново работает на всех СУБД, и очень тяжело допилить под конкретный двиг. > Когда допиливаешь - такое ощущение, что ребята вообще абстрагировались от реаль^W > оптимизации, и достигли нирваны > в процессе написания. Он одинаково хреново работает на всех СУБД потому что чуваки которые его писали, про что такое РСУБД не сном ни духом. Я в код его между прочим заглядывал. А MySQL существенно чувствительнее к таким ошибкам чем PostgreSQL. Oracle как раз является лидером среди РСУБД потому что еще менее чувствителен к таким ошибкам. > Сохранить модульность при оптимизации под двиг - та еще задача. С другой > стороны, законченному решению редко нужна поддержка более одной СУБД. В случае zabbix вот как раз проблемы не было. Там нет такой суровой необходимости оптимизировать под конкретную РСУБД. Надо знать про то как они работают и писать с учетом этих особенностей. К примеру начать уже использовать транзакции при записи данных. А они там даже не ночевали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #124

124. Сообщение от AlexAT (ok), 29-Апр-13, 08:16	+/–
> Не имеет. Стандарт SQL-92 и общие концепции не зря придумывали. Угу. Вот только есть особенности, которых этот стандарт совершенно не учитывает. Например, собственно, механику работы движка, которую он никак не описывает. Поэтому в общем случае голого стандарта достаточно только для микронных баз и примитивных паттернов доступа. Для всего остального начинается специфика. > Он одинаково хреново работает на всех СУБД потому что чуваки которые его > писали, про что такое РСУБД не сном ни духом. Да нет. Написано в целом достаточно нормально, вот только... как раз таки абстракция от движка БД не позволила использовать специфику. В итоге приходится пилить руками. > Я в код его между прочим заглядывал. Заглядывать - мало. Недавно этот код по сути ныне до ума довел, во всяком случае самые жесткие затыки в нашей боевой инсталляции исчезли. Правда патчем это толкать в оригинал бессмысленно, поскольку оно теперь MySQL-only. > они работают и писать с учетом этих особенностей. К примеру начать > уже использовать транзакции при записи данных. А они там даже не > ночевали. Транзакции там только усугубят ситуацию. Основная проблема внутри заббикса - в "универсальных" удобных коду выборках, не учитывающих особенности движка. Причем в самых-самых критических местах. После переписывания десятка оных всё становится на места. Если кто бьется до сих пор - даю наводку: в первую голову смотрите выборки, совмещающие functions и triggers. Там наибольшая загвоздка с оптимизацией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #125

125. Сообщение от sauron (??), 29-Апр-13, 08:22	+/–
> Угу. Вот только есть особенности, которых этот стандарт совершенно не учитывает. Например, > собственно, механику работы движка, которую он никак не описывает. И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо. > Поэтому в общем случае голого стандарта достаточно только для микронных баз и > примитивных паттернов доступа. Для всего остального начинается специфика. Пример такой специфики в студию. > Да нет. Написано в целом достаточно нормально, вот только... как раз таки > абстракция от движка БД не позволила использовать специфику. В итоге приходится > пилить руками. Вот не надо ля-ля. Код там ужасен. Я уж молчу что переключение между СУБД производится на стадии компиляции. Прям у нас движков абстракции под C нет. Тот же libdbi можно взять. > Заглядывать - мало. Недавно этот код по сути ныне до ума довел, > во всяком случае самые жесткие затыки в нашей боевой инсталляции исчезли. > Правда патчем это толкать в оригинал бессмысленно, поскольку оно теперь MySQL-only. Это говорит о том что это хреновое решение. Фактически для исправления проблем у zabbix требуется запилить там нормальную работу с транзакциями. И это худо бедно начнет нормально работать в том числе и на MySQL. > Транзакции там только усугубят ситуацию. Основная проблема внутри заббикса - в "универсальных" > удобных коду выборках, не учитывающих особенности движка. Причем в самых-самых критических > местах. После переписывания десятка оных всё становится на места. У zabbix основная проблема плохой работы на MySQL это массированные атомарные записи в базу. Если это переделать на транзакции станет заметно лучше. То что они читают все без разбора меньшее зло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124 Ответы: #126

126. Сообщение от AlexAT (ok), 29-Апр-13, 11:20	+/–
>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо. Несколько примеров: - Использование LIMIT x,y (нет в MSSQL, к примеру) - Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется с подзапросами) - Для TokuDB - создание всех необходимых индексов, без оглядки на скорость модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс даже при обилии модификаций - Правильное партиционирование таблиц - Приведение типов столбцов в связках (в MySQL с этим очень строго) - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора (специфично для каждого движка) >> Поэтому в общем случае голого стандарта достаточно только для микронных баз и >> примитивных паттернов доступа. Для всего остального начинается специфика. > Пример такой специфики в студию. Пример специфики - например, избавление от full scan / больших range scan по мере возможности. В принципе актуально для любого движка. Партиционирование и использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборки и анализа в код (хранимки / клиент), максимизация использования индексов. Использование движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем сканирования). Построение покрывающих индексов. И так далее. > Это говорит о том что это хреновое решение. Предложите лучше для _большой_ сети (>2500 хостов). > Фактически для исправления проблем у zabbix требуется запилить там нормальную работу с транзакциями. И чем это поможет? Только давайте конкретно, без воды: где именно в заббиксе производительности поможет транзакционность? > У zabbix основная проблема плохой работы на MySQL это массированные атомарные записи > в базу. Не встретил даже на InnoDB. А на TokuDB это вообще не проблема. Вот не поверишь - ни разу не встал колом на записи, зато на чтении постоянно вставал колом в огромных range read. Пока не переписал ряд запросов. Основная проблема там - это массированные range scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000 триггеров, причем встает раком...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #127

127. Сообщение от sauron (??), 29-Апр-13, 11:53	+/–
>>> И какие такие критические особенности движка MySQL надо учитывать при разработке под него? Мне вот правда интеренсо. > Несколько примеров: > - Использование LIMIT x,y (нет в MSSQL, к примеру) вообще limit offset поддерживается в том числе и в MySQL и в PostgreSQL и Oracle > - Замена сложных JOIN ради выборки единичных элементов (постоянно вижу такое в > ногами писанных энтерпрайзных поделках) на подзапросы (MySQL очень неплохо справляется > с подзапросами) explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в MySQL работают быстрее подзапросов. > - Для TokuDB - создание всех необходимых индексов, без оглядки на скорость > модификации, если не превалирует запись - TokuDB очень шустро обновляет индекс > даже при обилии модификаций Это вообще специфика движка и к приложению никакого отношения не имеет. > - Правильное партиционирование таблиц Это тоже не имеет никакого отношения к приложению > - Приведение типов столбцов в связках (в MySQL с этим очень строго) Это уже вопросы к разработчикам. > - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора Это тоже не имеет никакого отношения к приложению. > Пример специфики - например, избавление от full scan / больших range scan > по мере возможности. В принципе актуально для любого движка. Партиционирование и > использование оного для оптового удаления устаревающих записей. Вынос сложной логики выборки Это точно так же делается на PosgtreSQL различия минимальны. > и анализа в код (хранимки / клиент), максимизация использования индексов. Использование > движка, позволяющего быстро обновлять множество индексов в многогигабайтных базах (BTree > отлетает сразу же) - в частности того же TokuDB. Сегментация таблиц > для уменьшения числа отбираемых строк (лучше усложнить запрос, чем увеличить объем > сканирования). Построение покрывающих индексов. И так далее. Это может делятся уже и после того как приложение запущено и это вот как раз при разработке вообще можно не учитывать. > Предложите лучше для _большой_ сети (>2500 хостов). К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно не мешает ему иметь ужасный код в основе ;) > И чем это поможет? Только давайте конкретно, без воды: где именно в > заббиксе производительности поможет транзакционность? Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL. У нас чинилось переходом на PostgreSQL, где с записью все лучше. > Не встретил даже на InnoDB. А на TokuDB это вообще не проблема. TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как работа housekeeper приводила к стоянию колом MySQL сервера. Да и в целом нагрузка на сервер была больше. > Вот не поверишь - ни разу не встал колом на записи, > зато на чтении постоянно вставал колом в огромных range read. Вот увы не поверю. Основная проблема это запись. Которая затем выливается в проблемы при чтении. > Пока не переписал ряд запросов. Основная проблема там - это массированные range > scan по разрастающимся таблицам. Заметно только после ~30000 item'ов и ~10000 > триггеров, причем встает раком... Основная проблема криворукость писателей zabbix которые часто даже в explain не удосуживаются посмотреть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #130

128. Сообщение от Andrey Mitrofanov (?), 29-Апр-13, 12:47	+/–
> А для статистики - не скажете число итемов/триггеров? Свой офтопик про Zabbix + PgSQL я вынес из темы про TokuDB. http://www.opennet.dev/openforum/vsluhforumID13/848.html 2All: Присоединяйтесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

129. Сообщение от XoRe (ok), 29-Апр-13, 15:11	+/–
> построение доступа к базе Честно говоря, не понял) А вообще в том и дело, что pgsql показывает лучшие характеристики на таких базах. А на небольших базах до 10GB, согласен, mysql за счет простоты (и запихивания всей базы в ОЗУ) будет бегать очень резво.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #131, #157

130. Сообщение от AlexAT (ok), 29-Апр-13, 20:38	+/–
> вообще limit offset поддерживается в том числе и в MySQL и в > PostgreSQL и Oracle В MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL, и в PGSQL, и в Oracle. > explain надо сначала смотреть, плюс думать как переписать. Правильно написанные join в > MySQL работают быстрее подзапросов. Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые. > Это вообще специфика движка и к приложению никакого отношения не имеет. Мы же о специфике и говорили? Ее надо учитывать, если хочется получить результат выше среднего в сложных условиях и по пересеченной местности. Если средний или около того - то сойдёт что угодно. >> - Правильное партиционирование таблиц > Это тоже не имеет никакого отношения к приложению Имеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне быть написаны с учётом оного. >> - Приведение типов столбцов в связках (в MySQL с этим очень строго) > Это уже вопросы к разработчикам. Именно. В MSSQL не так строго. Но это - специфика. >> - Форсирование и игнорирование индексов в определенных запросах для подстройки оптимизатора > Это тоже не имеет никакого отношения к приложению. Имеет, причём 100%. > Это может делятся уже и после того как приложение запущено и это > вот как раз при разработке вообще можно не учитывать. Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со стабильностью, увы. >> Предложите лучше для _большой_ сети (>2500 хостов). > К сожалению из открытого zabbix по фичам лучше всего. Но это совершенно > не мешает ему иметь ужасный код в основе ;) Если он по фичам лучше всего - то это не "хреновое решение"? Да, оно может и ужасно по коду, но при этом оно минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже, в общем, не блещут - ресурсов им надо немеряно. > Запись значений. Именно это вызывает большие проблемы с производительностью в случае MySQL. Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да и в InnoDB их нет, если не злоупотреблять столбцами и индексами, и сознательно строить базу с максимальным обходом блокировок. > У нас чинилось переходом на PostgreSQL, где с записью все лучше. У нас все проще - после переписывания нескольких запросов всё встало на места с чтением. А с записью проблем не было и нет. Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать не буду. > TokuDB согласен эту проблему решает. А вот на InnoDB я наблюдал как > работа housekeeper приводила к стоянию колом MySQL сервера. Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки обрабатывают по 1 элементу за 1 раз, хотя можно было оптом обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились, может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел - но его вообще в статистике не видно. > Вот увы не поверю. Основная проблема это запись. У нас ситуация иная. Колом вставало именно чтение, причем записи в этот момент не было. Несколько переписанных запросов - и больше колом не встает ничего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127 Ответы: #132

131. Сообщение от AlexAT (ok), 29-Апр-13, 21:05	+/–
> А на небольших базах до 10GB, согласен, mysql за счет простоты (и > запихивания всей базы в ОЗУ) будет бегать очень резво. А что я делаю не так с моим сжатым объемом базы в TokuDB в 246 Гб (~800 Гб несжатых)? Аналитика бегает шустро, нареканий нет, на сервере (виртуалка) 8Gb RAM :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

132. Сообщение от sauron (??), 29-Апр-13, 21:13	+/–
> В MSSQL - нет. Всё, универсальности уже нет. Специфика. И в MySQL, > и в PGSQL, и в Oracle. MSSQL - это своя атмосфера. В остальных есть. > Не всегда. Есть примеры, но приводить лениво - ибо они объёмистые. Хорошо в большинстве случаев. > Мы же о специфике и говорили? Ее надо учитывать, если хочется получить > результат выше среднего в сложных условиях и по пересеченной местности. Если > средний или около того - то сойдёт что угодно. Все вами перечисленное может быть уже сделано по месту. Лучше уделить больше внимания проектированию самой базы и архитектуры программы. > Имеет, поскольку само приложение должно знать о партиционировании, и запросы могут вполне > быть написаны с учётом оного. Вот приложение про партицирование знать особо ничего не должно. Его просто делают под типичные запросы. > Имеет, причём 100%. Не имеет так-как может быть добавлено после разработки приложения. И указывать в приложении использовать вот этот индекс не нужно и часто вообще вредно. Из-за этого к примеру нет хинтов в PostgreSQL. > Сделать, чтобы потом переделывать в боевой эксплуатации - не важно, апгрейдом или > как ещё, в любом случае шанс ошибки возрастает. Подход, несовместимый со > стабильностью, увы. Вполне совместимый если у вас нормально спроектирована СУБД. > Если он по фичам лучше всего - то это не "хреновое решение"? Хреновое, так-как можно сделать и оптимальнее. > Да, оно может и ужасно по коду, но при этом оно > минимально "хреновое" из всех доступных. Остальные еще хуже. Большые "энтерпрайзные" тоже, > в общем, не блещут - ресурсов им надо немеряно. С ПО вообще все сложно. Отличные приложения встречаются, но редко. > Не столкнулись на практике. В TokuDB проблем с записью особых нет. Да > и в InnoDB их нет, если не злоупотреблять столбцами и индексами, > и сознательно строить базу с максимальным обходом блокировок. В TokuDB не будет. А вот в InnoDB сталкивался, правда это было года три назад, там еще у InnoDB были серьезные проблемы с масштабируемостью. > Кстати, можно размер Вашей инсталляции (итемы/триггеры)? Просто для сравнения, комментировать > не буду. Да где-то как у вас. > Это не из-за какой-либо проблемы в MySQL. Это из-за того, что ребятки > обрабатывают по 1 элементу за 1 раз, хотя можно было оптом > обработать пару десятков тысяч. В 2.0 вроде-бы как-то с этим справились, > может действительно оптовую обработку сделали. Детально HK в 2.0 не смотрел > - но его вообще в статистике не видно. Да нет удаляли они уже тогда пачками. Но это плохо сказывалось на работу записи. > У нас ситуация иная. Колом вставало именно чтение, причем записи в этот > момент не было. Несколько переписанных запросов - и больше колом не > встает ничего. Ну черт знает. Я только могу резюмировать, что после перехода на PostgreSQL про прыганья вокруг СУБД шоб работало я забыл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130 Ответы: #133

133. Сообщение от AlexAT (ok), 29-Апр-13, 21:48	+/–
> Из-за этого к примеру нет хинтов в PostgreSQL. А зря. Иногда единственный способ обойти оптимизатор, не лезя в код собственно движка СУБД. Иногда - нужный, поскольку я например местами куда лучше эвристики оптимизатора знаю, как лучше тот или иной запрос сгрести с диска :) А стохастика в MSSQL вообще убивает xD > В TokuDB не будет. А вот в InnoDB сталкивался, правда это было > года три назад, там еще у InnoDB были серьезные проблемы с > масштабируемостью. Ну да, три года назад - и я с Вами согласился бы :) > Да нет удаляли они уже тогда пачками. Но это плохо сказывалось на > работу записи. Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за этого года два назад на заббих было положено ровно на год :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #134

134. Сообщение от sauron (??), 30-Апр-13, 06:18	+/–
> А зря. Иногда единственный способ обойти оптимизатор, не лезя в код собственно > движка СУБД. Иногда - нужный, поскольку я например местами куда лучше > эвристики оптимизатора знаю, как лучше тот или иной запрос сгрести с > диска :) А стохастика в MSSQL вообще убивает xD Чуваки из PostgreSQL против хинтов. Они говорят что если у вас оптимизатор плохо строит план, то это или бага или у вас ошибка при проектировании. > Ну да, три года назад - и я с Вами согласился бы Вполне может быть что в крайних версиях MySQL и MariaDB это пофиксили. Но там еще много других претензий есть, так что я пока лучше PostgreSQL буду использовать и не знать головной боли. > Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом > DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за > этого года два назад на заббих было положено ровно на год > :) Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #133 Ответы: #135, #136

135. Сообщение от pavel_simple (ok), 30-Апр-13, 07:33	+/–
>[оверквотинг удален] > при проектировании. >> Ну да, три года назад - и я с Вами согласился бы > Вполне может быть что в крайних версиях MySQL и MariaDB это пофиксили. > Но там еще много других претензий есть, так что я пока > лучше PostgreSQL буду использовать и не знать головной боли. >> Ни, точно не пачками. SELECT ... WHERE ItemId = ... , потом >> DELETE WHERE ItemId = AND ... Это как сейчас помню, из-за >> этого года два назад на заббих было положено ровно на год >> :) > Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций. подобие хинтов таки появилось http://habrahabr.ru/post/169751/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #137

136. Сообщение от AlexAT (ok), 30-Апр-13, 08:06	+1 +/–
> Чуваки из PostgreSQL против хинтов. Они говорят что если у вас оптимизатор > плохо строит план, то это или бага или у вас ошибка > при проектировании. Вот за что и не люблю академические поделки - так это за это самое "а баба яга против". Во-первых - идеальных оптимизаторов не бывает, баги есть у всех, угу. Во-вторых - в случае БД (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику, призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и специфику конкретных приложений могут не понять. Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По двум причинам: 1. Если я точно знаю, что мой набор данных быстрее соберется именно вот с этого вот боку, а иные варианты проектирования - еще хуже в обозримом круге вариантов - то зачем мне все усилия оптимизатора по приоритизации таблиц и индексов, к примеру? Тем более, что он часто ошибается. 2. Если в оптимизаторе всё-таки встретилась бага. Или фича (см. выше про эмпирику). Ждать месяц, пока эту багу закроют - накладно. Могут и вообще закрывать отказаться - ибо в ущерб другим ворклоудам. Самому патчить - в движок БД своими руками, в одиночку, лезть страшновато, и, опять же - накладно. Исключения быть могут, но и причина должна быть куда более веской. И если в некой СУБД этого делать не хотят по "академическим" мотивам, навязывая свой паттерн мышления - я просто не буду применять эту СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито. Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент. > Там уже транзакцию хотя бы начали ставить это приводит к оптимизации операций. Если честно - в заббиксе транзакции ничем не помогут производительности. Это так, попутный вывод на основе анализа его запросов при оптимизации. Наоборот - могут усугубить - за счет длительного блокирования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #138, #147, #173

137. Сообщение от AlexAT (ok), 30-Апр-13, 08:11	+/–
> подобие хинтов таки появилось > http://habrahabr.ru/post/169751/ О как. Видать кого-то здорово припёрло как раз тем, о чём я ниже в #136 написал. Жалко только, что костыль - де-факто - unsupported модуль. Его надо в основную ветку проталкивать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135

138. Сообщение от sauron (??), 30-Апр-13, 08:16	+/–
> Вот за что и не люблю академические поделки - так это за > это самое "а баба яга против". Во-первых - идеальных оптимизаторов не > бывает, баги есть у всех, угу. Во-вторых - в случае БД > (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику, > призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением > данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор > плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и > специфику конкретных приложений могут не понять. А специфика конкретных приложений затачивается уже указанием индексов. Если вот это надо быстро то стоит делать материализированный виев. > Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По > двум причинам: > 1. Если я точно знаю, что мой набор данных быстрее соберется именно > вот с этого вот боку, а иные варианты проектирования - еще > хуже в обозримом круге вариантов - то зачем мне все усилия > оптимизатора по приоритизации таблиц и индексов, к примеру? Тем более, что > он часто ошибается. В MySQL часто. В PostgreSQL существенно реже. > И если в некой СУБД этого делать не хотят по "академическим" мотивам, > навязывая свой паттерн мышления - я просто не буду применять эту > СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито. > Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент. Да сколько угодно. Проблема только в том что MySQL все еще хуже по фичам чем PostgreSQL ивсе так же плохо держит нагрузку. > Если честно - в заббиксе транзакции ничем не помогут производительности. Это так, > попутный вывод на основе анализа его запросов при оптимизации. Наоборот - > могут усугубить - за счет длительного блокирования. Какого еще длительного блокирования? Ну пишу я себе там в потоке ни у ладно. Блокировка таблицы в MySQL возникает только при самом высоком уровне изоляции или при применении MyISAM. А вот его применять пожалуй не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #139

139. Сообщение от AlexAT (ok), 30-Апр-13, 08:21	+/–
> А специфика конкретных приложений затачивается уже указанием индексов. Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, индекс, и ничего кроме" - очень даже нужны хинты/форсирование. > В MySQL часто. В PostgreSQL существенно реже. "Часто", "реже" - это всё относительно, и зависит от приложения / структуры БД. У меня есть большая табличка, аналитическая выборка из которой ломает шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что все три берут самый очевидный вариант плана запроса, который совершенно неоптимален с точки зрения доступа к диску. И переструктурировать ее некуда - там явных внутренних связей просто нет, + символьные поля переменной длины. С форсированием конкретного индекса (раза в два больше строк в скане, зато на порядок меньше время выполнения) же вся аналитика бегает очень неплохо. > Да сколько угодно. Проблема только в том что MySQL все еще хуже > по фичам чем PostgreSQL ивсе так же плохо держит нагрузку. Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах вижу - ситуация прямо обратная. > Какого еще длительного блокирования? Ну пишу я себе там в потоке ни > у ладно. Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же части индекса - уже не пройдут, и будут ждать выполнения твоей транзакции. А до момента COMMIT может пройти много времени. Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи на транзакцию. Например при высоком параллелизме обновления одних и тех же таблиц. Zabbix в его нынешнем виде - как раз тот случай. Хотя - да, его бы переписать с прямой записи в таблицы на каждый чих на очередь обновления - и он нормально бы с транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в этом направлении там уже есть, но пока что не везде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #140

140. Сообщение от sauron (??), 30-Апр-13, 08:34	–1 +/–
> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, > индекс, и ничего кроме" - очень даже нужны хинты/форсирование. Если у вас возникает такая надобность, то надо внимательно посмотреть на свою базу данных. > "Часто", "реже" - это всё относительно, и зависит от приложения / структуры > БД. У меня есть большая табличка, аналитическая выборка из которой ломает > шаблон оптимизатору хоть MySQL, хоть MSSQL, хоть Оракла. Просто потому, что > все три берут самый очевидный вариант плана запроса, который совершенно неоптимален > с точки зрения доступа к диску. И переструктурировать ее некуда - > там явных внутренних связей просто нет, + символьные поля переменной длины. > С форсированием конкретного индекса (раза в два больше строк в скане, > зато на порядок меньше время выполнения) же вся аналитика бегает очень > неплохо. А не надо так делать и все будет хорошо. > Тут бы неплохо пруфлинк-таки, потому что из того, что я на форумах > вижу - ситуация прямо обратная. Пруфлинк на что? Что MySQL хуже держит нагрузки? Вы уйдите с форумов про MySQL и сразу найдете. > Когда делаешь START TRANSACTION, и начинаешь писать данные пачками - блокируются части > индекса. Ровно до момента COMMIT. Поэтому параллельные записи, затрагивающие те же > части индекса - уже не пройдут, и будут ждать выполнения твоей > транзакции. А до момента COMMIT может пройти много времени. И? Ну не будет в выборке у меня этих данных и все. > Поэтому иногда выгоднее отсутствие явных транзакций, и выполнение по 1 команде записи > на транзакцию. Например при высоком параллелизме обновления одних и тех же > таблиц. Zabbix в его нынешнем виде - как раз тот случай. И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :) > Хотя - да, его бы переписать с прямой записи в таблицы на > каждый чих на очередь обновления - и он нормально бы с > транзакционностью ужился, и проблем с производительностью стало бы меньше. Подвижки в > этом направлении там уже есть, но пока что не везде. Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #141, #145

141. Сообщение от pavel_simple (ok), 30-Апр-13, 09:08	+/–
>> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, >> индекс, и ничего кроме" - очень даже нужны хинты/форсирование. > Если у вас возникает такая надобность, то надо внимательно посмотреть на свою > базу данных. дело не в базе данyых, дело в том что постгрес использует оптимизатор который работает на т.н. "генетических алгоритмах", это немного из области ИИ, и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ отменяют того, что оптимизатор выдаёт кривой план.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #142, #143

142. Сообщение от pavel_simple (ok), 30-Апр-13, 09:10	+1 +/–
>>> Именно. И если надо обойти оптимизатор и сказать - "вот этот, @#$%ь, >>> индекс, и ничего кроме" - очень даже нужны хинты/форсирование. >> Если у вас возникает такая надобность, то надо внимательно посмотреть на свою >> базу данных. > дело не в базе данyых, дело в том что постгрес использует оптимизатор > который работает на т.н. "генетических алгоритмах", это немного из области ИИ, > и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ > отменяют того, что оптимизатор выдаёт кривой план. P.S. http://www.postgresql.org/docs/8.2/static/geqo-pg-intro.html " 48.3.1. Future Implementation Tasks for PostgreSQL GEQO Work is still needed to improve the genetic algorithm parameter settings. In file src/backend/optimizer/geqo/geqo_main.c, routines gimme_pool_size and gimme_number_generations, we have to find a compromise for the parameter settings to satisfy two competing demands: Optimality of the query plan Computing time At a more basic level, it is not clear that solving query optimization with a GA algorithm designed for TSP is appropriate. In the TSP case, the cost associated with any substring (partial tour) is independent of the rest of the tour, but this is certainly not true for query optimization. Thus it is questionable whether edge recombination crossover is the most effective mutation procedure. " т.е. поле для работы есть. местами обширное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

143. Сообщение от sauron (??), 30-Апр-13, 09:10	+/–
> дело не в базе данyых, дело в том что постгрес использует оптимизатор > который работает на т.н. "генетических алгоритмах", это немного из области ИИ, > и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ > отменяют того, что оптимизатор выдаёт кривой план. Это на сильно не тривиальных выборках бывает и там покрутить можно для изменения поведения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #144

144. Сообщение от pavel_simple (ok), 30-Апр-13, 09:18	+1 +/–
>> дело не в базе данyых, дело в том что постгрес использует оптимизатор >> который работает на т.н. "генетических алгоритмах", это немного из области ИИ, >> и именно поэтому иногда его ошибки алгоритмически совершенно обоснованы, но НЕ >> отменяют того, что оптимизатор выдаёт кривой план. > Это на сильно не тривиальных выборках бывает и там покрутить можно для > изменения поведения. говорю как есть, может у меня конечно чего с руками, НО... мы (втроём) тут как-то раз пытались поправить кривой план, опыт с постресом на больших объёмах у всех ближе к 10 годам.... ммм... так вот неасилили. пришлось дополнительно рихтовать сервер-сайд чтобы зафиксировать логику запроса, разница по времени: или 1.3 мс или 1 мин.15 сек. -- ну т.е. крайне чувствительная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

145. Сообщение от AlexAT (ok), 30-Апр-13, 09:29	+/–
> Если у вас возникает такая надобность, то надо внимательно посмотреть на свою > базу данных. Скорее на оптимизатор, так как хинтинг даёт огромную разницу (минуты -> секунды). Суть в том, что это оптимизатор для помощи приложению, а не приложение для оптимизатора. Соответственно подстраивать нужно оптимизатор. За исключением случаев, когда приложение действительно косое. > А не надо так делать и все будет хорошо. Угу, и аналитика будет ворочаться по 5+ минут вместо 1-2 секунд. Очень хорошо. Я считаю себя несколько умнее оптимизатора в данном вопросе, поскольку мой результат лучше. > И? Ну не будет в выборке у меня этих данных и все. Да нет - не в выборке не будет, а запись встанет колом до завершения блокирующей транзакции. > И в этом случае у MySQL все становится плохо. Хотя и при длинных транзакциях ему тоже плохеет :) И не только MySQL. > Транзакционная запись необходима. Это ускорит работу zabbix ну так лучше с СУБД > работать. Еще раз: как именно ускорит? За счет какой магии? Хотелось бы обоснования, потому что неочевидно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #146

146. Сообщение от sauron (??), 30-Апр-13, 09:43	+/–
> Скорее на оптимизатор, так как хинтинг даёт огромную разницу (минуты -> секунды). > Суть в том, что это оптимизатор для помощи приложению, а не > приложение для оптимизатора. Соответственно подстраивать нужно оптимизатор. За исключением > случаев, когда приложение действительно косое. Чаще бывает случай все же что приложение косое. > Угу, и аналитика будет ворочаться по 5+ минут вместо 1-2 секунд. Очень > хорошо. Я считаю себя несколько умнее оптимизатора в данном вопросе, поскольку > мой результат лучше. Я не спорю что сильно зависит от данных. > Да нет - не в выборке не будет, а запись встанет колом > до завершения блокирующей транзакции. Не встанет если у вас не максимальный уровень изоляции. > И не только MySQL. Ему особенно. То что PostgreSQL переживает даже не подавившись, может вызывать снижение производительности у MySQL. > Еще раз: как именно ускорит? За счет какой магии? Хотелось бы обоснования, > потому что неочевидно. Ускоряется за счет уменьшения накладных расходов. К примеру загрузить 2 тысячи итемов в одной транзакции и 2 тысячи итемов без указания в одной транзакции это две большие разницы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #153

147. Сообщение от arisu (ok), 30-Апр-13, 11:48	+/–
это мне напоминает спичи людей, которые утверждают, что лучше компилятора соптимизируют ассемблер. иногда одни даже правы, но почти никогда в этом смысла нет. а если уж сильно хочется, то всегда можно поправить исходник постгреса, добавив себе нужную фичу. но лучше, конечно, чтобы описаной тобой возможности не было. потому что на одного умного DBA, который выиграет свою 0.1 секунду, будет 100500 идиотов, которые своими «оптимизациями» запорют всё и вся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #152, #154

148. Сообщение от Кирилл (??), 30-Апр-13, 15:56	–1 +/–
Это по принципу написал на заборе *** и вот он. Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним файлом, хоть сотней. К тому же иннодб поддерживает принципы acid.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #155

149. Сообщение от Кирилл (??), 30-Апр-13, 15:59	–2 +/–
> Один из очевидных плюсов очень мало настроек, в отличии от пары сотен > тонких настроек innodb Какой ещё "пары сотен"? )))) Всё настраивается не более чем десятком очевидных параметров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

150. Сообщение от Кирилл (??), 30-Апр-13, 16:02	+/–
> storage engine это API, много различных индексов есть во всех базах. Опять > же это "индексов", а не полностью контроль над всеми данными Не то что контроля, а самого подхода к формированию данных. В общем, доля общего в подходе, который диктует MySQL, ничтожна, чтобы кичиться этим и преподносить, как некую неповторимую особенность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

151. Сообщение от Кирилл (??), 30-Апр-13, 16:06	–1 +/–
> PG до сих пор в позиции догоняющего, но так как > более 20 ядер нужно не всем, то компромис быстрый, но мало > фичастый (mysql) и медленный, но реализующий то же что и коммерческие > базы (PG) для многих свежих проектов смещается в сторону PG. Водораздел не там проводите: MySQL -- если ценность данных мусорная (в куда меньшей степени касается InnoDB, но InnoDB не блещет скоростью на фоне сходных решений); PG -- если данные всё же имеют какую-то ценность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

152. Сообщение от nagual (ok), 30-Апр-13, 16:33	+/–
> это мне напоминает спичи людей, которые утверждают, что лучше компилятора соптимизируют > ассемблер. Помниться Линукс ругался на gcc по поводу неочевидности оптимизации :))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

153. Сообщение от AlexAT (ok), 30-Апр-13, 18:03	+/–
> Не встанет если у вас не максимальный уровень изоляции. В том то и фокус. Кроме уровня изоляции - есть еще особенности движка. Блокировка страниц индексов именно страницами наблюдается во многих движках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

154. Сообщение от AlexAT (ok), 30-Апр-13, 18:03	+/–
> но лучше, конечно, чтобы описаной тобой возможности не было. потому что на > одного умного DBA, который выиграет свою 0.1 секунду Тут речь, увы, о минутах...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

155. Сообщение от AlexAT (ok), 30-Апр-13, 18:04	+/–
> Это по принципу написал на заборе *** и вот он. > Нет там таблиц. В иннодб данные хранятся в сегментированной куче. Хоть одним > файлом, хоть сотней. К тому же иннодб поддерживает принципы acid. Чушь собачья. При innodb_file_per_table данные таблиц хранятся в отдельных неймспейсах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #148 Ответы: #167

156. Сообщение от Аноним (-), 30-Апр-13, 21:17	+1 +/–
>>  я не могу представить себе задачу БД, которую можно поручить GPU. Упрётся в шину. Расчет шейдеров на карте онлайн игры
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121

157. Сообщение от AlexAT (ok), 01-Май-13, 00:16	+/–
Мне тут на одном форуме вновь "глаза открыли"... может ошиблись, конечно, но надо убедиться. Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический или нет) для отчистки таблиц и индексов? Если да - для больших онлайновых баз оно неприменимо как факт, потому что: 1) встанет колом/раком по IOPS на первом же выполнении VACUUM (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть масса удаленных записей, сводя на нет оптимальность оных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129 Ответы: #160, #161

158. Сообщение от Crazy Alex (ok), 01-Май-13, 00:22	+/–
Я так понимаю, человек из веба, а особенно если где фреймворки с ORM - там оно именно так и выглядит - данных тянем мало, но в отдельных сущностях (которые каждый раз создаются заново) и много раз, причем 70% выборок - по первичному ключу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #159

159. Сообщение от AlexAT (ok), 01-Май-13, 00:24	+/–
> Я так понимаю, человек из веба, а особенно если где фреймворки с > ORM - там оно именно так и выглядит - данных тянем > мало, но в отдельных сущностях (которые каждый раз создаются заново) и > много раз, причем 70% выборок - по первичному ключу. Да даже там разбор запроса - это ни о чём. В него упереться можно только на базах < pool size или на совсем хилых VPS/VDS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #200

160. Сообщение от тень_pavel_simple (?), 01-Май-13, 09:28	+/–
> Мне тут на одном форуме вновь "глаза открыли"... может ошиблись, конечно, но > надо убедиться. > Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический > или нет) для отчистки таблиц и индексов? коенчно вакуум никуда не делся, приборкой кто-то заниматься должен. но то что было скажем в 7 ветке сравнивать с 9 .... этож совершенно разные вещи, я работу автовакуума на "больших онлайновых баз"'ах не замечаю по сравнению с основной нагрузкой. > Если да - для больших онлайновых баз оно неприменимо как факт, потому > что: 1) встанет колом/раком по IOPS на первом же выполнении VACUUM > (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть > масса удаленных записей, сводя на нет оптимальность оных. на самом деле на форумах такого увидеть можно -- жить расхочеться... фактически-же те-же gist индексы занимают не так много кода чтобы зафиксировать всю логику процесса в голове раз и на всегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

161. Сообщение от Andrey Mitrofanov (?), 01-Май-13, 10:02	+/–
> Скажите, в PG/SQL что, до сих пор актуален VACUUM (не важно, автоматический > или нет) для отчистки таблиц и индексов? Я понимаю, чо тебе не надо, но коли уж спросил: прочитай по MVCC. Вакуум из него прямо следует. И про "до сих пор": он там _будет _всегда, поскольку это основопологающее архитектурное решение. Когда уменя была одна таблица из 1.5К пар логин-пароль, одна на весь инстанс Pg, я про вакуум ничего не слышал и мне тоже не надо было. Когда мне понадобилось админить забикс с 1000+ хостов, узнал много, чего, может, и не хотел бы. > (помню свой первый опыт с PG/SQL); 2) в индексах будет сидеть > масса удаленных записей, сводя на нет оптимальность оных. А вы "там у себя" при вставке записи _раздвигаете таблицу и все её индексы? А при удалении сжимаете? В онлайне?? Про транзакции и множ.доступ не будем -- я таких материй не понимат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #162

162. Сообщение от AlexAT (ok), 01-Май-13, 10:20	+/–
> он там _будет _всегда, поскольку это основопологающее архитектурное решение. Спасибо за информацию. Пусть будет. > не надо было. Когда мне понадобилось админить забикс с 1000+ хостов, > узнал много, чего, может, и не хотел бы. Андрей (простите, в исходном сообщении ошибся именем), 1000+ хостов - это не страшно. Я статистику по нашему заббиксу дал в соседней ветке, если хотите сравнить - взгляните. > А вы "там у себя" при вставке записи _раздвигаете таблицу и все > её индексы? А при удалении сжимаете? В онлайне?? В InnoDB/TokuDB при удалении освобождаются страницы/части хранилища и индексов. Старые версии для MVCC хранятся в rollback-буфере. Если надо сжать - можно сделать ALTER/OPTIMIZE, но реальная необходимость оного при равномерном росте или стагнации объёма базы сводится к 0 - новые данные раскладываются на свободное место. И с MVCC всё в порядке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #163

163. Сообщение от sauron (??), 01-Май-13, 13:18	+/–
> В InnoDB/TokuDB при удалении освобождаются страницы/части хранилища и индексов. Старые > версии для MVCC хранятся в rollback-буфере. Если надо сжать - можно > сделать ALTER/OPTIMIZE, но реальная необходимость оного при равномерном росте или стагнации > объёма базы сводится к 0 - новые данные раскладываются на свободное > место. И с MVCC всё в порядке. Замечу что точно так же делается в PostgreSQL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #164

164. Сообщение от AlexAT (ok), 01-Май-13, 19:19	+/–
> Замечу что точно так же делается в PostgreSQL. Тогда зачем там VACUUM? Под "равномерный рост/стагнация", например, предполагалось, что может быть удалено процентов 10 базы, но на следующий день это место уже заполнится новыми данными. Вопрос: без постоянного фонового VACUUM в PG база в таких условиях будет расти бесконечно или всё-таки нет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #165

165. Сообщение от sauron (??), 01-Май-13, 19:26	+/–
>> Замечу что точно так же делается в PostgreSQL. > Тогда зачем там VACUUM? Под "равномерный рост/стагнация", например, предполагалось, что > может быть удалено процентов 10 базы, но на следующий день это > место уже заполнится новыми данными. Вопрос: без постоянного фонового VACUUM в > PG база в таких условиях будет расти бесконечно или всё-таки нет? Смотря какой VACUUM. Если FULL ANALYZE смотреть то он перестраивает таблицу с удалением пустых мест. А тот что работает в фоне автоматический просто оптимизирует то что там наосвобождали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #166, #174

166. Сообщение от AlexAT (ok), 01-Май-13, 19:36	+/–
> Смотря какой VACUUM. Если FULL ANALYZE смотреть то он перестраивает таблицу с > удалением пустых мест. А тот что работает в фоне автоматический просто > оптимизирует то что там наосвобождали. Таки новые данные запишутся на освобожденное место без фонового VACUUM? С фоновым VACUUM? Или всегда будет расти? В мануале как-то очень скользко описано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #171

167. Сообщение от Кирилл (??), 03-Май-13, 11:55	–2 +/–
Лёша, ты слышал звон, да не въехал откуда он. А этот звон из твоих штанов. Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств сегментов, которые к нему приписаны). А не физическое представление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #155 Ответы: #168

168. Сообщение от AlexAT (ok), 03-Май-13, 17:40	+/–
> Табличное пространство -- логический уровень абстракции (обобщающий носитель свойств > сегментов, которые к нему приписаны). А не физическое представление. Я просто оставлю это здесь, дабы спугнуть любителей обсуждать сферических коней в вакууме: http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-table...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #169

169. Сообщение от Кирилл (??), 06-Май-13, 15:30	+/–
Э, суть в том, что таблица это такая штука, где есть первая строка, за первой строкой идёт вторая, и так далее (я думаю ты меня понял). Так вот, такого в ИнноДБ нет (как и большинстве взрослых РСУБД). Данные не хранятся последовательно, а хранятся в виде кучи. Чем иннодб радикально и отличается от ISAM-ов разных мастей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #170

170. Сообщение от AlexAT (ok), 06-Май-13, 19:11	+/–
> Э, суть в том, что таблица это такая штука, где есть первая > строка, за первой строкой идёт вторая, и так далее (я думаю > ты меня понял). Так вот, такого в ИнноДБ нет (как и > большинстве взрослых РСУБД). Данные не хранятся последовательно, а хранятся в виде > кучи. Чем иннодб радикально и отличается от ISAM-ов разных мастей. Суть в том, что таблица СУБД - это не такая штука, как таблица на бумаге ("первая, вторая, ..."). Такая штука годится только для диссертаций. В принципе, раздельное хранение как раз есть в TokuDB, но с большими оговорками. Таблица отдельно, индексы отдельно. Но не линейно, далеко не. В современных СУБД "таблица" - это, как правило, таблица вместе с индексами, поскольку де факто они взаимозависимы. В одном файле хранится этот набор для таблицы или в разных - фактически без разницы. Главное, что не все таблицы в одном файле. Почему, и "почему бы не"? Да потому, что вставка в середину того, что вы выше описали - это операция весьма себе ресурсоемкая. Или изменение длины строки в случае полей переменной длины. Плюс блобешники хранить накладно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #178

171. Сообщение от Andrey Mitrofanov (?), 06-Май-13, 23:31	+/–
> Таки новые данные запишутся на освобожденное место без фонового VACUUM? Нет. > С фоновым VACUUM? Если не повезёт (=zabbix и ленивый админ, как я, с автовакуумом по умолчанию), то фоновый и не запустится, далее см.п.1. > Или всегда будет расти? В мануале как-то очень скользко описано. У моего предшественника Pg регулярно (раз в год?) рос до free space==0, дальнейшено оффлайна сервиса и poor man defrag-а/пылесоса в виде pgdump/pgrestore. ---Почитал, MVCC в MySQL есть. Куда девается бэк-лог, пока не вдавался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166 Ответы: #172

172. Сообщение от AlexAT (ok), 06-Май-13, 23:41	+/–
>> Таки новые данные запишутся на освобожденное место без фонового VACUUM? > Нет. Во, спасибо! > ---Почитал, MVCC в MySQL есть. Куда девается бэк-лог, пока не вдавался. У InnoDB - сидит в отдельных файлах. Новые данные сразу пишутся на место, старые вытаскиваются в лог. У TokuDB - более правильно - сначала пишется в лог, потом сливается на место.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

173. Сообщение от Кирилл (??), 07-Май-13, 15:56	+/–
Лёша, это чушь. Практически невозможно представить себе случая, когда ты сам сможешь спланировать запрос лучше, чем коммерческий планировщик запроса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #176, #212

174. Сообщение от Кирилл (??), 07-Май-13, 16:04	+1 +/–
Аналог хвоста данных отмены есть во всех СУБД с MVCC. Реализация различна (в Слоне это периодических Вакуум, в Оракле это содержание огромного пространства под сегменты отмены, в Инно тоже что-то вроде сегментов отмены). Вакуум сам по себе не плох и не хорош. Хотя в 9-той версии механизма вакуума очень грамотно завязан на планировщик ресурсов -- в результате нагрузка по содержанию данных отмены очень хорошо размазывается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165 Ответы: #177

175. Сообщение от Кирилл (??), 07-Май-13, 16:05	+/–
> Шож там у нас такое бысстрое ? Неужто MSSQL на NTFS ? Оракл на раве.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75

176. Сообщение от AlexAT (ok), 07-Май-13, 16:11	+/–
> Лёша, это чушь. Практически невозможно представить себе случая, когда ты сам сможешь > спланировать запрос лучше, чем коммерческий планировщик запроса. Не суди обо всех по себе. Тчк.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #182

177. Сообщение от AlexAT (ok), 07-Май-13, 16:14	–1 +/–
> Вакуум сам по себе не плох и не хорош. Хотя в 9-той Ну да, просто неплохой способ загнать таблицу в блокировку, и получить timeout. Всего-то лишь. Для мелких таблиц нормально, там шанс мал. Для громадных, и постоянно меняющихся - финиш.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #185, #186

178. Сообщение от Кирилл (??), 07-Май-13, 16:15	+/–
Лёша, в жизни крутиться вокруг названий. И называть таблицей нужно именно таблицу. Т.е. нечто вертикально упорядоченное. Вот в ISAM, в том числе и в MyISAM, именно такой подход и используется (именно из-за этого в ISAM данные легко добавлять в конец таблицы, но крайне сложно изменять или удалять откуда-то из середины). Поэтому там есть равенство между файлом и таблицей. В иннодб такого равенства нет и быть не может. Там просто есть ТП, в котором есть один файл и размер этого файла увеличивается по мере роста сегмента, который в нём хранится. Причём для простоты (которая хуже воровства) в ТП пихается один файл, а в одном файле размещается один сегмент ("таблица"-отношение или индекс). Причём нарастает этот файл "не построчно", а некими крупными кусками -- назовём их экстентами, которые могут и вообще данных не содержать. До поры до времени. Но равенство один кортеж = один файл надуманное. В том же инно в ТП может входить множество файлов, причём один сегмент (т.е. таблица-отношение) может быть размазан по множеству файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #170 Ответы: #179

179. Сообщение от AlexAT (ok), 07-Май-13, 16:21	+/–
> Лёша, в жизни крутиться вокруг названий. Всё крутится вокруг сути, а не вокруг названий. Предположим дерьмо вдруг назвали конфеткой. Вне зависимости от названия, я его есть не буду. За тех, у кого "всё вокруг названий" - не ручаюсь. Еще раз повторюсь: "таблица" СУБД и "таблица" на бумаге - не одно и то же. Название одно, суть - разная. > Т.е. нечто вертикально упорядоченное. Ну так зачем ты в БД-то тогда лезешь вообще? Работай в Excel. И то структура файла у него не "вертикально упорядоченная". СУБД и придумали как раз для того, чтобы обойти ограничения "вертикальной упорядоченности" таблиц, дав возможность управлять данными линейной "вертикальной" структуры в нелинейном порядке, удобном для раскладывания и обработки. > один сегмент (т.е. таблица-отношение) может быть размазан по множеству файлов. Если "отношение" - это внутритабличная сущность - нет, не может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #178 Ответы: #183

180. Сообщение от Кирилл (??), 07-Май-13, 16:22	+/–
> А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column > add/delete без остановки операций и блокировки таблицы. Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут же непредсказуемые фантомы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #181

181. Сообщение от AlexAT (ok), 07-Май-13, 16:27	+/–
> Это как? На самом низком уровне изоляции транзакции? Нафига такое нужно? Будут > же непредсказуемые фантомы. См. сайт разработчика - там в презентациях все разжевано. Данные перемещаются большими блоками, все изменения добавляются к корню, и протаскиваются по нодам в фоновом режиме. Да, снизит скорость последующих выборок по нодам, но только однократно. Зато на таблицах в xxx Гб-Тб не имеем простоя при смене структуры. Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API _моментально_, старые транзакции завершаются со старой структурой, новые - идут с новой. Реальное изменение структуры идёт в фоне. Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри файла, структура самодефрагментирующаяся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180 Ответы: #184

182. Сообщение от Кирилл (??), 08-Май-13, 12:51	+/–
Я и не пытаюсь. Не каждый имеет более, чем 10-ти летний опыт разработки и оптимизации производительности различных СУБД, как я.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #187

183. Сообщение от Кирилл (??), 08-Май-13, 13:01	+/–
> Еще раз повторюсь: "таблица" СУБД и "таблица" на бумаге - не одно > и то же. Название одно, суть - разная. Суть разная -- и название разное. Читай Кодда, лучше Дэйта, до просветления. > Если "отношение" - это внутритабличная сущность - нет, не может. Лёха, отношение это то, что ты упорно пытаешься называть таблицей (что таблицей не является, а является множеством кортежей). Сиречь: relation -- отношение. Отсюда и Реляционные СУБД. Так вот это отношение может занимать сколько угодно файлов в иннодб. Единственно -- отношение (или сегмент) не может разделяться между несколькими ТП. Тут в инно всё почти как у взрослых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #179 Ответы: #188

184. Сообщение от Кирилл (??), 08-Май-13, 13:19	+/–
> Изоляция транзакций тут вообще не при чём. Структура таблицы меняется для API > _моментально_, старые транзакции завершаются со старой структурой, новые - идут с > новой. Реальное изменение структуры идёт в фоне. Моментально? Ну вот начал ты длинную транзакцию, в её процессе структура, ладно, "таблиц" изменилась -- как транзакция вытащит согласованные по времени данные? Т.е. прежняя структура где-то и как-то сохраняется? Т. е. как я понял словарь данных имеет какой-то механизм, сохраняющий данные отмены подобных изменений структуры. Но этот механизм не ясен. > Плюс бонусом механизма является отсутствие сильной фрагментации индекса и таблицы внутри > файла, структура самодефрагментирующаяся. Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть, либо редко -- но долго и всё разом. Можно и вообще дефрагментации не допускать, к примеру, за счёт избыточности пустого места в блоках.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181 Ответы: #189

185. Сообщение от XoRe (ok), 08-Май-13, 15:25	+1 +/–
>> Вакуум сам по себе не плох и не хорош. Хотя в 9-той > Ну да, просто неплохой способ загнать таблицу в блокировку, и получить timeout. > Всего-то лишь. Для мелких таблиц нормально, там шанс мал. Для громадных, > и постоянно меняющихся - финиш. vacuum'ы разные бывают. Просто vacuum работает без exclusive lock. exclusive lock на таблицу кидает vacuum full. Но на то он и full. http://www.postgresql.org/docs/9.1/static/sql-vacuum.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #190

186. Сообщение от Кирилл (??), 08-Май-13, 15:40	+/–
Нет. Там нет ни эскалации блокировок, ни эксклюзивного блокирования. Единственно, конечно ресурсы ввода/вывода и процессора отъедает. Хотя такое говорить тоже не слишком корректно. У того же Оракла на обслуживание механизма MVCC тоже уходит не мало ресурсов. Поэтому подобный механизм в Слоне не хуже прочих. Другое дело, что планировщик у него слабее, чем у того же Оракла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177

187. Сообщение от AlexAT (ok), 08-Май-13, 15:58	+1 +/–
> Я и не пытаюсь. Не каждый имеет более, чем 10-ти летний опыт > разработки и оптимизации производительности различных СУБД, как я. Понты. Организации и ФИО в студию - поглядим.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #182

188. Сообщение от AlexAT (ok), 08-Май-13, 15:59	+/–
Печалька печальная. Еще раз подтверждаешь, что от теоретика до практика - пропасть немеряная. А потом смотришь на поделки таких теоретиков, и диву даешься.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #191

189. Сообщение от AlexAT (ok), 08-Май-13, 16:05	+/–
> Моментально? Ну вот начал ты длинную транзакцию, в её процессе структура, ладно, > "таблиц" изменилась Ты почитай механизмы работы TokuDB, на практике посмотри. Там фокус как раз в том, что все изменения применяются по мере завершения транзакций, а новые транзакции изменения видят сразу. > прежняя структура где-то и как-то сохраняется? > Но этот механизм не ясен. Сам механизм ясен и прозрачен. Представь себе, что вся база - один большой сплошной лог (!!!). Который тихонько самодефрагментируется, вычищая ненужное, и реорганизуя записи в линейные структуры. Немножко упростил, но вот это и есть TokuDB. > Тут опять же дилемма -- либо дефрагментировать постоянно и по чуть-чуть Там хитро - структура сама дефрагментируется в процессе штатного функционирования. Она устроена так, что не фрагментируется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #184 Ответы: #198

190. Сообщение от AlexAT (ok), 08-Май-13, 16:15	+/–
> http://www.postgresql.org/docs/9.1/static/sql-vacuum.html Уже веселее. Но всё равно неприятно следующее: VACUUM causes a substantial increase in I/O traffic, which might cause poor performance for other active sessions.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185 Ответы: #209

191. Сообщение от Кирилл (??), 09-Май-13, 04:02	–1 +/–
Леха, увы, подобные сентенции -- про бесполезность теории -- обычно выдают в собеседнике неосилянта пэтэушника.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #192, #193, #194

192. Сообщение от arisu (ok), 09-Май-13, 04:05	+2 +/–
а тут не бесполезность, тут «страшно далеки они от народа». потому что ехать надо вчера, а высокотехнологичная суперэкономичная машина — только завтра, и то лишь в чертежах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191 Ответы: #195

193. Сообщение от arisu (ok), 09-Май-13, 04:06	+/–
p.s. это не значит, что машина не нужна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

194. Сообщение от AlexAT (ok), 09-Май-13, 12:32	+/–
> Леха, увы, подобные сентенции -- про бесполезность теории -- обычно выдают в > собеседнике неосилянта пэтэушника. Теория не бесполезна, но вот слепое поклонение теории - удел недалеких, Кира. Кроме того - любые теории являются сферическим конем, предметом рассмотрения и корректировки, а вот практика - она живая, ее потрогать можно. Это не говорит о том, что практика без теории возможна. Это говорит о том, что если человек замкнулся на теорию в отрыве от практики - грош ему цена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #191

195. Сообщение от nagual (ok), 10-Май-13, 18:09	+/–
> а тут не бесполезность, тут «страшно далеки они от народа». потому что > ехать надо вчера, а высокотехнологичная суперэкономичная машина — только завтра, > и то лишь в чертежах. Это вы про автомобильТеслы на трех радиолампах ? За который его заперли под домашний арест до конца жизни ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #196, #197

196. Сообщение от arisu (ok), 10-Май-13, 18:27	+/–
а ещё он марсиан видел!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

197. Сообщение от AlexAT (ok), 10-Май-13, 22:24	+/–
> Это вы про автомобиль Теслы на трех радиолампах ? За который его заперли > под домашний арест до конца жизни ? Да Тесла вообще-то практик был, 100%-й - он сначала внедрял идеи на основе существующей теории, потом исследовал результаты и улучшал. И не запирал его никто. А вот галимые теоретики от его идей с переменным током тоже вначале отказывались, ибо "не по канонам". Правда, потом деваться стало некуда - мир шагнул без них :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195

198. Сообщение от Аноним (-), 13-Май-13, 18:14	+/–
> Сам механизм ясен и прозрачен. Представь себе, что вся база - один > большой сплошной лог (!!!). Который тихонько самодефрагментируется, вычищая ненужное, > и реорганизуя записи в линейные структуры. Немножко упростил, но вот это > и есть TokuDB. Не очень-то тихонько, на самом деле. В последних бенчах на mysqlperformanceblog хорооошая такая пила на графике insert'ов видна, с красиивыми такими провалами. Не так, конечно, ужасно как у LevelDB, где с какого-то момента compacting начинает съедать вообще всё и rps доходит до нуля, но таки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189 Ответы: #202

199. Сообщение от Аноним (-), 13-Май-13, 18:17	+/–
> Именно так. Просто помимо сложных выражений я не могу представить себе задачу > БД, которую можно поручить GPU. Упрётся в шину. Так дело в том что "сложных выражений" становится всё больше, дальше если с виду они и не особо сложные. Тот же JSON в Pg 9.3 - распарсить, что-то из него добыть и добытое опять в JSON чтоб отдать - очень даже CPU-bound будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #203

200. Сообщение от Аноним (-), 13-Май-13, 18:20	+/–
> Да даже там разбор запроса - это ни о чём. В него > упереться можно только на базах < 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...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #204, #214

201. Сообщение от Аноним (-), 13-Май-13, 18:33	+/–
>> TokuDB это типа хранилища для архивов или аналитики, где преобладает запись. >> TokuDB можно использовать для сбора статистики ddos аттак и анализа или какоую >> то аналитическую систему сбора > Неправда. Она в целом хорошо справляется не только с записью, Практически -- только. Уже на UPDATE она медленней, а на INSERT ON DUPLICATE - совсем всё плохо. Есть, правда, специальный случай апдейта "x = x + c" где с - константа, специально оптимизированный в Toku, остальное - в пролете. > увеличивает параллелизм Раньше всё плохо с этим было в Toku, хорошо если поправили. > А еще у TokuDB есть незаменимая для огромных БД фича: hot index/column > add/delete без остановки операций и блокировки таблицы. Впервые начали использовать TokuDB > только из-за этого - потому, что новая аналитика постоянно требовала новых > индексов. Именно. Поэтому, как и сказано выше - идеально как логгер больших объемов + гибкая аналитика в одном флаконе. То есть ниша на самом деле рыночная - очень большая, огромная даже. В идеале -- это лавка, которая сидела на MySQL, объемы выросли (и вырастут еще больше, руководство прочитало статью про Big Data, да и вообще неплохо бы), и требования по аналитике тоже всё развесистей, и надо бы, с одной стороны, как-то с этим справляться, а с другой - строить вот прямо сразу кластеры с кассандрами и некому, и не на что, и некогда. Вывод - в краткосрочной перспективе прыгаем на TokuDB (тем более что можно постепенно это делать), в среднесрочной - присматриваемся к Vertica, в долгосрочной - ищем спецов по Big Data и дата сайентистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88 Ответы: #205

202. Сообщение от AlexAT (ok), 14-Май-13, 07:31	+/–
> Не очень-то тихонько, на самом деле. В последних бенчах на mysqlperformanceblog хорооошая > такая пила на графике insert'ов видна, с красиивыми такими провалами. Не > так, конечно, ужасно как у LevelDB, где с какого-то момента compacting > начинает съедать вообще всё и rps доходит до нуля, но таки. Вы вот об этом бенче - http://www.mysqlperformanceblog.com/2013/05/07/benchmarking-.../ ? Таки да, чекпоинтинг бесплатным не бывает. У InnoDB в таких условиях всё вообще плохо - на первые 5 минут теста можно внимания не обращать - там таблица умещалась в память целиком. TokuDB оптимизирует именно работу с дисковой подсистемой и индексами, в случае CPU-bound/RBW-bound workloads лучше смотреть в сторону иных решений. Вообще к указанному бенчу есть ряд серьезных нареканий - автор пытается по сути забить гвоздь микроскопом. Под такую задачу надо in-memory database, +, возможно, NoSQL, и TPS будут куда мягче и шелковистее. По сути бенч - одна из стадий OLTP в чистом виде (ну и выбор железа и структуры таблиц намекают именно на OLTP), только вот слегка непонятен выбор последовательности процесса - гибрид высоких TPS на входе + rollup'а также на входе смотрится как-то неправильно. Это не говорит о том, хорош или плох бенч - это просто замечания к тому, что в данном случае он не раскрывает всех сторон медали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #207

203. Сообщение от AlexAT (ok), 14-Май-13, 08:14	+/–
> Тот же JSON в Pg 9.3 Не нужен. Адовое нарушение собственно принципа структурирования РСУБД. Чего-то парсить и добывать оттуда - в общем, задача приложения. Не против, если это делается в движке - но производительность этого логично будет ниже плинтуса. Так можно и XML в движок РСУБД притащить, и обработку изображений, звука, видео, и дифференциальные уравнения до кучи - чего уж там. Правда, нафига козе баян - ясно плоховато.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #199

204. Сообщение от AlexAT (ok), 14-Май-13, 08:17	+/–
> "..>95% of the CPU time in reads is spent in the SQL > parser" > http://www.openldap.org/lists/openldap-devel/201203/msg00017... а) это SQLite б) это < pool size
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

205. Сообщение от AlexAT (ok), 14-Май-13, 08:21	+/–
> Практически -- только. Уже на UPDATE она медленней, а на INSERT ON > DUPLICATE - совсем всё плохо. Есть, правда, специальный случай апдейта "x > = x + c" где с - константа, специально оптимизированный в > Toku, остальное - в пролете. Да, очень сильно зависит от структуры таблицы. Я бы не сказал, что на UPDATE сложных таблиц с кучей индексов оно медленнее. Насчет оптимизации - сильно не хватает X = X + VALUE(X).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #206

206. Сообщение от Аноним (-), 14-Май-13, 23:36	+/–
обещали добавить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

207. Сообщение от Аноним (-), 14-Май-13, 23:45	+/–
> Вообще к указанному бенчу есть ряд серьезных нареканий - автор пытается по > сути забить гвоздь микроскопом. Под такую задачу надо in-memory database, +, > возможно, NoSQL, и TPS будут куда мягче и шелковистее. Конкретный бенч раскрывает конкретную сторону конкретной медали, что от него и требуется. В данном случае - как оно ведет себя под жестким write load. Ответ - так себе. На распространенных in-memory DB оно конечно график будет поровней и форма пилы другая (ибо иерархичность памяти никто не отменял, но ваятелям модным in-memory db про неё забыли рассказать), только вот персистенс будет уже сбоку и сколько улетит незаписанных данных при сбое -- ... А это типа бывает важно, не все же веб-апп "to-do list" на рельсах с редисом рисуют. Что касается NoSQL - если не брать те где всё будет просто тупо медленней (Riak & Co.), то опять же, пила будет несколько иной формы ибо в том или ином виде они в большинстве своем SSTable-based - Cassandra etc. Ну а про LevelDB я выше написал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202 Ответы: #208

208. Сообщение от AlexAT (ok), 15-Май-13, 07:21	+/–
> В данном случае - как оно ведет себя под жестким write load. Ответ - так себе. Неправильный ответ :) Ведет себя оно в разы лучше InnoDB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #207 Ответы: #211

209. Сообщение от XoRe (ok), 15-Май-13, 20:44	+/–
>> http://www.postgresql.org/docs/9.1/static/sql-vacuum.html > Уже веселее. Но всё равно неприятно следующее: > VACUUM causes a substantial increase in I/O traffic, which might cause poor > performance for other active sessions. Для вас новость, что дефрагментация вызывает большой I/O? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190 Ответы: #210

210. Сообщение от AlexAT (ok), 15-Май-13, 23:06	+/–
> Для вас новость, что дефрагментация вызывает большой I/O? :) Да нет, неприятно, что данная СУБД не умеет повторно использовать свободное место без принудительного дефрага и просадки по I/O.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209

211. Сообщение от Аноним (-), 15-Май-13, 23:55	+/–
Так я же не сказал "отвратительно", а всего лишь "так себе".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #208

212. Сообщение от Аноним (-), 13-Окт-16, 16:01	+/–
Тут на Оракле, у которого этот оптимизатор уж точно не полное г. на "больших серверах" постоянно приходится использовать хинты т.к. 1 из 100 запросов "напрямую" не отрабатывает за разумное время, и выигрыш бывает не на секунды. Ситуации когда у вас есть набор таблиц и нужна определённая выборка в течении ограниченного времени ( а не пары дней/недель что-бы как тут предлагали исходники поправить ) по нескольку раз в месяц случаются, и очень радует что в Оракле такая возможность есть, хоть по умолчанию использование её и не приветствуется ).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173

213. Сообщение от Denisss (?), 19-Фев-17, 11:45	+/–
>> запросы всё равно упираются в 99% случаев в разбор SQL > Откройте для себя prepared statement уже наконец. Какой нафиг prepared statement в web ? На каждую страницу, на каждый коннект они убиваются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

214. Сообщение от anomymous (?), 19-Фев-17, 11:50	+/–
а) это SQLite б) это OpenLDAP Механика запросов к БД в голове у тех, кто писал модули хранения данных к OpenLDAP (включая встроенные БД), как бы это помягче-то сказать, специфическая... Взгляните на код сами, ужаснитесь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

215. Сообщение от Аноним (215), 04-Авг-20, 12:16	+/–
14.04.15 В своём блоге команда Percona заявила о приобретении компании Tokutek, разработчика движка TokuDB для СУБД MySQL/MariaDB/Percona. Теперь даже ссылка из шапки ведёт на сайт Перконы :)
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема