forum.opennet.ru - "OpenNews: Сравнение производительности MySQL 5.1 и 6.0" (13)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"OpenNews: Сравнение производительности MySQL 5.1 и 6.0"

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

"OpenNews: Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от opennews on 11-Апр-08, 13:04
Петр Зайцев представил (http://www.mysqlperformanceblog.com/2008/04/10/tpc-h-run-on-.../) результаты тестирования производительности MySQL 5.1.23 и тестовой версии MySQL 6.0.4, при работе с двумя наборами данных на сервере Dell 2950 с 16Гб ОЗУ и 8 ядрами CPU. В качестве типа хранилища был использован MyISAM, сравнение было основано на измерении времени выполнения 22 выборок, составленных на основе запросов, используемых в тестовом комплекте TPC-H (http://www.tpc.org/tpch/). Результаты: - Набор данных размером 10Гб (целиком помещается в память): из 22 тестов в 7 запросы были выполнены быстрее в MySQL 6.0.4, в 11 тестах быстрее оказался MySQL 5.1.23. В среднем расхождение было около 10 процентов, кроме 3 тестов, где разница была ощутима; - Набор данных размером 100Гб: Из 22 запросов, только 8 были выполнены обеими версиями MySQL менее, чем за 3 часа. В 6 успешных тестах победу одержал MySQL 6.0.4, причем в двух с опережением более чем в 2 раза. В двух тестах незна... URL: http://www.mysqlperformanceblog.com/2008/04/10/tpc-h-run-on-.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=15246
Высказать мнение \| Ответить \| Правка \| Cообщить модератору

Оглавление

Сравнение производительности MySQL 5.1 и 6.0, airman, 13:04 , 11-Апр-08, (1)
Сравнение производительности MySQL 5.1 и 6.0, amix, 15:12 , 11-Апр-08, (2)

Сравнение производительности MySQL 5.1 и 6.0, chesnok, 15:36 , 11-Апр-08, (3)

Сравнение производительности MySQL 5.1 и 6.0, squirl, 18:17 , 11-Апр-08, (4)

Сравнение производительности MySQL 5.1 и 6.0, Бурзум, 22:04 , 11-Апр-08, (6)

Сравнение производительности MySQL 5.1 и 6.0, rPman, 21:04 , 11-Апр-08, (5)

Сравнение производительности MySQL 5.1 и 6.0, GliNT, 00:52 , 12-Апр-08, (7)

Сравнение производительности MySQL 5.1 и 6.0, andr.mobi, 14:02 , 12-Апр-08, (9)

(offtopic) Не буди спящую кошку (ц), Michael Shigorin, 00:15 , 13-Апр-08, (11)

(offtopic) Не буди спящую кошку (ц), evgeniy, 00:29 , 28-Апр-08, (12)

Сравнение производительности MySQL 5.1 и 6.0, Аноним, 23:21 , 12-Апр-08, (10)

Сравнение производительности MySQL 5.1 и 6.0, Аноним, 13:26 , 15-Июл-10, (13)

Сравнение производительности MySQL 5.1 и 6.0, Michael Shigorin, 18:39 , 17-Июл-10, (14)

Сообщения по теме [Сортировка по времени | RSS]

1. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от airman on 11-Апр-08, 13:04

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

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

2. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от amix (??) on 11-Апр-08, 15:12

А постгрес умеет паралелить ?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от chesnok (ok) on 11-Апр-08, 15:36

oracle позволяет это...
на самом деле если Вы делаете запрос из таблицы с 70 млн записей, то основная нагрузка будет на CPU0, хотя если еще будет запушен параллельно другой запрос, то mysql должен его передать на другой CPU, я такое замечал покрайне мере в mysql 5.0.44, но беда в том, что действительно есть очень медленные и ресурсоемкие запросы (!), причем ресурсы машины позволяют задйствовать еще дополнительное процессорное время остальных процессоров, но к сожелению этого пока нет и очень жаль.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

4. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от squirl on 11-Апр-08, 18:17

опять MyISAM... почему его еще не похоронили?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

6. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от Бурзум on 11-Апр-08, 22:04

Он как бы быстр, если нужно просто складировать и читать. Как бы очень. По субьективным ощущениям (на таблицах в 1Гб и аналогичном серваке), MyISAM быстрее Inno в РАЗЫ.
зы. на дефолтной некрученной настройке, конечно же

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от rPman on 11-Апр-08, 21:04

я могу сомниваться.. но MyISAM не самое ли быстрой на данный момент хранилище для SQL баз данных? Есть огромное количество задач, когда ну не требуется сложные многоуровневой вложенности запросы, или когда нафиг не требуется часто, точнее многозадачно, или лучше сказать транзакционно? :), писать в БД, но надо очень часто и быстро из нее читать...
P.S. Кстати есть ли более быстрые решения для не SQL баз данных?

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

7. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от GliNT (??) on 12-Апр-08, 00:52

BDB быстрее, на определенных типах задач, конечно, не зря Оракл в него денег вложил ;)

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

9. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от andr.mobi (??) on 12-Апр-08, 14:02

Berkeley DB однозначно всех ибйод и по скорости, и по поддержке возможностей (у него есть все, кроме SQL и реляционных таблиц), и теперь и по престижности, потому что официально называет Oracle Berkeley DB. А те олухи, которые воротят от него нос и считают memcached вешиной технологий просто бездарные сопляжуи и молокососы.
Отсутствие SQL-интерпретатора (у memcached тоже интерпретатор, хоть и куцый) ускоряет работу в десятки и сотни раз! Пишут на БАСИКе и удивляются, чего это так медленно и много ресурсов жрет :))) Любую реляционную таблицу можно разложить на несколько нереляционных, если в шОпе горЯт гОвна. Не нужные возможности не присоединяются к исполняемому файлу и добавляют приложению самый необходимый минимум веса. А как вам апгрейд версии без остановки БД?
И всё это Оракл раздает открыто и бесплатно по некоммерческой лицензии, не знаю уж как они на такое согласились.
Мускул гораздо менее удобный инструмент, и гораздо более громоздкий.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

11. "(offtopic) Не буди спящую кошку (ц)" +/–

Сообщение от Michael Shigorin (ok) on 13-Апр-08, 00:15

