On Tue, Feb 07, 2012 at 06:52:36PM +0400, Sergey Rudenko wrote:
> > напишите вместо этого одиночный селект. from forum,forum_t, вместе с id.
> Если вас не затруднит, напишите пример такого запроса
я уже практически написал. Да, он вернет гораздо больше чем надо - ну и что?
> Джоимов может быть 20
Сорри, отсутствовал.
2Sergey Rudenko
> Неужели БД "тупее" приложения будет?
Не тупее, но у грузовика задача перевозить много картофеля, а у мазерати
быстро до сотни разгоняться. БД пусть хранит и выбирает данные, т.е. то под
что она оптимизирована.
2Alex Korchmar
>
> Я работаю с клиентами у кот
7 февраля 2012 г. 17:24 пользователь Denis Zhdanov
написал:
> Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у
> них была политика "брать только своих".
Сам себе отвечу - да, похоже политика поменялась, в 2011 программеров
по крайней мере набирали, и с России и с Укрины тоже. М
7 февраля 2012 г. 17:15 пользователь Alex Samorukov написал:
> Кстати, facebook активно нанимал MySQL DBA недавно (Ирландия или
> Калифорния), так что если у кого есть желание узнать как оно там внутри - у
> меня где-то контакты их HR`а сохранились ;-)
Мегаоффтоп - но разве ФБ хайрит кого то из за
On 02/07/2012 03:52 PM, Sergey Rudenko wrote:
просто селект в данном случае тот-же джоин.
именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже
автооптимизирующийся. Ну так не делайте таких селектов.
select thread_name,
(SELECT forum_name FROM forum WHERE forum_id = thread_forum_i
On Tue, Feb 07, 2012 at 02:50:53PM +0400, Sergey Rudenko wrote:
> Я вас правильно понял,
повторяю: вы ничего не поняли.
> просто селект в данном случае тот-же джоин.
именно. _ваш_ селект - тот же джойн, только, вероятно, еще и хуже
автооптимизирующийся. Ну так не делайте таких селектов.
> sele
Я вас правильно понял, просто селект в данном случае тот-же джоин. Не думаю,
что в ФБ они заменили джоины на селекты и этим добились большей
производительности
Специально протестировал на mysql таблица 4 записей, большей под рукой
сейчас нет
Первое значение это первый запрос, второе после то
6 февраля 2012 г. 22:49 пользователь Алексей Бобок
написал:
> Вся логика - в приложении. Задача БД - хранить данные и быстро выбирать.
Расскажите это разрабочтикам на "труъ ынтырпрайз оракуле", которые
бОльшую часть логики пишут в БД, и оно там как-то работает.
On Tue, Feb 07, 2012 at 10:35:40AM +0200, Denis Zhdanov wrote:
> А мужики в FB не знают... :)
> Тогда вопрос - чего ж тогда такой бум NoSQL сейчас?
ну типа, кризис, становятся модными системы из говн...зачеркнуто, облачные
структуры...
> В них тоже джойнов нет, и особой серверной логики тоже - ма
6 февраля 2012 г. 21:35 пользователь Sergey V. Dyatko
написал:
> сколько из 92Г весят бинлоги, например?:)
# du -hs /var/lib/mysql/
92G /var/lib/mysql/
# find /var/lib/mysql/ -name \*bin\*
#
Как бы 0 байт бинлоги весят.
ЗЫЖ Тоже 1 база.
ЗЗЫЖ И это не фаллометрия, а пример БД на мускуле, кото
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
7 февраля 2012 г. 10:26 пользователь Sergey Rudenko
написал:
> Отвечу цитатой
>
> Вывод: В условиях многоядерных серверов LEFT JOIN имеет неоспоримые
> преимущества
>
А мужики в FB не знают... :)
Тогда вопрос - чего ж тогда такой бум NoSQL сейчас?
В них тоже джойнов нет, и особой серверной логи
Отвечу цитатой
При выборке в секции SELECT требуется дополнительное время на слияние
основной выборки и подзапроса. Вышло 1% от общего времени.(+ LEFT JOIN / -
SELECT)
Оказалось, что каждый LEFT JOIN выполняется отдельным потоком! В то время
как подзапросы выполняются последовательно по
On Tue, Feb 07, 2012 at 12:38:51AM +0400, Sergey Rudenko wrote:
> Я возможно далёк, но хотел-бы услышать как можно избавиться от join,
> хотя-бы каким методом
сделать select без join и тупо отфильтровать нужное?
Идея что фронтендов вы можете понапихать до бесконечности, если они не
справляются с
> Когда нет денег на бекап - нет и бизнеса. Это несерьезная хрень какая-то.
> Потому мои клиенты или покупают то, что я говорю или идут к другому
хорошо, можете смело давать им мой адрес. Я работаю с клиентами у которых
бюджет ограничен и которые понимают что такое управление рисками, и не
афилли
Неужели БД "тупее" приложения будет?
07 февраля 2012, 00:50 от Алексей Бобок :
6 февраля 2012 г. 22:38 пользователь Sergey Rudenko
написал:
Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы
каким методом
Легко, имея соответствующую архитектуру приложения.
Необ
6 февраля 2012 г. 22:38 пользователь Sergey Rudenko
написал:
> Я возможно далёк, но хотел-бы услышать как можно избавиться от join,
> хотя-бы каким методом
>
> Легко, имея соответствующую архитектуру приложения.
Необходимо выбирать нужные данные, обработать в приложении и выдать
конечный результат
Я возможно далёк, но хотел-бы услышать как можно избавиться от join, хотя-бы
каким методом
07 февраля 2012, 00:24 от Алексей Бобок :
Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL, которые
являются основным хранилищем данных ФБ, несмотря на то что они
не используют
>
> Мммм. Переформулируем так - ФБ использует более 2500 серверов с MySQL,
> которые являются основным хранилищем данных ФБ, несмотря на то что они
> не используют join и используют ее только как справочник - это именно
> то "основное", на чем оно и крутится.
Использовать join и rlike и вообще про
6 февраля 2012 г. 19:21 пользователь Sergey Rudenko
написал:
> "ИМХО справочники" - относилось к ФБ
> Если они не используют там join то вывод один - это справочники, которые не
> такие и большие
> А на чем основное крутится совсем не понятно
Мммм. Переформулируем так - ФБ использует более 2500
On Mon, Feb 06, 2012 at 11:18:11PM +0400, Andrey Kopeyko wrote:
> Нет, не одному вам.
вы тоже DBA-теоретик?
> У меня, к примеру, несколько "не складываются" две другие вещи
> - простои критичны
> - отсутствуют регулярные полные бэкапы базы.
сплошь и рядом.
В частности, потому, что очень во многих
On Mon, 06 Feb 2012 23:56:33 +0400
Sergey Rudenko wrote:
> Вы не теми попугаями меряете, что у вас в директории лежит одна или
> 500 баз? Вес тут роли не играет, а у гражданина одна база на 50 гиг
>
2шт. та что mysql и та что рабочая (это mysql-slave)
>
> 06 февраля 2012, 23:35 от "Sergey V.
Вы не теми попугаями меряете, что у вас в директории лежит одна или 500 баз?
Вес тут роли не играет, а у гражданина одна база на 50 гиг
06 февраля 2012, 23:35 от "Sergey V. Dyatko" :
> On Mon, 6 Feb 2012 18:17:32 +0200
> Sayetsky Anton wrote:
>
> > 6 февраля 2012 г. 18:15 пользователь Vasiliy P
On Mon, 6 Feb 2012 18:17:32 +0200
Sayetsky Anton wrote:
> 6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik
> написал:
> > может одному мне кажется что мускуль, 50 гигов и простои критичны
> > между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие,
> > постгресы и прочие тяжеловесы н
6 февраля 2012 г. 21:18 пользователь Andrey Kopeyko написал:
> У меня, к примеру, несколько "не складываются" две другие вещи
> - простои критичны
> - отсутствуют регулярные полные бэкапы базы.
>
+1
>
> Чем быстрее вы её исправите - тем легче вам будет дышать в будущем.
>
+1
>
> Да, будет даунт
06.02.2012 20:15, Vasiliy P. Melnik пишет:
может одному мне кажется что мускуль, 50 гигов и простои критичны
между собой не вяжутся.
Нет, не одному вам.
У меня, к примеру, несколько "не складываются" две другие вещи
- простои критичны
- отсутствуют регулярные полные бэкапы базы.
На мой взгляд
On Mon, Feb 06, 2012 at 06:15:32PM +0200, Vasiliy P. Melnik wrote:
> может одному мне кажется что мускуль, 50 гигов и простои критичны
видимо, одному.
> между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие,
> постгресы и прочие тяжеловесы нужны
более того, я как раз зассал бы такого разме
"ИМХО справочники" - относилось к ФБ
Если они не используют там join то вывод один - это справочники, которые не
такие и большие
А на чем основное крутится совсем не понятно
06 февраля 2012, 21:14 от Denis Zhdanov :
> 6 февраля 2012 г. 19:07 пользователь Sergey Rudenko
> написал:
> > Не оффтоп
6 февраля 2012 г. 19:07 пользователь Sergey Rudenko
написал:
> Не оффтопа ради, а ради спаведливости
> "ФБ MySQL -- используется как хранилище пар ключ-значение, никаких join'ов"
А кто спорит? Вопрос был о больших базах на мускуле. Ответ - они есть и юзаются.
> ИМХО справочники
> "ВК Собственная
Очень даже вяжется) ФБ и ВК на мускуле. Так что это оффтоп) только надо строить
правильно.
--
Best regards,
Alexey Bobok
06.02.2012, в 18:23, Sergey Kobzar написал(а):
> On 02/06/12 18:15, Vasiliy P. Melnik wrote:
>> может одному мне кажется что мускуль, 50 гигов и простои критичны
>> между с
On 02/06/12 18:15, Vasiliy P. Melnik wrote:
может одному мне кажется что мускуль, 50 гигов и простои критичны
между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие,
постгресы и прочие тяжеловесы нужны
Да ладно ;)
6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik
написал:
> может одному мне кажется что мускуль, 50 гигов и простои критичны
> между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие,
> постгресы и прочие тяжеловесы нужны
# du -hs /var/lib/mysql/
92G /var/lib/mysql/
Работает, не
On 02/06/12 18:46, Vasiliy P. Melnik wrote:
В случае выхода из строя мастера вместе со всеми данными на слейве
> будет свежая копия данных, к тому же готовая к использованию.
не понял
На сервере 2 винта?
Очень редко, но бывают ситуации, когда два винта не спасают. Например
неисправность жел
6 февраля 2012 г. 16:58 пользователь Sayetsky Anton написал:
> 6 февраля 2012 г. 16:57 пользователь skeletor написал:
>> Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее
>> полная копия работающего сервера с БД.
>
> mysql + drbd + heartbeat
>
> Или dual-direction replicat
>
> 06.02.2012 14:10, Anton Yuzhaninov пишет:
>
>
> Чтобы получить работающий slave, надо сначала получить dump мастера.
>>
>> Именно! Вот как раз и в этом состоит и проблема.
>
Это действительно настолько недопустимая ситуация?
Я не представляю себе существование базы, которая не может не работ
6 февраля 2012 г. 16:57 пользователь skeletor написал:
> Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы, точнее
> полная копия работающего сервера с БД.
mysql + drbd + heartbeat
Или dual-direction replication, но говорят, что оно не работает.
06.02.2012 16:46, Vasiliy P. Melnik пишет:
На сервере 2 винта?
А какое отношение имеет количество винтов на сервере к выходу сервера из
строя?
Как написал, Anton Yuzhaninov, мне нужна просто свежая копия базы,
точнее полная копия работающего сервера с БД.
On Mon, Feb 06, 2012 at 06:44:00PM +0400, Anton Yuzhaninov wrote:
> On 02/06/12 18:35, Vasiliy P. Melnik wrote:
> >так если есть винт с базой зачем тогда мускуль поднимать и что-то еще -
> >файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд
>
> Файл базы запакованный на д
On 02/06/12 18:35, Vasiliy P. Melnik wrote:
так если есть винт с базой зачем тогда мускуль поднимать и что-то еще -
файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд
Файл базы запакованный на длительное хранение, содержит старые данные. А бэкап
обычно хочется иметь м
так если есть винт с базой зачем тогда мускуль поднимать и что-то еще -
файлы базы запаковать и на длительное хранение. Винт вернуть на место в рейд
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 пишет:
>
On 02/06/12 16:18, skeletor wrote:
06.02.2012 14:10, Anton Yuzhaninov пишет:
Чтобы получить работающий slave, надо сначала получить dump мастера.
Именно! Вот как раз и в этом состоит и проблема.
Как она решается в треде уже написано. Напишу более подробно.
1. Включть в mysql заись binary l
On 02/06/12 14:18, skeletor wrote:
06.02.2012 14:10, Anton Yuzhaninov пишет:
Чтобы получить работающий slave, надо сначала получить dump мастера.
Именно! Вот как раз и в этом состоит и проблема.
Остановить базу, сделать копию на уровне ФС, запустьть базу, вылить
копию на слэйв.
Если оста
06.02.2012 14:10, Anton Yuzhaninov пишет:
Чтобы получить работающий slave, надо сначала получить dump мастера.
Именно! Вот как раз и в этом состоит и проблема.
On 02/06/12 16:05, Алексей Бобок wrote:
Данные сливать на slave посредством родной sql-репликации, dump делать со slave.
Чтобы получить работающий slave, надо сначала получить dump мастера.
--
Anton Yuzhaninov
6 февраля 2012 г. 13:15 пользователь Sergey Rudenko
написал:
>
> Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него?
>
> Коллега предложил самый простой, железный и действенный способ.
Данные сливать на slave посредством родной sql-репликации, dump делать со
slave.
Но нужно
06.02.2012 15:31, skeletor пишет:
06.02.2012 13:25, Sergey V. Dyatko пишет:
каким образом предлагаете делать слейв?;-) насколько я понял, опускать
сайт нельзя.
Думаю делать так: поднять slave и начать репликацию.
Учтите, что репликация будет переносить на slave лишь изменения в базе,
возн
On Mon, 06 Feb 2012 13:31:34 +0200
skeletor wrote:
> 06.02.2012 13:25, Sergey V. Dyatko пишет:
>
> > каким образом предлагаете делать слейв?;-) насколько я понял,
> > опускать сайт нельзя.
> >
>
> Думаю делать так: поднять slave и начать репликацию. При этом
> возникает такой момент: данных оче
06.02.2012 15:15, Sergey Rudenko пишет:
Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него?
Ха-ха: дабы поднять репликацию не с рождения базы, на будущем слейве вам
надо будет развернуть дамп базы, для чего на будущем мастере его
предстоит сделать...
Получаем "сказк
06.02.2012 13:25, Sergey V. Dyatko пишет:
каким образом предлагаете делать слейв?;-) насколько я понял, опускать
сайт нельзя.
Думаю делать так: поднять slave и начать репликацию. При этом возникает
такой момент: данных очень много и поэтому, пока будет делаться дамп и
заливка на slave насоб
On Mon, 06 Feb 2012 15:15:10 +0400
Sergey Rudenko wrote:
>
> Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с
> него?
>
каким образом предлагаете делать слейв?;-) насколько я понял, опускать
сайт нельзя.
> 06 февраля 2012, 15:07 от skeletor :
> > Есть сервер в продакшине и
50 matches
Mail list logo
