[freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Отвечу цитатой quote При выборке в секции SELECT требуется дополнительное время на слияние основной выборки и подзапроса. Вышло 1% от общего времени.(+ LEFT JOIN / - SELECT) Оказалось, что каждый LEFT JOIN выполняется отдельным потоком! В то время как подзапросы выполняются последовательно после основной выборки. (+ LEFT JOIN / - SELECT) Каждый LEFT JOIN объединяется в результирующую выборку, что требует дополнительной памяти. В то время как подзапрос вернет нам одно значение на каждую строку, т.е. для получения результата нам нужно меньше памяти. (- LEFT JOIN / + SELECT) Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые преимущества /quote 07 февраля 2012, 01:07 от Alex Korchmar 4spa...@linux.e-moe.ru: On Tue, Feb 07, 2012 at 12:38:51AM +0400, Sergey Rudenko wrote: Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы каким методом сделать select без join и тупо отфильтровать нужное? Идея что фронтендов вы можете понапихать до бесконечности, если они не справляются с сортировкой, а добавить еще одно процессорное ядро в сервер с БД может оказаться уже физически неодолимой задачей. Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы или были нужны крайне редко (в том числе - отказываясь от нормализации и дублируя часть данных, диски и линки нынче дешевы, cpu не совсем). Редкие операции выносятся на отдельный сервер и во время тихое. Alex
[freebsd] Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 10:26 пользователь Sergey Rudenko sergey_rude...@bk.ru написал: Отвечу цитатой quote Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые преимущества /quote sarcasmА мужики в FB не знают.../sarcasm :) Тогда вопрос - чего ж тогда такой бум NoSQL сейчас? В них тоже джойнов нет, и особой серверной логики тоже - максимум примитивы, типа SORT
Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 12:26:39PM +0400, Sergey Rudenko wrote: Отвечу цитатой А из чего цитата? А то оно как-то резко расходится со здравым смыслом и реальностью данной в ощущениях. Если, как подсказывает гугель, http://skahin.blogspot.com/2009/10/left-join-select.html - то там логотип ms sql как бе намекает... ну и я говорил не о синтаксической, а о логической замене join'ов. Вы, похоже, так и не поняли. Alex
Re: [freebsd] Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 10:35:40AM +0200, Denis Zhdanov wrote: sarcasmА мужики в FB не знают.../sarcasm :) Тогда вопрос - чего ж тогда такой бум NoSQL сейчас? ну типа, кризис, становятся модными системы из говн...зачеркнуто, облачные структуры... В них тоже джойнов нет, и особой серверной логики тоже - максимум примитивы, типа SORT зато сервера получаются дешевые и много. Alex
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 22:49 пользователь Алексей Бобок alexey.bo...@gmail.com написал: Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать. Расскажите это разрабочтикам на труъ ынтырпрайз оракуле, которые бОльшую часть логики пишут в БД, и оно там как-то работает.
[freebsd] Re[2]: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Я вас правильно понял, просто селект в данном случае тот-же джоин. Не думаю, что в ФБ они заменили джоины на селекты и этим добились большей производительности Специально протестировал на mysql таблица 4 записей, большей под рукой сейчас нет Первое значение это первый запрос, второе после того как он закешировался select thread_name, (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) from forum_t SQL запросов: 1, время mysql: 0.538739, всего затрачено: 0.615614 секунд !Процент времени на MySQL: 87.51% SQL запросов: 1, время mysql: 0.013977, всего затрачено: 0.089507 секунд !Процент времени на MySQL: 15.62% SELECT forum_t.thread_name, forum.forum_name FROM forum_t LEFT JOIN forum ON(forum_id = thread_forum_id) SQL запросов: 1, время mysql: 0.301786, всего затрачено: 0.368958 секунд !Процент времени на MySQL: 81.79% SQL запросов: 1, время mysql: 0.013766, всего затрачено: 0.082863 секунд !Процент времени на MySQL: 16.61% 07 февраля 2012, 12:37 от Alex Korchmar 4spa...@linux.e-moe.ru: On Tue, Feb 07, 2012 at 12:26:39PM +0400, Sergey Rudenko wrote: Отвечу цитатой А из чего цитата? А то оно как-то резко расходится со здравым смыслом и реальностью данной в ощущениях. Если, как подсказывает гугель, http://skahin.blogspot.com/2009/10/left-join-select.html - то там логотип ms sql как бе намекает... ну и я говорил не о синтаксической, а о логической замене join'ов. Вы, похоже, так и не поняли. Alex
Re: [freebsd] Re[2]: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote: Я вас правильно понял, повторяю: вы ничего не поняли. просто селект в данном случае тот-же джоин. именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже автооптимизирующийся. Ну так не делайте таких селектов. select thread_name, (SELECT forum_name FROM forum WHERE forum_id = thread_forum_id) from forum_t напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. Дальше два варианта - либо вы фронтендом вручную сортируете результат, если его немного, это неудобно программировать зато фронтендов может быть много, либо меняете структуру базы данных - складываете свой 'forum_name' в forum_t, и забываете всю глубокомысленную ерунду которой вас учили в институте. Целостность данных придется поддерживать либо триггером, либо опять же фронтендом, ничего особенно ужасного в этом, обычно, нет. Alex
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Сорри, отсутствовал. 2Sergey Rudenko Неужели БД тупее приложения будет? Не тупее, но у грузовика задача перевозить много картофеля, а у мазерати быстро до сотни разгоняться. БД пусть хранит и выбирает данные, т.е. то под что она оптимизирована. 2Alex Korchmar Я работаю с клиентами у которых бюджет ограничен и которые понимают что такое управление рисками, и не афиллирован с конторами по впариванию железа (увы ;-) Работайте. Дайте Ваш контакт в личку - буду давать при случае. Кстати, я не аффилирован ни с кем. Я даю ТТХ, а заказчик закупает сам в удобных ему местах. Просто я не вкладываю свой интерес в железо и не занижаю стоимость своей работы) Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы Именно так. 2Sayetsky Anton Расскажите это разрабочтикам на труъ ынтырпрайз оракуле, которые бОльшую часть логики пишут в БД, и оно там как-то работает. Без разницы какая БД. Разница в том КАК оно в итоге работает и сколько ресурсов требует. 2Alex Samorukov Я, конечно, не модератор - но друзья, при чём тут BSD? Для этого есть множество sql и non-sql форумов. Алекс(-ей,-андр?), Вы абсолютно правы. Просто коллегу возмутило, что кто-то зарабатывает деньги, требуя нормальное железо и сам выбирает себе заказчиков, а кто-то работает со всеми подряд. -- Think before you print. Best regards, Alexey Bobok.
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 16:58 пользователь Sayetsky Anton vsj...@gmail.com написал: 6 февраля 2012 г. 16:57 пользователь skeletor skele...@lissyara.su написал: Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее полная копия работающего сервера с БД. mysql + drbd + heartbeat Или dual-direction replication, но говорят, что оно не работает. Вдогонку: Ежели фря - mysql + hast + heartbeat
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
ИМХО справочники - относилось к ФБ Если они не используют там join то вывод один - это справочники, которые не такие и большие А на чем основное крутится совсем не понятно 06 февраля 2012, 21:14 от Denis Zhdanov denis.zhda...@gmail.com: 6 февраля 2012 г. 19:07 пользователь Sergey Rudenko sergey_rude...@bk.ru написал: Не оффтопа ради, а ради спаведливости ФБ MySQL -- используется как хранилище пар ключ-значение, никаких join'ов А кто спорит? Вопрос был о больших базах на мускуле. Ответ - они есть и юзаются. ИМХО справочники ВК Собственная СУБД на C, созданная лучшими умами России С ВК все непонятно, как я уже и говорил. Я уже молчу, что это всё из проверенных источникофф ))) Ну тут вопрос - верить или не верить самим разработчикам сервисов. В отличие от ВК западные девы архитектуру не скрывают - инфы в Инете полно, на Insight-IT она просто собрана в одном месте. Вот еще инфа к размышлению - http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc (Adam D'Angelo - бывший техдир ФБ)
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 19:21 пользователь Sergey Rudenko sergey_rude...@bk.ru написал: ИМХО справочники - относилось к ФБ Если они не используют там join то вывод один - это справочники, которые не такие и большие А на чем основное крутится совсем не понятно Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, которые являются основным хранилищем данных ФБ, несмотря на то что они не используют join и используют ее только как справочник - это именно то основное, на чем оно и крутится. Аналогичная ситуация в Твиттере и Википедии - у них тысячи серверов с MySQL и размер каждой БД вполне сравним с десятками Гб - имхо не такие уж это и космические цифры, при современной то технике - особенно если джойны то не использовать...
[freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, которые являются основным хранилищем данных ФБ, несмотря на то что они не используют join и используют ее только как справочник - это именно то основное, на чем оно и крутится. Использовать join и rlike и вообще производить сложные вычисления посредством БД - это плохо. Это прошлый век и это на нагрузке приведет к тому, что БД остановится на процессоре. В частности, потому, что очень во многих случаях лавочку можно смело закрывать, если она встанет на то время, которое занимает восстановление с такого бэкапа О_о А нормальная система с бэкапами и фэйловером стоит у вас, скажем - пять, которые надо вырвать из бизнеса немедленно, навсегда, и еще и доливать по мере роста Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то. Потому мои клиенты или покупают то, что я говорю или идут к другому специалисту, который потом создает триды в рассылках типа помогите восстановить.. , как без простоя внедрить... и т.д. А вообще, так как этот оффтоп на 50 писем спровоцировал походу я, потому я же и предлагаю закончить. Все равно все при своем мнении остануться) А к топикстартеру просьба рассказать, чем закончилось для будущих поколений. PS Пользуясь случаем, предаю поздравления Бобу Марли) -- Think before you print. Best regards, Alexey Bobok.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то. Потому мои клиенты или покупают то, что я говорю или идут к другому хорошо, можете смело давать им мой адрес. Я работаю с клиентами у которых бюджет ограничен и которые понимают что такое управление рисками, и не афиллирован с конторами по впариванию железа (увы ;-) (я, правда, очень не люблю клиентов с freebsd и mysql, но вдруг кому-то повезет) специалисту, который потом создает триды в рассылках типа помогите восстановить.. , как без простоя внедрить... и т.д. Если это в конечном итоге решает их проблему - значит вы нагрели тех кто купил что вы говорите, вероятно, дважды - сперва они зазря заплатили более дорогому специалисту, а потом еще и за более дорогие лекарства которые он прописал. Если вдруг опаньки - это был их риск, бизнес без риска не бывает. И, поверьте, есть еще такие, которые просто знают, как. Поскольку вопросов в рассылках они не задают, вы о них не в курсе. Alex
Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 12:38:51AM +0400, Sergey Rudenko wrote: Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы каким методом сделать select без join и тупо отфильтровать нужное? Идея что фронтендов вы можете понапихать до бесконечности, если они не справляются с сортировкой, а добавить еще одно процессорное ядро в сервер с БД может оказаться уже физически неодолимой задачей. Ну или делать такую структуру тазы банных, чтобы ей не были нужны join'ы или были нужны крайне редко (в том числе - отказываясь от нормализации и дублируя часть данных, диски и линки нынче дешевы, cpu не совсем). Редкие операции выносятся на отдельный сервер и во время тихое. Alex
