[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] Необычный дамп базы mysql
7 февраля 2012 г. 17:15 пользователь Alex Samorukov m...@os2.kiev.ua написал: Кстати, facebook активно нанимал MySQL DBA недавно (Ирландия или Калифорния), так что если у кого есть желание узнать как оно там внутри - у меня где-то контакты их HR`а сохранились ;-) Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у них была политика брать только своих.
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
7 февраля 2012 г. 17:24 пользователь Denis Zhdanov denis.zhda...@gmail.com написал: Мегаоффтоп - но разве ФБ хайрит кого то из за рубежа? Вроде раньше у них была политика брать только своих. Сам себе отвечу - да, похоже политика поменялась, в 2011 программеров по крайней мере набирали, и с России и с Укрины тоже. Мало-мало, но есть... Ж)
[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] Необычный дамп базы mysql
On Tue, Feb 07, 2012 at 06:52:36PM +0400, Sergey Rudenko wrote: напишите вместо этого одиночный селект. from forum,forum_t, вместе с id. Если вас не затруднит, напишите пример такого запроса я уже практически написал. Да, он вернет гораздо больше чем надо - ну и что? Джоимов может быть 20 штук и более, предлагаете все данные в одну таблицу пихать? если их двадцать штук и это не раз в час, а на каждый запрос - предлагаю предварительно прописать бамбуковую палку по пяткам тому кто придумал такую структуру данных. В одну или в несколько - думать головой. Вот фэйсбук, как видим, в нее не только ест, и у них джойнов нету. Не думаю что ваши данные сильно сложнее фейсбучных. На днях как раз такой сон разума переделывал (крошечный, но работать с ним было неудобно). От полутора десятков (не помню сколько, но что-то совсем безобразное) таблиц осталось две, джойна ни одного потому что единственное поле ради которого джойнили - наличествует теперь просто в обоих таблицах и достаточно простого where id=id , а запрос занимает пол-строчки, а не пять. Ну и вот зачем этот бред изначально городили? Правильно: аффтар начитался детских книжек про нормальную форму. Alex
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
6 февраля 2012 г. 13:15 пользователь Sergey Rudenko sergey_rude...@bk.ruнаписал: Поднять ещё один сервер БД, настроить репликацию и сделать дамп уже с него? Коллега предложил самый простой, железный и действенный способ. Данные сливать на slave посредством родной sql-репликации, dump делать со slave. Но нужно понимать насколько много записи в базу, чтобы между процедурами дампа slave успевал отрпелицировать все (помним, что до версии mysql, кажется, 5.5 на слейв изменения льются в 1 поток, в 5.5 или какой-то новой можно включать отдельные потоки per-database). -- 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] Необычный дамп базы mysql
6 февраля 2012 г. 18:15 пользователь Vasiliy P. Melnik ba...@vpm.net.ua написал: может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны # du -hs /var/lib/mysql/ 92G /var/lib/mysql/ Работает, не чешется.
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On 02/06/12 18:15, Vasiliy P. Melnik wrote: может одному мне кажется что мускуль, 50 гигов и простои критичны между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны Да ладно ;)
[freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
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
ИМХО справочники - относилось к ФБ Если они не используют там 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] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 06:15:32PM +0200, Vasiliy P. Melnik wrote: может одному мне кажется что мускуль, 50 гигов и простои критичны видимо, одному. между собой не вяжутся. Совсем не вяжутся - тут ораклы всякие, постгресы и прочие тяжеловесы нужны более того, я как раз зассал бы такого размера и критичное к простоям делать на оракле (я верю что он - может, но к нему надо трех очень дорогих админов, живущих совершенно свою, отдельную от моей профессиональную жизнь, да и сам такой оракл со всеми, вероятно, нужными, тем админам, причиндалами тоже может оказаться вне бюджета проекта с 50гиг и критичностью к простоям), и точно не стал бы - на postgres, его какие-то совершенно не от мира сего чуваки пишут. А mysql'ные конструкции я видел и на порядок большего объема. Разумеется, это не было простой и приятной в поддержке системой, но и супер-гуру рядом тоже не наблюдалось. А уж 50G на нем - совсем не требуют никакого сильного колдунства, тем более если до сих пор проблема только с эффективным бэкапом. (то ли кто-то умеет писать запросы, то ли мощности переизбыток, то ли у кого-то хорошая бамбуковая палка) Alex
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[2]: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
Вы не теми попугаями меряете, что у вас в директории лежит одна или 500 баз? Вес тут роли не играет, а у гражданина одна база на 50 гиг 06 февраля 2012, 23:35 от Sergey V. Dyatko sergey.dya...@gmail.com: 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
Re: [freebsd] Re[2]: [freebsd] Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, 06 Feb 2012 23:56:33 +0400 Sergey Rudenko sergey_rude...@bk.ru wrote: Вы не теми попугаями меряете, что у вас в директории лежит одна или 500 баз? Вес тут роли не играет, а у гражданина одна база на 50 гиг 2шт. та что mysql и та что рабочая (это mysql-slave) 06 февраля 2012, 23:35 от Sergey V. Dyatko sergey.dya...@gmail.com: 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 -- wbr, tiger
Re: [freebsd] Re: [freebsd] Необычный дамп базы mysql
On Mon, Feb 06, 2012 at 11:18:11PM +0400, Andrey Kopeyko wrote: Нет, не одному вам. вы тоже DBA-теоретик? У меня, к примеру, несколько не складываются две другие вещи - простои критичны - отсутствуют регулярные полные бэкапы базы. сплошь и рядом. В частности, потому, что очень во многих случаях лавочку можно смело закрывать, если она встанет на то время, которое занимает восстановление с такого бэкапа. При том что особо ценной информации там внутри может и 1% нет. Разумеется, вместо него обычно есть стройная система костылей и подпорок, как-то позволяющая отложить процесс банкротства до следующего месяца, но часто и она оказывается слегка отставшей от развития и уже маложизнеспособной. На мой взгляд, второе прямо и недвусмысленно говорит о том, что простои таки совершенно нестрашны. или что приняты меры чтобы они были маловероятны, а затыкать буде все же выйдут - будут административным путем. ну, грубо утрируя - если у вас там счета клиентов и оно хряпсь - тупо пересоздаем их все, добавляя на каждый денег по пол-лимона. Ни один ведь не пожалуется? (ок - трое пожалуются и каждый отсудит по два, но через три года пока будет тянуться судебная волокита. А нормальная система с бэкапами и фэйловером стоит у вас, скажем - пять, которые надо вырвать из бизнеса немедленно, навсегда, и еще и доливать по мере роста. Для кого-то и это вполне приемлемый риск.) Все совпадения и имена случайны, поэтому не надо гадать где именно лежат ваши два лимона ;-) Поверьте, у контор есть куда больше способов накрываться медным тазом, особенно у стартапных. И далеко не всегда этот - наиболее вероятный. Прецедент я обслуживал с 2005-го (когда как раз навернулось и оказалось что бэкапа нет) до 2008, когда наступили опаньки совсем-совсем по другой причине. Причем оно протрепыхалось уже как бесплатный проект еще пару лет, потеряв в том числе и бэкап и фэйловер (потому что нечем было платить), и в конечном итоге сдохло - вполне обратимо, в целом, но практического смысла в оживлении уже не было. Alex
[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
