M>>Не верю. Потому что в мускуле нет ничего особенного или специального.
P>Есть быстрая отработка простых запросов, у меня 300 клиентов — сканят базу раз в 3 секунды. Да криво — но я немогу это поменять. Мсскл — дохнет мускул живет — и дает другим процессам жить
Если запросы простые, то что-то неправильно с запросами.
P>>>У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...
M>>Ты так и не предоставил ни единого доказательства слива, кроме громких заявлений о том, что примитивный оптимизатор — это круто.
[скипнут примитивный запрос]
P>Это из кода с++, но, отрабатывет на полумилионе запизей за 10 милисикунд. Мсскл — порядка 2 секунд.
Это скорее всего значит, что где-то в mssql неверно проставлены индексы или неверно настроена база данных. Ничего особенного в этом запросе не вижу.
M>>ЗЫ. MySQL не сможет много кого порвать по банальной причине: в нем тупо нельзя оптимизировать запросы. Почему? Потому что каждый из движков плевать хотел на любую из оптимизаций или любую их комбинацию. Из того, что помню: M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
P>Это бред — причем бред какойто нереальный....
Не ко мне — к авторам High performance mysql
M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
P>При каком энджайне?
Ключевой вопрос, который сводит на нет все рассужления про крутизну мускуля
P>Если про исам — то это его плюс
Его плюс в том, что оптимизатор запросов не сможет пользоваться индексами, если поменять местами два слова в SELECT'е? С какой стороны это плюс?
P>- но его легко комбинировать к инобд — или мемори. Но если только он — я отвечаю — что на иннобд можно построиь выборку не менее крутую чем на оракле, и мсскл
Нельзя. Потому что у innodb много своих тараканов, а оптимизатор мускуля работать не меет, потому что он не в курсе, как себя ведет тот или иной движок.
P>, При количестве записей в много милиардов.
Ну да, после долгого и мучительного траха с поисками той самой правильной записи, которая сможет заставить полуоптимизатор запросов мускуля сегнирировать хоть близко вменяемый план запроса.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, pzhy, Вы писали:
P>>Дайте скрипты сосдания таблиц, и ваши запросы?
RO>Дано: таблица Отрезок (a integer, b integer).
RO>Найти: объединение всех отрезков (в том же виде, только записей будет меньше).
RO>Например, (1, 2), (3, 6), (4, 5), (7, 9), (8, 10) → (1, 2), (3, 6), (7, 10).
Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно
P>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее
Быстрее чего?
P>, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее.
Быстрее чего?
P>Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Каких?
ЗЫ. MySQL не сможет много кого порвать по банальной причине: в нем тупо нельзя оптимизировать запросы. Почему? Потому что каждый из движков плевать хотел на любую из оптимизаций или любую их комбинацию. Из того, что помню:
— SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
— В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
В книжицах типа High Performance MySQL вообще много всяких веселостей написано по поводу этого гуана.
Здравствуйте, 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 этот запрос без всякого тюнинга отработал меньше чем за секунду.
Здравствуйте, sysenter, Вы писали
M>>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы P>>Бред, на майисам — при определенных делах — так, но на иннодб — ты не прав
S>А тут Mamut всё верно написал.
Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
P>да и —
M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса. M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
P>Бред, на майисам — при определенных делах — так,
Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
Здравствуйте, pzhy, Вы писали:
P>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
Кому тут смешно? Правильный джойн между инннобд и мемори разорвет любой большой БД. И это из опыта, а не маркетенгового булшита.
Здравствуйте, pzhy, Вы писали:
P>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
Здравствуйте, pzhy, Вы писали:
P>Кому тут смешно? Правильный джойн между инннобд и мемори разорвет любой большой БД. И это из опыта, а не маркетенгового булшита.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
_AB>Что такое "немыслимый результат"?
Это результат — который немыслемо достичь ни при каких условиях
P>б) ты утрируешь, что скорее всего. Да оптимизатор мускула — приметивен. Но если тебе надо много делать простых запросов — зачем тебе оверхед на оптимизаторе?
Все. На этом твои сказки про крутизну мускула заканчиваются.
Повторю. Ты достигаешь хорошей производительности после
после долгого и мучительного траха с поисками той самой правильной записи, которая сможет заставить полуоптимизатор запросов мускуля сегнирировать хоть близко вменяемый план запроса.
Все. Завязывай с наркотиками и перестань рассказывать про то, как в мускуле все раджуно
Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Здравствуйте, pzhy, Вы писали:
P>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
_AB>Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
Это ты дал "И неконкурентная работа в контексте СУБД никого не интересует." — бухаешь?
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Тут много говорят о том что мускул сосет при многих джойнах и т.д. Дайте скрипты сосдания таблиц, и ваши запросы? Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
_AB>Осталось дать формальное определение этого "во многом" и можно поспорить. И неконкурентная работа в контексте СУБД никого не интересует. Для этого простые файлы лучше подойдут.
В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
Здравствуйте, 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>Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной — инодб всеравно на некоторых запросах — сильно быстрее. Конечно он не для всего подходит — но во многом мускул — делает проприетарных колег — в разы.
Здравствуйте, pzhy, Вы писали:
P>Здравствуйте, Mamut, Вы писали:
P>да и —
M>>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса.
Тут походу ошибка, fullscan не будет.
M>>- В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы P>Бред, на майисам — при определенных делах — так, но на иннодб — ты не прав
Здравствуйте, pzhy, Вы писали:
P>В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
Здравствуйте, 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.
Как это не странно — но мне удается сводить 15 млн записей в день из индексов из мсскл2000(DTS), за 15 минут. А мсскл — не выкинули потомучто там действительно хорошие тулзы по дата майнинг, на мускуле вообще ничего по этому нет. Но что касается просто бд... Мускул на определенных запросах — рвет тотже мсскл — просто в разы. Это моя практика — хотя конечно чем больше конкурентных запросов — тем более мсскл догоняет. но и на 100 конкурентах не доганяет
Здравствуйте, pzhy, Вы писали:
НС>>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
P>однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
Ты попробуй повнимательнее прочесть то, что я написал. РСУБД не нацелены на рынок датамайнинга. Поэтому бессмысленно делать какие то выводы из их доли на этом рынке.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
P>>однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
НС>Ты попробуй повнимательнее прочесть то, что я написал. РСУБД не нацелены на рынок датамайнинга. Поэтому бессмысленно делать какие то выводы из их доли на этом рынке.
Вполне прочел. И да — согласен. Только вот для промежуточных данных — ничего лучше нет. И за перераспределение — в новые оох хранилища — никто платить не будет. а R позволяет делать все, тут и сейчас. Да кластеризация данных в нереляционные бд — рулит, но это дело будущего — данных тонны — а обрабатывать их надо сейчас. Т.е. — СУБД для дата майнинга — не очень хороши — да кто их спрашивает...
Здравствуйте, Mamut, Вы писали:
M>Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
Myisam — это считай что зашареный лоченый полностью(хотя это не так) сетевой мемори шаринг. Надо больше — иннобд, еще больше перфоманса — мемори, что в нем у тебя глючит? У меня почемуто ничео не глючит, и сервера на нем стоят — и не жужжат. Есть особенности — да. А где их нет?
Здравствуйте, pzhy, Вы писали:
P>Как это не смешно но мои подобные запросы на базе — где ежедневно +15 млн новых записей отрабатывают за секунды. А запросы апдейта за 10 минут где порядка 3-4 — милионов. Кстати его там сменили с мсскл 2000.
Здравствуйте, pzhy, Вы писали:
P>В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
Data mining не работает как правило на РСУБД. Если мы говорим про сектор enterprise и о больших объемах данных.
Данные поступают в том числе и из РСУБД, но хранятся и обрабатываются в других продуктах. Которые зачастую и продаются-то отдельно от СУБД. У Microsoft'a только исключение вроде как, если говорить о крупных игроках.
Здравствуйте, pzhy, Вы писали:
P>Как это не смешно но мои подобные запросы на базе — где ежедневно +15 млн новых записей отрабатывают за секунды. А запросы апдейта за 10 минут где порядка 3-4 — милионов. Кстати его там сменили с мсскл 2000.
А скажем объединения таблиц с использованием full text индекса имеются? Если нет то не считается.
M>>Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
P>Myisam — это считай что зашареный лоченый полностью(хотя это не так) сетевой мемори шаринг. Надо больше — иннобд, еще больше перфоманса — мемори, что в нем у тебя глючит? У меня почемуто ничео не глючит, и сервера на нем стоят — и не жужжат. Есть особенности — да. А где их нет?
Еще раз повторю. Оптимизатор MySQL'я не может проводить оптимизацию запросов, потому что он ничего не знает про особенности движков. То, что у тебя сервера стоят и не жужжат означают ровно одно: что ты провел дикое количество времени изучая разницу между движками и скрупулезно выискивая ту комбинацию запросов, для которой оптимизатор выдаст вменяемый план запросов.
Потому что в чем ращница между двумя следующими селектами?
--- индекс по полю aSELECT a, b FROM t
SELECT b, а FROM t
Разница между ними нулевая. Но только вот в mysql второй запрос может спокойно вылитсья в fullscan таблицы. И ты называешь это плюсом
Здравствуйте, Mamut, Вы писали:
M> — В запросе поля, для которых есть индексы, надо писать в первую очередь, потому что оптимизатор не умеет их определять и выносить вперед, что может привести к фуллскану таблицы даже несмотря на все индексы
Это ты чего-то не то вспомнил. Если ты имеешь ввиду coverage индексы, то это немного не так выглядит.
Здравствуйте, pzhy, Вы писали:
p> M>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса. p> Это бред — причем бред какойто нереальный....
Нет, это не бред. На движке InnoDB запрос SELECT COUNT(*) без WHERE приведет к полному сканированию индекса или таблицы (если индекса нет), что при большом количестве записей может быть очень долго. Для MyISAM подсчет количества записей без WHERE оптимизирован. С WHERE оба движка ведут себя одинаково — выбирают диапазон.
С другой стороны, смысла в таком подсчете строк нет, по этому это не напрягает.
Здравствуйте, Anton Batenev, Вы писали:
p>> M>- SELECT COUNT(*) на InnoDB (или на MyISAM? Неважно) вызовет fullscan таблицы даже при наличии primary индекса. p>> Это бред — причем бред какойто нереальный....
AB>Нет, это не бред. На движке InnoDB запрос SELECT COUNT(*) без WHERE приведет к полному сканированию индекса или таблицы (если индекса нет), что при большом количестве записей может быть очень долго. Для MyISAM подсчет количества записей без WHERE оптимизирован. С WHERE оба движка ведут себя одинаково — выбирают диапазон.
AB>С другой стороны, смысла в таком подсчете строк нет, по этому это не напрягает.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, pzhy, Вы писали:
p>> Мой опыт говорит о том что при неконкурентной работе мускул много быстрее, при конкурентной AB>А SQLite при дополнительных условиях порвет MySQL раз в 10, но это же ни о чем не говорит — у каждого своя ниша.
embeded mysql — врядли, а boost::multi_index — порвет всех, Это не ниша — а определенный спектр.
Здравствуйте, Mamut, Вы писали:
M>>>Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
P>>Myisam — это считай что зашареный лоченый полностью(хотя это не так) сетевой мемори шаринг. Надо больше — иннобд, еще больше перфоманса — мемори, что в нем у тебя глючит? У меня почемуто ничео не глючит, и сервера на нем стоят — и не жужжат. Есть особенности — да. А где их нет?
M>Еще раз повторю. Оптимизатор MySQL'я не может проводить оптимизацию запросов, потому что он ничего не знает про особенности движков. То, что у тебя сервера стоят и не жужжат означают ровно одно: что ты провел дикое количество времени изучая разницу между движками и скрупулезно выискивая ту комбинацию запросов, для которой оптимизатор выдаст вменяемый план запросов.
M>Потому что в чем ращница между двумя следующими селектами? M>
M>--- индекс по полю a
M>SELECT a, b FROM t
M>SELECT b, а FROM t
M>
M>Разница между ними нулевая. Но только вот в mysql второй запрос может спокойно вылитсья в fullscan таблицы. И ты называешь это плюсом
а) ты реально веришь в то что пишешь. Данный вариант будет одинаково работать и на иннобд и майисам.
б) ты утрируешь, что скорее всего. Да оптимизатор мускула — приметивен. Но если тебе надо много делать простых запросов — зачем тебе оверхед на оптимизаторе?
Да и на мсскл — оптимизатор — действительно крут. Что есь, то есть. А вот у оракла — может такую фигню придумать — что изголяться приходится почище мускула, но это редко
Здравствуйте, DarthSidius, Вы писали:
DS>Здравствуйте, pzhy, Вы писали:
P>>Кому тут смешно? Правильный джойн между инннобд и мемори разорвет любой большой БД. И это из опыта, а не маркетенгового булшита.
DS>А теперь расскажи нам про транзакции в мыскле.
На иннобд — все нормально. На майисам — их просто нет
Здравствуйте, pzhy, Вы писали:
P>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Здравствуйте, pzhy, Вы писали:
P>>>Дайте скрипты сосдания таблиц, и ваши запросы?
RO>>Дано: таблица Отрезок (a integer, b integer).
RO>>Найти: объединение всех отрезков (в том же виде, только записей будет меньше).
RO>>Например, (1, 2), (3, 6), (4, 5), (7, 9), (8, 10) → (1, 2), (3, 6), (7, 10).
P>Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно
Всем кто смеется — привидите запрос — с обработкой отридцательных чисел хотя бы
M>>Все. Завязывай с наркотиками и перестань рассказывать про то, как в мускуле все раджуно
P>Зачем, меня прет. Нет не радужно — но это иструмент — и очень хороший для своих целей инструмент
Угу, угу. И считаешь примитивный оптимизатор и дикое количество движков, каждый со своими глюками, плюсами. Завязывай с наркотиками.
Здравствуйте, Mamut, Вы писали:
P>>Зачем, меня прет. Нет не радужно — но это иструмент — и очень хороший для своих целей инструмент
M>Угу, угу. И считаешь примитивный оптимизатор и дикое количество движков, каждый со своими глюками, плюсами. Завязывай с наркотиками.
Не веришь что есть задачи где только на мускуле можно сделать? У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...
P>>>Зачем, меня прет. Нет не радужно — но это иструмент — и очень хороший для своих целей инструмент
M>>Угу, угу. И считаешь примитивный оптимизатор и дикое количество движков, каждый со своими глюками, плюсами. Завязывай с наркотиками.
P>Не веришь что есть задачи где только на мускуле можно сделать?
Не верю. Потому что в мускуле нет ничего особенного или специального.
P>У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...
Ты так и не предоставил ни единого доказательства слива, кроме громких заявлений о том, что примитивный оптимизатор — это круто.
Здравствуйте, pzhy, Вы писали:
RO>>>Дано: таблица Отрезок (a integer, b integer). RO>>>Найти: объединение всех отрезков (в том же виде, только записей будет меньше). RO>>>Например, (1, 2), (3, 6), (4, 5), (7, 9), (8, 10) → (1, 2), (3, 6), (7, 10).
P>>Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно P>Всем кто смеется — привидите запрос — с обработкой отридцательных чисел хотя бы
На коленке как-то так: select y x, lead(x) over(order by x) y from (select x, s, sum(s) over(order by x,s) c, lead(x) over(order by x,s) y from (select min(a) x, 0 s from intervals union select a, 1 from intervals union select b, -1 from intervals) t) t where c=0;
Здравствуйте, pzhy, Вы писали:
DS>>А теперь расскажи нам про транзакции в мыскле.
P>На иннобд — все нормально. На майисам — их просто нет
Ух ты. Все нормально? ACID и все такое? http://lj.rossia.org/users/silly_sad/289700.html
"просто потому что в MySQL всё через жопу и транзакйи там НЕТ, там вместо транзакций просто к жопе дверца приделана."
Это я в гугле по быстрому нашел. А так зайди в форум db и задай вопрос "Почему MySQL УГ и почему его транзакции УГ?" и тебе там разобьют твои розовые очки
Здравствуйте, Roman Odaisky, Вы писали:
RO>На коленке как-то так: select y x, lead(x) over(order by x) y from (select x, s, sum(s) over(order by x,s) c, lead(x) over(order by x,s) y from (select min(a) x, 0 s from intervals union select a, 1 from intervals union select b, -1 from intervals) t) t where c=0;
Э-э-э... А оно не звоняется часом от немедленной смерти?
Здравствуйте, Anton Batenev, Вы писали:
DS>> http://lj.rossia.org/users/silly_sad/289700.html DS>> "просто потому что в MySQL всё через жопу и транзакйи там НЕТ, там вместо транзакций просто к жопе дверца приделана."
AB> По ссылке одни эмоции и ноль конструктива. MySQL не имеет никакого отношения к исключениям в фреймворке yii.
Да, я в курсе (к слову, по приведенной ссылке этой цитаты больше нет). Но у них и раньше был достаточно стабильный релизный цикл, где правились баги, вводились фитчи — продукт живет и достаточно прочно занимает свою нишу.
Здравствуйте, Anton Batenev, Вы писали:
AB>Да, я в курсе (к слову, по приведенной ссылке этой цитаты больше нет). Но у них и раньше был достаточно стабильный релизный цикл, где правились баги, вводились фитчи — продукт живет и достаточно прочно занимает свою нишу.
Здравствуйте, DarthSidius, Вы писали:
DS>Здравствуйте, pzhy, Вы писали:
P>>Что такое "полному сканированию индекса"?
DS>Уууу. Как все запущено... Учи матчасть. И поверь более опытным товарищам: мыскль — УГ полное.
Я знаю что это такое, был немного пьян. Я думаю с каждым бывает.
Здравствуйте, LuciferArh, Вы писали:
LA>Здравствуйте, pzhy, Вы писали:
P>>embeded mysql — врядли, а boost::multi_index — порвет всех, Это не ниша — а определенный спектр.
LA>А кроме упертости другие доказательства будут?
Да — опыт — того где мсскл выкинули — и вставили мускул. Порядка 100000 простых запросов в час, от 100 клиентов.
Здравствуйте, DarthSidius, Вы писали:
DS>Ух ты. Все нормально? ACID и все такое? DS>http://lj.rossia.org/users/silly_sad/289700.html DS>"просто потому что в MySQL всё через жопу и транзакйи там НЕТ, там вместо транзакций просто к жопе дверца приделана."
DS>Это я в гугле по быстрому нашел. А так зайди в форум db и задай вопрос "Почему MySQL УГ и почему его транзакции УГ?" и тебе там разобьют твои розовые очки
Не знаю, что там у вас гуугле у меня все нормально. И там где надо работает. А вот тебе вопрос — сможежб апдейт на 300 милионов эффективных записей сделать за 10 минут? Да пускай они будут нерелявантны индексам — мне не важно, но надо что бы так.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, pzhy, Вы писали:
RO>>>>Дано: таблица Отрезок (a integer, b integer). RO>>>>Найти: объединение всех отрезков (в том же виде, только записей будет меньше). RO>>>>Например, (1, 2), (3, 6), (4, 5), (7, 9), (8, 10) → (1, 2), (3, 6), (7, 10).
P>>>Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно P>>Всем кто смеется — привидите запрос — с обработкой отридцательных чисел хотя бы
RO>На коленке как-то так: select y x, lead(x) over(order by x) y from (select x, s, sum(s) over(order by x,s) c, lead(x) over(order by x,s) y from (select min(a) x, 0 s from intervals union select a, 1 from intervals union select b, -1 from intervals) t) t where c=0;
RO>(реальная задача была похожая, но другая
Здравствуйте, Mamut, Вы писали:
M>Не верю. Потому что в мускуле нет ничего особенного или специального.
Есть быстрая отработка простых запросов, у меня 300 клиентов — сканят базу раз в 3 секунды. Да криво — но я немогу это поменять. Мсскл — дохнет мускул живет — и дает другим процессам жить
P>>У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...
M>Ты так и не предоставил ни единого доказательства слива, кроме громких заявлений о том, что примитивный оптимизатор — это круто.
Здравствуйте, Mamut, Вы писали:
M>[скипнут примитивный запрос]
Лукавишь чуть-чуть. Запрос как раз — при правильном подборе rm.members_id = @mId and rm.companys_id = @companyId — способен загрузить сервер по самое нимагу.
С другой стороны, человек, который рассказывает о том что
UNIX_TIMESTAMP(rm.last_try_time) + if(rm.try_timeout is null, @companyTryTimeout, rm.try_timeout) < UNIX_TIMESTAMP(now())
— выполняется 10мс на миллионных таблицах — явно лжец.
Здравствуйте, LuciferArh, Вы писали:
P>>Да — опыт — того где мсскл выкинули — и вставили мускул. Порядка 100000 простых запросов в час, от 100 клиентов.
LA>Поток сознания детектед. (с)
LA>Где доказательства, а?
Здравствуйте, pzhy, Вы писали:
P>В чем? Разве я сказал что противопостовляю мускул ораклу? Это смешно, но в некоторых задачах — мускул лучше, иначебы оракл не купил сан.
Нда... Всё ясно...
Кстати, Вам сегодня еще в НАТО надо заглянуть. За заверением.
Здравствуйте, pzhy, Вы писали:
P>Я знаю что это такое, был немного пьян. Я думаю с каждым бывает.
Только далеко не каждый при этом пишет на rsdn. А которые таки пишут — быстро оказываются в бане и избавляют общество от своего навязчивого присутствия.
