Re[4]: mysql
От: pzhy  
Дата: 21.06.12 19:44
Оценка:
Здравствуйте, LuciferArh, Вы писали:

LA>Здравствуйте, pzhy, Вы писали:


P>>embeded mysql — врядли, а boost::multi_index — порвет всех, Это не ниша — а определенный спектр.


LA>А кроме упертости другие доказательства будут?


Да — опыт — того где мсскл выкинули — и вставили мускул. Порядка 100000 простых запросов в час, от 100 клиентов.
Re[9]: mysql
От: pzhy  
Дата: 21.06.12 19:48
Оценка:
Здравствуйте, DarthSidius, Вы писали:

DS>Ух ты. Все нормально? ACID и все такое?

DS>http://lj.rossia.org/users/silly_sad/289700.html
DS>"просто потому что в MySQL всё через жопу и транзакйи там НЕТ, там вместо транзакций просто к жопе дверца приделана."

DS>Это я в гугле по быстрому нашел. А так зайди в форум db и задай вопрос "Почему MySQL УГ и почему его транзакции УГ?" и тебе там разобьют твои розовые очки


Не знаю, что там у вас гуугле у меня все нормально. И там где надо работает. А вот тебе вопрос — сможежб апдейт на 300 милионов эффективных записей сделать за 10 минут? Да пускай они будут нерелявантны индексам — мне не важно, но надо что бы так.
Re[5]: mysql
От: pzhy  
Дата: 21.06.12 19:49
Оценка:
Здравствуйте, 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>(реальная задача была похожая, но другая
Автор: Roman Odaisky
Дата: 27.05.08
)


Завтра отпишу, сейчас нет сил думать.
Re[12]: mysql
От: pzhy  
Дата: 21.06.12 19:56
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Не верю. Потому что в мускуле нет ничего особенного или специального.


Есть быстрая отработка простых запросов, у меня 300 клиентов — сканят базу раз в 3 секунды. Да криво — но я немогу это поменять. Мсскл — дохнет мускул живет — и дает другим процессам жить

P>>У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...


M>Ты так и не предоставил ни единого доказательства слива, кроме громких заявлений о том, что примитивный оптимизатор — это круто.


ну вот например:
"select "
"m.id,"
"rm.status,"
"m.dial_number1,"
"m.dial_number2,"
"m.dial_number3,"
"m.dial_number4,"
"m.dial_number5,"
"m.data1,"
"m.data2,"
"m.data3,"
"m.data4,"
"m.data5,"
"rm.data1,"
"rm.data2,"
"rm.data3,"
"rm.data4,"
"rm.data5,"
"rm.max_tries,"
"rm.is_monitoring,"
"rm.dial_time,"
"rm.try_timeout,"
"rm.id,"
"rm.dial_mode,"
"rm.scenarios_id "
"from "
"refinements_members rm,"
"members m "
"where "
"rm.members_id = m.id and "
"rm.companys_id = " << company_->id_ << " and " <<
"((rm.status) = " << not_started <<
" or "
"( "
"(rm.status = " << noanswer << " or rm.status = " << mismatch << ") "
"and "
"( "
"UNIX_TIMESTAMP(rm.last_try_time) + if(rm.try_timeout is null, " << company_->try_timeout_ << ", rm.try_timeout) < UNIX_TIMESTAMP(now()) "
") "
"and "
"( "
"( "
"rm.try_counter < if(rm.max_tries is null, " << company_->max_member_tries_ << ",rm. max_tries) "
") "
"or "
"( "
"0 = if(rm.max_tries is null, " << company_->max_member_tries_ << ", rm.max_tries) "
") "
") "
")) "
"order by rm.status "
"limit " << num_of_possible_dials_,

Это из кода с++, но, отрабатывет на полумилионе запизей за 10 милисикунд. Мсскл — порядка 2 секунд.
Re[13]: mysql
От: Mamut Швеция http://dmitriid.com
Дата: 21.06.12 21:17
Оценка: +3
M>>Не верю. Потому что в мускуле нет ничего особенного или специального.

P>Есть быстрая отработка простых запросов, у меня 300 клиентов — сканят базу раз в 3 секунды. Да криво — но я немогу это поменять. Мсскл — дохнет мускул живет — и дает другим процессам жить


Если запросы простые, то что-то неправильно с запросами.

