Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Датамайнинг это слабоструктурированные и неструктурированные данные. Для их хранения реляционные СУБД действительно сильно избыточны. РСУБД предназначены для активно изменяющихся многими пользователями и хорошо структурированных данных.
P>>однако R завоевывает позиции — и уже держит треть рынка, вполне над субд. И он убивает проприетарные утилитные языки в усмерть
НС>Ты попробуй повнимательнее прочесть то, что я написал. РСУБД не нацелены на рынок датамайнинга. Поэтому бессмысленно делать какие то выводы из их доли на этом рынке.
Вполне прочел. И да — согласен. Только вот для промежуточных данных — ничего лучше нет. И за перераспределение — в новые оох хранилища — никто платить не будет. а R позволяет делать все, тут и сейчас. Да кластеризация данных в нереляционные бд — рулит, но это дело будущего — данных тонны — а обрабатывать их надо сейчас. Т.е. — СУБД для дата майнинга — не очень хороши — да кто их спрашивает...
Здравствуйте, Mamut, Вы писали:
M>Если так, то это не бред. Я же сказал, что не помню, для какого движка. Бред — это защищать эту поделку, которая даже не может воспользоваться индексами для простейших запросов.
Myisam — это считай что зашареный лоченый полностью(хотя это не так) сетевой мемори шаринг. Надо больше — иннобд, еще больше перфоманса — мемори, что в нем у тебя глючит? У меня почемуто ничео не глючит, и сервера на нем стоят — и не жужжат. Есть особенности — да. А где их нет?
Здравствуйте, pzhy, Вы писали:
P>Как это не смешно но мои подобные запросы на базе — где ежедневно +15 млн новых записей отрабатывают за секунды. А запросы апдейта за 10 минут где порядка 3-4 — милионов. Кстати его там сменили с мсскл 2000.
Здравствуйте, pzhy, Вы писали:
P>В плане того что весь дата манинг — работает на данных которые обычно в данный момент не нужны
Data mining не работает как правило на РСУБД. Если мы говорим про сектор enterprise и о больших объемах данных.
Данные поступают в том числе и из РСУБД, но хранятся и обрабатываются в других продуктах. Которые зачастую и продаются-то отдельно от СУБД. У Microsoft'a только исключение вроде как, если говорить о крупных игроках.
Здравствуйте, pzhy, Вы писали:
P>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
Здравствуйте, pzhy, Вы писали:
P>Кому тут смешно? Правильный джойн между инннобд и мемори разорвет любой большой БД. И это из опыта, а не маркетенгового булшита.
Здравствуйте, 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 — порвет всех, Это не ниша — а определенный спектр.
Здравствуйте, 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).
Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно
Здравствуйте, 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>А теперь расскажи нам про транзакции в мыскле.
На иннобд — все нормально. На майисам — их просто нет
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, pzhy, Вы писали:
P>>Инобд — вполне умеет себе нормально оптимизировать. Но прелесть мускула в том что можно комбинировать движки, да это сложно, но можно получить такой результат — кот на больших бд не мыслим. да надо понимать как это работает
_AB>Что такое "немыслимый результат"?
Это результат — который немыслемо достичь ни при каких условиях
Здравствуйте, 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>Влом думать о алгоритмах поверх скл. Покажите запрос который у вас тормазит — и я скажу — можно ли на мускуле сделать его также эффективно
Всем кто смеется — привидите запрос — с обработкой отридцательных чисел хотя бы
