[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.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 14:18, skeletor wrote: 06.02.2012 14:10, Anton Yuzhaninov пишет: Чтобы получить работающий slave, надо сначала получить dump мастера. Именно! Вот как раз и в этом состоит и проблема. Остановить базу, сделать копию на уровне ФС, запустьть базу, вылить копию на слэйв. Если остановка базы на пол часа неприемлема - залочить базу на запись, и проделать то же самое что выше.
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
так если есть винт с базой зачем тогда мускуль поднимать и что-то еще - файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд On Mon, Feb 06, 2012 at 04:28:31PM +0400, Anton Yuzhaninov wrote: On 02/06/12 16:18, skeletor wrote: 06.02.2012 14:10, Anton Yuzhaninov пишет: Чтобы получить работающий slave, надо сначала получить dump мастера. Именно! Вот как раз и в этом состоит и проблема. Как она решается в треде уже написано. Напишу более подробно. 1. Включть в mysql заись binary log Проверить через show master status, что логи пишутся. 1. в mysql FLUSH TABLES WITH READ LOCK; SHOW MASTER STATUS 2. В OS sync sleep 5 делаем ZFS snapshot (или gmirror remove если нет ZFS) 3. в mysql UNLOCK TABLES 4. Копируем данные из папки снапшота на будущий слейв. Это может идти долго, но будущий мастер в этот момент работает, даунтайма нет. Чтобы копироание не грузило диски, можно использовать scp -l 5. На будущем слейве запускает mysql и выполняем команду CHANGE MASTER TO master_host=master.example.ru, master_user=usr_repl, master_password=xxx, master_log_file=master-bin.000123, master_log_pos=12345; где имя лога и позицию в нем, указываем как показал SHOW MASTER STATUS при создании снапшота. После этого слейв начнем медленно догонять мастер. Если на мастере шла активная запись, то догонять будет долго, но на работу мастера это не влияет, нагрузка от наличия слейва будет очень небольшая. Прогресс смотреть по SHOW SLAVE STATUS. После того как слейв догонит, на нем можно делать бэкапы с помощью mysqldump и мучить его другими способами. -- Anton Yuzhaninov -- --- Vasiliy P. MelnikVPM-UANIC
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
06.02.2012 16:46, Vasiliy P. Melnik пишет: На сервере 2 винта? А какое отношение имеет количество винтов на сервере к выходу сервера из строя? Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее полная копия работающего сервера с БД.
[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 - бывший техдир ФБ)
Re: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 6 Feb 2012 18:17:32 +0200 Sayetsky Anton vsj...@gmail.com wrote: 6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik ba...@vpm.net.ua написал: может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны да ладно;-) # du -hs /var/lib/mysql/ 92G /var/lib/mysql/ Работает, не чешется. сколько из 92Г весят бинлоги, например?:) раз уж мерянья начались, машинка, которую трогать страшно: archive-db# du -shx /var/db/mysql/ 147G/var/db/mysql/ archive-db# ll -h /var/db/mysql/ibdata1 -rw-rw 1 mysql wheel 105G Feb 6 22:33 /var/db/mysql/ibdata1 -- wbr, tiger
[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