P>>>У меня они есть, правда. Я бы его не использовал — воркбенч — уг. Но просто на определенных задачах все остальное сливает в разы, и приходится — альтернотивы нет...


M>>Ты так и не предоставил ни единого доказательства слива, кроме громких заявлений о том, что примитивный оптимизатор — это круто.


[скипнут примитивный запрос]

P>Это из кода с++, но, отрабатывет на полумилионе запизей за 10 милисикунд. Мсскл — порядка 2 секунд.


Это скорее всего значит, что где-то в mssql неверно проставлены индексы или неверно настроена база данных. Ничего особенного в этом запросе не вижу.


dmitriid.comGitHubLinkedIn
Re[14]: mysql
От: fddima  
Дата: 21.06.12 22:05
Оценка:
Здравствуйте, 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мс на миллионных таблицах — явно лжец.
Re[5]: mysql
От: LuciferArh Россия  
Дата: 22.06.12 04:28
Оценка:
Здравствуйте, pzhy, Вы писали:

P>Да — опыт — того где мсскл выкинули — и вставили мускул. Порядка 100000 простых запросов в час, от 100 клиентов.


Поток сознания детектед. (с)

Где доказательства, а?
... << RSDN@Home 1.2.0 alpha 5 rev. 52>>
Re[6]: mysql
От: pzhy  
Дата: 25.06.12 17:12
Оценка:
Здравствуйте, LuciferArh, Вы писали:

P>>Да — опыт — того где мсскл выкинули — и вставили мускул. Порядка 100000 простых запросов в час, от 100 клиентов.


LA>Поток сознания детектед. (с)


LA>Где доказательства, а?


Вам натореально заверенные? Мой опыт
Re[7]: mysql
От: LuciferArh Россия  
Дата: 25.06.12 17:34
Оценка:
Здравствуйте, pzhy, Вы писали:

P>Вам натореально заверенные?


Ну, если аж НАТО РЕАЛЬНО заверит, то, пожалуй, сойдет...

P>Мой опыт


И что? А мой опыт говорит, что у Oracle все равно длиннее и толще.
... << RSDN@Home 1.2.0 alpha 5 rev. 52>>
Re[8]: mysql
От: pzhy  
Дата: 25.06.12 17:39
Оценка:
Здравствуйте, LuciferArh, Вы писали:

LA>И что? А мой опыт говорит, что у Oracle все равно длиннее и толще.


В чем? Разве я сказал что противопостовляю мускул ораклу? Это смешно, но в некоторых задачах — мускул лучше, иначебы оракл не купил сан.
Re[9]: mysql
От: lazymf Россия  
Дата: 25.06.12 18:15
Оценка:
Здравствуйте, pzhy, Вы писали:

P>но в некоторых задачах — мускул лучше, иначебы оракл не купил сан.


???
Re[10]: mysql
От: lazymf Россия  
Дата: 25.06.12 18:17
Оценка:
Здравствуйте, lazymf, Вы писали:

P>>но в некоторых задачах — мускул лучше, иначебы оракл не купил сан.


Поясню. Вы правда думаете, что оракл купил сан ради мускуля?
Re[6]: mysql
От: Visor2004  
Дата: 26.06.12 14:36
Оценка:
Здравствуйте, pzhy, Вы писали:

P>Завтра отпишу, сейчас нет сил думать.


Это слив? или все же силы подумать найдуццо?
Помните!!! ваш говнокод кому-то предстоит разгребать.
Re[9]: mysql
От: _ABC_  
Дата: 26.06.12 16:47
Оценка:
Здравствуйте, pzhy, Вы писали:

P>В чем? Разве я сказал что противопостовляю мускул ораклу? Это смешно, но в некоторых задачах — мускул лучше, иначебы оракл не купил сан.


Нда... Всё ясно...
Кстати, Вам сегодня еще в НАТО надо заглянуть. За заверением.
Re[7]: mysql
От: Ночной Смотрящий Россия  
Дата: 26.06.12 20:01
Оценка:
Здравствуйте, pzhy, Вы писали:

P>Я знаю что это такое, был немного пьян. Я думаю с каждым бывает.


Только далеко не каждый при этом пишет на rsdn. А которые таки пишут — быстро оказываются в бане и избавляют общество от своего навязчивого присутствия.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.