Отвечу цитатой
quote
При выборке в секции SELECT требуется дополнительное время на слияние
основной выборки и подзапроса. Вышло 1% от общего времени.(+ LEFT JOIN / -
SELECT)
Оказалось, что каждый LEFT JOIN выполняется отдельным потоком! В то время
как подзапросы выполняются
7 февраля 2012 г. 10:26 пользователь Sergey Rudenko
sergey_rude...@bk.ru написал:
Отвечу цитатой
quote
Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые
преимущества
/quote
sarcasmА мужики в FB не знают.../sarcasm :)
Тогда вопрос - чего ж тогда такой бум NoSQL сейчас?
В них
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
On Tue, Feb 07, 2012 at 10:35:40AM +0200, Denis Zhdanov wrote:
sarcasmА мужики в FB не знают.../sarcasm :)
Тогда вопрос - чего ж тогда такой бум NoSQL сейчас?
ну типа, кризис, становятся модными системы из говн...зачеркнуто, облачные
структуры...
В них тоже джойнов нет, и особой серверной
07.02.2012 10:28, Alex Korchmar пишет:
On Tue, Feb 07, 2012 at 10:23:20AM +0200, Vladimir Mevsha wrote:
Пока сейчас вижу способ с lock table и zfs snapshot
В таком случае советую посмотреть еще и на zfs send/receive
а вот кто расскажет, по личным впечатлениям - насколько оно все встает
колом
6 февраля 2012 г. 22:49 пользователь Алексей Бобок
alexey.bo...@gmail.com написал:
Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать.
Расскажите это разрабочтикам на труъ ынтырпрайз оракуле, которые
бОльшую часть логики пишут в БД, и оно там как-то работает.
Alex Korchmar wrote:
On Tue, Feb 07, 2012 at 10:23:20AM +0200, Vladimir Mevsha wrote:
Пока сейчас вижу способ с lock table и zfs snapshot
В таком случае советую посмотреть еще и на zfs send/receive
а вот кто расскажет, по личным впечатлениям - насколько оно все встает
колом при создании
07.02.2012 10:23, Vladimir Mevsha пишет:
В таком случае советую посмотреть еще и на zfs send/receive
(в случае, если БД будет в отдельном dataset).
Ага, но лучше это делать не в лоб send/receive, а через mbuff
Здесь на примере показано как это сделать
On Tue, Feb 07, 2012 at 11:14:43AM +0200, skeletor wrote:
Ага, но лучше это делать не в лоб send/receive, а через mbuff
а не чисто-солярисовая ли это заморочка?
Alex
07.02.2012 11:39, Alex Korchmar пишет:
On Tue, Feb 07, 2012 at 11:14:43AM +0200, skeletor wrote:
Ага, но лучше это делать не в лоб send/receive, а через mbuff
а не чисто-солярисовая ли это заморочка?
Да, это чисто солярисовская заморочка, на собственных тестах проблем
с производительностью
7 февраля 2012 г. 11:50 пользователь Vladimir Mevsha
vladi...@mevsha.com написал:
Да, это чисто солярисовская заморочка, на собственных тестах проблем
с производительностью не заметил.
Тем не менее, mbuffer в портах топика есть.
Кстати, я вот подумал... а какого хрена тема имеет метку
Я вас правильно понял, просто селект в данном случае тот-же джоин. Не думаю,
что в ФБ они заменили джоины на селекты и этим добились большей
производительности
Специально протестировал на mysql таблица 4 записей, большей под рукой
сейчас нет
Первое значение это первый запрос, второе после
Безотносительно системы, но посмотрите сюда
http://www.percona.com/software/percona-xtrabackup/
Пользуемся сами на критичных серверах именно для бекапов
Слепок с 600г данных делается 4ч
Восстановление с такого бекапа - порядка 2-3ч
On Feb 6, 2012, at 15:07 , skeletor wrote:
Есть сервер в
On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote:
Я вас правильно понял,
повторяю: вы ничего не поняли.
просто селект в данном случае тот-же джоин.
именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже
автооптимизирующийся. Ну так не делайте таких селектов.
select
07 февраля 2012, 18:40 от Alex Korchmar 4spa...@linux.e-moe.ru:
On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote:
Я вас правильно понял,
повторяю: вы ничего не поняли.
просто селект в данном случае тот-же джоин.
именно. _ваш_ селект - тот же джойн, только, вероятно,
7 февраля 2012 г. 17:15 пользователь Alex Samorukov m...@os2.kiev.ua написал:
Кстати, facebook активно нанимал MySQL DBA недавно (Ирландия или
Калифорния), так что если у кого есть желание узнать как оно там внутри - у
меня где-то контакты их HR`а сохранились ;-)
Мегаоффтоп - но разве ФБ хайрит
7 февраля 2012 г. 17:24 пользователь Denis Zhdanov
denis.zhda...@gmail.com написал:
Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у
них была политика брать только своих.
Сам себе отвечу - да, похоже политика поменялась, в 2011 программеров
по крайней мере набирали, и с
Сорри, отсутствовал.
2Sergey Rudenko
Неужели БД тупее приложения будет?
Не тупее, но у грузовика задача перевозить много картофеля, а у мазерати
быстро до сотни разгоняться. БД пусть хранит и выбирает данные, т.е. то под
что она оптимизирована.
2Alex Korchmar
Я работаю с клиентами у которых
On Tue, Feb 07, 2012 at 06:52:36PM +0400, Sergey Rudenko wrote:
напишите вместо этого одиночный селект. from forum,forum_t, вместе с id.
Если вас не затруднит, напишите пример такого запроса
я уже практически написал. Да, он вернет гораздо больше чем надо - ну и что?
Джоимов может быть 20
19 matches
Mail list logo