>Berkeley DB однозначно всех
Сэр никогда не сталкивался с развалом bdb?  Похоже, сэр вообще с bdb под нагрузкой не сталкивался.  Не было бы такого щенячьего восторга :(
К сожалению, и около openldap, и около cyrus-imap косяками ходят требования специфичных версий плюс к ним специфичных патчей :(  С феерией, когда один бинарник может оказаться в итоге слинкован с двумя libdb* (например, 4.4 "с собой" и 4.3 -- опосредованно, через какую-либо из библиотек, собранных ранее) -- тоже бывали разные истории, пока такие ситуации по крайней мере у нас не были исключены под корень.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

12. "(offtopic) Не буди спящую кошку (ц)" +/–

Сообщение от evgeniy (??) on 28-Апр-08, 00:29

  Кстати, о bdb и ldap'е.  Давно и прочно не люблю ldap.. Но я не знаю стандартных готовых решений по организации хранения паролей и прочих данных пользователей в pgsql/mysql уровня RHDS/FDS ..

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

10. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от Аноним (??) on 12-Апр-08, 23:21

>Berkeley DB однозначно всех ибйод и по скорости, и по поддержке возможностей (у него есть все, кроме SQL и реляционных таблиц)
Фраза уже смешная... Вдумайтесь просто...
А что по скорости и функциональности нет конкуренции Intersystems Cache... Факт.
И Оракл рядом не валялся.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

13. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от Аноним (??) on 15-Июл-10, 13:26

Вовсе не факт. Работал я с Intersystems Cache. Никаких передовых алгоритмов и структур данных в ней не применяется. Преимущества в скорости достигаются исключительно урезанием функциональности (например отсутствием MVCC, а значит и нормальной изоляции транзакций).

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

14. "Сравнение производительности MySQL 5.1 и 6.0" +/–

Сообщение от Michael Shigorin (ok) on 17-Июл-10, 18:39

>Преимущества в скорости достигаются исключительно урезанием функциональности
Не знаю насчёт конкретно Cache, но вообще-то иерархички как бы немного иначе смотрят на данные, и подходить к ним реляционно попросту глупо.
PS: я работал с другими иерархическими СУБД (Daylight Thor, позже смотрел на базу GT.M) -- дело как раз в подходе, ну и структурах-алгоритмах.  На реляционках догнать результат в _тех_ задачах было нереально, пробовали.

Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от airman on 11-Апр-08, 13:04
Таки да, распараллеливание выполнения больших запросов - это конечно узкое место, сколько раз замечал ,что один проц загружен запросом а остальные простаивают.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

2. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от amix (??) on 11-Апр-08, 15:12
А постгрес умеет паралелить ?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	3. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от chesnok (ok) on 11-Апр-08, 15:36
	oracle позволяет это... на самом деле если Вы делаете запрос из таблицы с 70 млн записей, то основная нагрузка будет на CPU0, хотя если еще будет запушен параллельно другой запрос, то mysql должен его передать на другой CPU, я такое замечал покрайне мере в mysql 5.0.44, но беда в том, что действительно есть очень медленные и ресурсоемкие запросы (!), причем ресурсы машины позволяют задйствовать еще дополнительное процессорное время остальных процессоров, но к сожелению этого пока нет и очень жаль.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

4. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от squirl on 11-Апр-08, 18:17
опять MyISAM... почему его еще не похоронили?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	6. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от Бурзум on 11-Апр-08, 22:04
	Он как бы быстр, если нужно просто складировать и читать. Как бы очень. По субьективным ощущениям (на таблицах в 1Гб и аналогичном серваке), MyISAM быстрее Inno в РАЗЫ. зы. на дефолтной некрученной настройке, конечно же
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

5. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от rPman on 11-Апр-08, 21:04
я могу сомниваться.. но MyISAM не самое ли быстрой на данный момент хранилище для SQL баз данных? Есть огромное количество задач, когда ну не требуется сложные многоуровневой вложенности запросы, или когда нафиг не требуется часто, точнее многозадачно, или лучше сказать транзакционно? :), писать в БД, но надо очень часто и быстро из нее читать... P.S. Кстати есть ли более быстрые решения для не SQL баз данных?
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	7. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от GliNT (??) on 12-Апр-08, 00:52
	BDB быстрее, на определенных типах задач, конечно, не зря Оракл в него денег вложил ;)
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	9. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от andr.mobi (??) on 12-Апр-08, 14:02
	Berkeley DB однозначно всех ибйод и по скорости, и по поддержке возможностей (у него есть все, кроме SQL и реляционных таблиц), и теперь и по престижности, потому что официально называет Oracle Berkeley DB. А те олухи, которые воротят от него нос и считают memcached вешиной технологий просто бездарные сопляжуи и молокососы. Отсутствие SQL-интерпретатора (у memcached тоже интерпретатор, хоть и куцый) ускоряет работу в десятки и сотни раз! Пишут на БАСИКе и удивляются, чего это так медленно и много ресурсов жрет :))) Любую реляционную таблицу можно разложить на несколько нереляционных, если в шОпе горЯт гОвна. Не нужные возможности не присоединяются к исполняемому файлу и добавляют приложению самый необходимый минимум веса. А как вам апгрейд версии без остановки БД? И всё это Оракл раздает открыто и бесплатно по некоммерческой лицензии, не знаю уж как они на такое согласились. Мускул гораздо менее удобный инструмент, и гораздо более громоздкий.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	11. "(offtopic) Не буди спящую кошку (ц)"	+/–
	Сообщение от Michael Shigorin (ok) on 13-Апр-08, 00:15
	>Berkeley DB однозначно всех Сэр никогда не сталкивался с развалом bdb? Похоже, сэр вообще с bdb под нагрузкой не сталкивался. Не было бы такого щенячьего восторга :( К сожалению, и около openldap, и около cyrus-imap косяками ходят требования специфичных версий плюс к ним специфичных патчей :( С феерией, когда один бинарник может оказаться в итоге слинкован с двумя libdb* (например, 4.4 "с собой" и 4.3 -- опосредованно, через какую-либо из библиотек, собранных ранее) -- тоже бывали разные истории, пока такие ситуации по крайней мере у нас не были исключены под корень.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	12. "(offtopic) Не буди спящую кошку (ц)"	+/–
	Сообщение от evgeniy (??) on 28-Апр-08, 00:29
	Кстати, о bdb и ldap'е. Давно и прочно не люблю ldap.. Но я не знаю стандартных готовых решений по организации хранения паролей и прочих данных пользователей в pgsql/mysql уровня RHDS/FDS ..
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору

10. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
Сообщение от Аноним (??) on 12-Апр-08, 23:21
>Berkeley DB однозначно всех ибйод и по скорости, и по поддержке возможностей (у него есть все, кроме SQL и реляционных таблиц) Фраза уже смешная... Вдумайтесь просто... А что по скорости и функциональности нет конкуренции Intersystems Cache... Факт. И Оракл рядом не валялся.
Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	13. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от Аноним (??) on 15-Июл-10, 13:26
	Вовсе не факт. Работал я с Intersystems Cache. Никаких передовых алгоритмов и структур данных в ней не применяется. Преимущества в скорости достигаются исключительно урезанием функциональности (например отсутствием MVCC, а значит и нормальной изоляции транзакций).
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору


	14. "Сравнение производительности MySQL 5.1 и 6.0"	+/–
	Сообщение от Michael Shigorin (ok) on 17-Июл-10, 18:39
	>Преимущества в скорости достигаются исключительно урезанием функциональности Не знаю насчёт конкретно Cache, но вообще-то иерархички как бы немного иначе смотрят на данные, и подходить к ним реляционно попросту глупо. PS: я работал с другими иерархическими СУБД (Daylight Thor, позже смотрел на базу GT.M) -- дело как раз в подходе, ну и структурах-алгоритмах. На реляционках догнать результат в _тех_ задачах было нереально, пробовали.
	Высказать мнение \| Ответить \| Правка \| ^ \| Наверх \| Cообщить модератору