Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Здравствуйте, pzhy, Вы писали:
P>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
_AB>Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
Это ты дал "И неконкурентная работа в контексте СУБД никого не интересует." — бухаешь?
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
_AB>Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
P>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее
Быстрее чего?
P>, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее.
Быстрее чего?
P>Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Каких?
ЗЫ. MySQL не сможет много кого порвать по банальной причине: в нем тупо нельзя оптимизировать запросы. Почему? Потому что каждый из движков плевать хотел на любую из оптимизаций или любую их комбинацию. Из того, что помню:
— SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
— В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
В книжицах типа High Performance MySQL вообще много всяких веселостей написано по поводу этого гуана.
Здравствуйте, Mamut, Вы писали:
M>ЗЫ. MySQL не сможет много кого порвать по банальной причине: в нем тупо нельзя оптимизировать запросы. Почему? Потому что каждый из движков плевать хотел на любую из оптимизаций или любую их комбинацию. Из того, что помню: M>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
Это бред — причем бред какойто нереальный....
M>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
При каком энджайне? Если про исам — то это его плюс — но его легко комбинировать к инобд — или мемори. Но если только он — я отвечаю — что на иннобд можно построиь выборку не менее крутую чем на оракле, и мсскл, При количестве записей в много милиардов.
да и —
M>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса. M>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
Бред, на майисам — при определенных делах — так, но на иннодб — ты не прав
Здравствуйте, pzhy, Вы писали:
P>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы?
Последний раз c MySQL работал год назад, исходников не осталось. Но, насколько помню запрос в котором происходит объединение 3 или 4 таблиц через left join в котором может быть минимум 1 подзапрос с группировкой (GROUP BY) на MySQL 5.1/5.5 отрабатывал за часы, количество записей в БД было порядка 300 тыщ. Запрос был что-то типа:
select t1.id, t1.col1, t2.col1, t3.col1, t4.col1
from table1 as t1 left join table2 as t2 on t1.id = t2.id
left join table3 as t3 on t2.id = t3.id
left join (select id, col1, col2 where col1 = чему-то group by col1) as t4 on t3.id = t4.id
P>Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Здравствуйте, sysenter, Вы писали:
S>Последний раз c MySQL работал год назад, исходников не осталось. Но, насколько помню запрос в котором происходит объединение 3 или 4 таблиц через left join в котором может быть минимум 1 подзапрос с группировкой (GROUP BY) на MySQL 5.1/5.5 отрабатывал за часы, количество записей в БД было порядка 300 тыщ. Запрос был что-то типа:
S>select t1.id, t1.col1, t2.col1, t3.col1, t4.col1 S>from table1 as t1 left join table2 as t2 on t1.id = t2.id S>left join table3 as t3 on t2.id = t3.id S>left join (select id, col1, col2 where col1 = чему-то group by col1) as t4 on t3.id = t4.id
Запрос на MySQL отрабатывал за 3-4 часа, при этом все индексы согласно плану выполнения запроса были установлены.
На свеже установленном PostgreSQL этот запрос без всякого тюнинга отработал меньше чем за секунду.
Здравствуйте, pzhy, Вы писали:
P>Здравствуйте, Mamut, Вы писали:
P>да и —
M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
Тут походу ошибка, fullscan не будет.
M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы P>Бред, на майисам — при определенных делах — так, но на иннодб — ты не прав
Здравствуйте, pzhy, Вы писали:
P>В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
Здравствуйте, sysenter, Вы писали
M>>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы P>>Бред, на майисам — при определенных делах — так, но на иннодб — ты не прав
S>А тут Mamut всё верно написал.
Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
Здравствуйте, sysenter, Вы писали:
S>Последний раз c MySQL работал год назад, исходников не осталось. Но, насколько помню запрос в котором происходит объединение 3 или 4 таблиц через left join в котором может быть минимум 1 подзапрос с группировкой (GROUP BY) на MySQL 5.1/5.5 отрабатывал за часы, количество записей в БД было порядка 300 тыщ. Запрос был что-то типа:
S>select t1.id, t1.col1, t2.col1, t3.col1, t4.col1 S>from table1 as t1 left join table2 as t2 on t1.id = t2.id S>left join table3 as t3 on t2.id = t3.id S>left join (select id, col1, col2 where col1 = чему-то group by col1) as t4 on t3.id = t4.id
P>>Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
S>смешно, очень смешно.
Как это не смешно но мои подобные запросы на базе — где ежедневно +15 млн новых записей отрабатывают за секунды. А запросы апдейта за 10 минут где порядка 3-4 — милионов. Кстати его там сменили с мсскл 2000.
M>>ЗЫ. MySQL не сможет много кого порвать по банальной причине: в нем тупо нельзя оптимизировать запросы. Почему? Потому что каждый из движков плевать хотел на любую из оптимизаций или любую их комбинацию. Из того, что помню: M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
P>Это бред — причем бред какойто нереальный....
Не ко мне — к авторам High performance mysql
M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
P>При каком энджайне?
Ключевой вопрос, который сводит на нет все рассужления про крутизну мускуля
P>Если про исам — то это его плюс
Его плюс в том, что оптимизатор запросов не сможет пользоваться индексами, если поменять местами два слова в SELECT'е? С какой стороны это плюс?
P>- но его легко комбинировать к инобд — или мемори. Но если только он — я отвечаю — что на иннобд можно построиь выборку не менее крутую чем на оракле, и мсскл
Нельзя. Потому что у innodb много своих тараканов, а оптимизатор мускуля работать не меет, потому что он не в курсе, как себя ведет тот или иной движок.
P>, При количестве записей в много милиардов.
Ну да, после долгого и мучительного траха с поисками той самой правильной записи, которая сможет заставить полуоптимизатор запросов мускуля сегнирировать хоть близко вменяемый план запроса.
P>да и —
M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса. M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
P>Бред, на майисам — при определенных делах — так,
Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
Здравствуйте, pzhy, Вы писали:
P>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
Кому тут смешно? Правильный джойн между инннобд и мемори разорвет любой большой БД. И это из опыта, а не маркетенгового булшита.
Как это не странно — но мне удается сводить 15 млн записей в день из индексов из мсскл2000(DTS), за 15 минут. А мсскл — не выкинули потомучто там действительно хорошие тулзы по дата майнинг, на мускуле вообще ничего по этому нет. Но что касается просто бд... Мускул на определенных запросах — рвет тотже мсскл — просто в разы. Это моя практика — хотя конечно чем больше конкурентных запросов — тем более мсскл догоняет. но и на 100 конкурентах не доганяет
Здравствуйте, pzhy, Вы писали:
НС>>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
P>однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
Ты попробуй повнимательнее прочесть то, что я написал. РСУБД не нацелены на рынок датамайнинга. Поэтому бессмысленно делать какие то выводы из их доли на этом рынке.
