Comments 80
Парни, да в случае с множеством инсертов разумеется нужно перейти на InnoDB. Почему не попробуете?
еще рекомендую глянуть в сторону memcacheDB
еще рекомендую глянуть в сторону memcacheDB
Мы использовали MyISAM в прошлых проектах, но там была стандартная схема хранения пользовательских данных в базе и при каждом запросе участвовала база данных. Это первый проект в котором пользовательские данные хранятся в памяти и сохраняются при логауте или по интервалу.
Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.
Про memcacheDB слышали, если мне не изменяет память — это интерфейс поверх BDB. А так как tyrant — показал себя намного лучше, чем bdb — то мы склонны использовать все таки его. Но в tyrant есть и свои минусы, поэтому мы не спешим с переходом.
Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.
Про memcacheDB слышали, если мне не изменяет память — это интерфейс поверх BDB. А так как tyrant — показал себя намного лучше, чем bdb — то мы склонны использовать все таки его. Но в tyrant есть и свои минусы, поэтому мы не спешим с переходом.
Про InnoDB нам рассказывали страшилки знакомые девелоперы. Они перевели базу с MyISAM на InnoDB и получили очень сильное увеличение нагрузки на диск. Но безусловно перевести несколько таблиц на InnoDB нам не составит труда, когда руки доберутся — попробуем.
Разумеется там есть нюансы ) Тюнинг там немного отличается от тюнинга MyISAM.
Я бы еще попробовал сделать связку Master-Master. Бин логи на отдельном диске вы правильно сделали — это очень критичная штука.
MemcacheDB — это как вы и написали интерфейс поверх BDB. А вот бенчмарки из MemcacheDB: A Complete Guide
вы сами использовали memcachedb?
На production проектах нет, только в качестве пощупать на локальном стенде.
Если интересует вариант именно практического применения, то спросите у пользователя magnit — у него имеется более детальное представление о сабже.
Если интересует вариант именно практического применения, то спросите у пользователя magnit — у него имеется более детальное представление о сабже.
ИМХО, Вам стоит рассмотреть следующий вариант:
1. берем на продакшене таблы, которые чаще всего ЧИТАЮТСЯ оставляем MyISAM
2. таблы, которые равномерно читаются / изменяются и ОЧЕНЬ ЧАСТО — MEMORY, иначе InnoDB
3. таблы, которые чаще изменяются InnoDB
Потому, что
1. MyISAM — очень быстро вибирает, но при изменении таблы лочится ВСЯ табла.
2. InnoDB — чуть медленнее выбирает, но при изменении лочится строка(ки).
3. MEMORY — вся висит в ОЗУ, но оно не резиновое.
При таком подходе мы сняли нагрузку на кластер БД, переведя ЧАСТЬ таблиц на InnoDB и MEMORY на столько, что смогли отказаться от кластера :)
проект имеет 40..60к уников в час.
Надеюсь, что этот опыт будет Вам полезен.
1. берем на продакшене таблы, которые чаще всего ЧИТАЮТСЯ оставляем MyISAM
2. таблы, которые равномерно читаются / изменяются и ОЧЕНЬ ЧАСТО — MEMORY, иначе InnoDB
3. таблы, которые чаще изменяются InnoDB
Потому, что
1. MyISAM — очень быстро вибирает, но при изменении таблы лочится ВСЯ табла.
2. InnoDB — чуть медленнее выбирает, но при изменении лочится строка(ки).
3. MEMORY — вся висит в ОЗУ, но оно не резиновое.
При таком подходе мы сняли нагрузку на кластер БД, переведя ЧАСТЬ таблиц на InnoDB и MEMORY на столько, что смогли отказаться от кластера :)
проект имеет 40..60к уников в час.
Надеюсь, что этот опыт будет Вам полезен.
Убило что из бекапа нельзя восстановить базы innodb, только если SQL дама постоянно делать…
Berkeley не выдает хорошую производительность на больших количествах запросов.
А Вы не пробовали использовать двиг MEMORY?
В нем таблы и так висят в ОЗУ :)
В нем таблы и так висят в ОЗУ :)
А про MEMORY мы и забыли;) Как по мне администрирование базы на tmpfs проще, чем использование MEMORY — потому как используются все те же скрипты и подходы, только мы работаем с очень быстрым диском.
Ещё тут вопрос как бекапить таблицы? Мы используем бекап файловой системы, которая находится в памяти (mysqldump в разы медленнее), а вот как быть с MEMORY — не знаю.
Ещё тут вопрос как бекапить таблицы? Мы используем бекап файловой системы, которая находится в памяти (mysqldump в разы медленнее), а вот как быть с MEMORY — не знаю.
Насколько я знаю, у него множество ограничений.
Да, в доках всё описано.
Как мемкеш поможет смасштабировать update-ы?
Чуть выше в посте есть график. Так вот там красненьким отмечено количество UPDATE-ов. И их куда больше чем SELECT-ов.
У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.
Хотя memcache тоже используется в некоторых местах, но работать с данными напрямую в памяти в сотни раз быстрее.
Хотя memcache тоже используется в некоторых местах, но работать с данными напрямую в памяти в сотни раз быстрее.
Проект — игра. Экономический симулятор. При входе в игру загружаются данные и начинается симуляцмя в С++. Периодически последний этап симуляции на всех объектах пользователя сохраняется в базу.
Мы меняли нагрузку увеличивая интервал сохранения, но это чревато тем что упадет демон и пользователь откатится на большое время назад.
Сами таблицы и индексы достаточно простые (грубо говоря несколько таблиц objects в которых есть user_id индекс, а сохранение производится по primary key). Просто данные активно меняются. И да, записываются только те данные, что изменились.
Мы меняли нагрузку увеличивая интервал сохранения, но это чревато тем что упадет демон и пользователь откатится на большое время назад.
Сами таблицы и индексы достаточно простые (грубо говоря несколько таблиц objects в которых есть user_id индекс, а сохранение производится по primary key). Просто данные активно меняются. И да, записываются только те данные, что изменились.
Навскидку вам можно посоветовать такие решения:
1. Partitioning tables + InnoDB + разделы на разных дисках. Появилось в MySQL 5.1.
2. Если у вас все настолько просто и нет необходимости джойнить таблицы, а MySQL в основном используется как key-value storage, то вам будет очень легко горизонтально зашардить таблички.
Ну уж точно надо отказываться от tmpfsm, в первую очередь, а во вторую от MyISAM.
1. Partitioning tables + InnoDB + разделы на разных дисках. Появилось в MySQL 5.1.
2. Если у вас все настолько просто и нет необходимости джойнить таблицы, а MySQL в основном используется как key-value storage, то вам будет очень легко горизонтально зашардить таблички.
Ну уж точно надо отказываться от tmpfsm, в первую очередь, а во вторую от MyISAM.
Простите, но у вас не единственная проблема. У вас очень высока вероятность потерять данные. Данные на реплике не всегда будут соответствовать данным на мастере из-за задержек репликации.
А InnoDB, в принципе, может сократить IO. Зависит от многих факторов.
А InnoDB, в принципе, может сократить IO. Зависит от многих факторов.
InnoDB просто нужно вменяемо готовить. Если вам не критична потеря данных за последние пару секунд innodb_flush_log_at_trx_commit=2 даст сбрасывание транзакций на диск раз в две секунды, что очень сильно прибаляет скорости.
Вы молодцы, но в вашей системе не хватает пакета aspell-ru.
Just pipe it to /dev/null!
www.xtranormal.com/watch/6995033/
www.xtranormal.com/watch/6995033/
хм, вот все говорят, что нужно оставаться на мускуле, что с монго можно потерять данные, что сравнение графиков usert`ов это туфта, но при этом никто не показывает как надо протюнить мускул, чтобы он, по графикам, отличался от монго на величину погрешности вычислений.
ЗЫ походу там два дурака разговаривают %)
ЗЫ походу там два дурака разговаривают %)
мда, а вы тоже самое не пытались делать с помощью встроенных утилит мускула? он ведь и сам может поместить базы в оперативу и писать апдейты на диск с отложением, а?
ну и так на будущее
www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/
www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
PS удачных велосипедов
ну и так на будущее
www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation/
www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
PS удачных велосипедов
Как уже многие писали — в вашем случае панацея — это InnoDB и его правильный тюнинг.
Вам нужно взять Percona Server (в нём можно настроить кол-во threads для чтения/записи данных, это уже само по себе позволяет распределить нагрузку), настроить log buffer на что-нить типа 20-50MB — получите запись крупными блоками на диск, что гораздо быстрее и эффективнее, чем рандомная запись, особенно на SSD. InnoDB buffer pool выставляете побольше — тогда в памяти постоянно будет висет большое кол-во данных и индексы — в этом случае InnoDB легко взлетает — выжимали до 3000 запросов из 2х2 Xeon'a ещё модели 2006 года, на нынешних можно выжать куда больше.
В общем, ИМХО, статья у вас получилась по незнанию «Как делать не надо». Один раз у вас что-то полетит и можно очень и очень сильно вляпаться с таким подходом. UPS иногда, знаете ли, тоже ломаются, RAID-5 умирают и происходят прочие, не менее странные вещи. Законы Мерфи, итить их за ногу.
Вам нужно взять Percona Server (в нём можно настроить кол-во threads для чтения/записи данных, это уже само по себе позволяет распределить нагрузку), настроить log buffer на что-нить типа 20-50MB — получите запись крупными блоками на диск, что гораздо быстрее и эффективнее, чем рандомная запись, особенно на SSD. InnoDB buffer pool выставляете побольше — тогда в памяти постоянно будет висет большое кол-во данных и индексы — в этом случае InnoDB легко взлетает — выжимали до 3000 запросов из 2х2 Xeon'a ещё модели 2006 года, на нынешних можно выжать куда больше.
В общем, ИМХО, статья у вас получилась по незнанию «Как делать не надо». Один раз у вас что-то полетит и можно очень и очень сильно вляпаться с таким подходом. UPS иногда, знаете ли, тоже ломаются, RAID-5 умирают и происходят прочие, не менее странные вещи. Законы Мерфи, итить их за ногу.
Спасибо за подробную информацию. Вы мы будем пробовать InnoDB. А статья может и «Как делать не надо», но в качестве быстрого решения — тоже вариант. В частности для обсуждения этого вопроса и создавалась эта статья.
Не подскажете где можно что-то про Percona Server прочитать. В стиле «Тюнинг Percona Server»...?
Перечитал пост дважды, но так и не нашел описания того, что будет, когда вдруг отключится электричество или понадобится ребут по техническим причинам. Получится закат солнца вручную (описанный паттерн «падение двух слейвов») или где-то в дебрях /etc/init.d лежат скрипты, которые заберут нужный снапшот базы из нужного места и развернут ее?
И вообще, оптимизация дисковых операций выглядит так: 1. убеждаемся, что для «горячих» select'ов у нас есть необходимые индексы и при этом их не так много, чтобы они убивали операции insert/update; 2. задействуем головной мозг и избавляемся от лишних запросов (можно использовать memcached). И только после этого, если ничего не помогло, имеет смысл копать «вглубь», перемещать данные в tmpfs и так далее, и тому подобное.
И вообще, оптимизация дисковых операций выглядит так: 1. убеждаемся, что для «горячих» select'ов у нас есть необходимые индексы и при этом их не так много, чтобы они убивали операции insert/update; 2. задействуем головной мозг и избавляемся от лишних запросов (можно использовать memcached). И только после этого, если ничего не помогло, имеет смысл копать «вглубь», перемещать данные в tmpfs и так далее, и тому подобное.
конечно все скрипты для поднятия со слейва написаны и подключены… скорость восстановления если машина рухнула состоит из времени поднятия машины+копирования бекапа+ разархивирования его + поднятие базы в среднем занимает около 3-5 минут, ну так если сервер рухнул в любом случае демоны не могут до стучаться до базы пока сервер лежит… теряется время в отличии от стандартного подьема сервера отличается только на копировании и развертывании бекапа…
1. 2. проблема не в селектах (У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.) если это выключить и оставить на базе, то селектов будет около 5000 к 500 апдейтов и 100 инсертов. Когда такое было не помогал ни мемкеш не что либо… поэтому и был написан демон робота которого как мемкеш только на С++ поэтому в разы быстрее… и в итоге уперлись в апдейты при работе с дисками…
1. 2. проблема не в селектах (У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.) если это выключить и оставить на базе, то селектов будет около 5000 к 500 апдейтов и 100 инсертов. Когда такое было не помогал ни мемкеш не что либо… поэтому и был написан демон робота которого как мемкеш только на С++ поэтому в разы быстрее… и в итоге уперлись в апдейты при работе с дисками…
И насчет MySQL в общем — почитайте MySQL Perfomance Book. Относительно недавно вышел перевод 2-го издания на русский язык.
Ага. А есть перевод ее — www.books.ru/shop/books/734220
В общем единственная потенциальная проблема — это рост базы. Но сейчас память в серваках достаточно дешевая и увеличить её не составит проблем (на части машин у нас 16Gb, на части 8Gb, но, насколько мне известно, можно поставить в потолке 128Gb)
Купите сервачок в 2U всё само будет только в оперативной памяти…
Купите сервачок в 2U всё само будет только в оперативной памяти…
много раз облизнулся, но слюни всеравно текут…
Мне тоже машинка очень нравится, единственное что стоит приличных денег даже в минимальной платформе(подумываю не взять ли её в лизинг)
и конечно, если её ставить на коло в РФ — то доплачивать придётся за мощность(а это обычно приличные деньги). В нашем латвийском ДЦ за коло такой тачанки возьмут всего 1450р(или со скидкой можно — 1233р)…
и конечно, если её ставить на коло в РФ — то доплачивать придётся за мощность(а это обычно приличные деньги). В нашем латвийском ДЦ за коло такой тачанки возьмут всего 1450р(или со скидкой можно — 1233р)…
128 уже давно в обычный сервак лезет, щас 192, а то вроде уже и 256 есть :) Модули по 8GB и 16GB анонс вроде проскакивал :)
То есть в то время, когда mysql-ю не хватает памяти для работы с таблицами, вы, вместо того, чтобы оптимизировать хранение данных, откусываете у него еще больше памяти?
you made my day.
you made my day.
Tmpfs вообще хорошо помогает, там где идет активная работа с диском. Я так с Imap-Cyrus баловался на допотопном железе.
Если запросы в основном на запись, то можно попробовать PostgereSQL
приставки «з» не бывает.
Кстати еще tmpdir = /dev/shm в конфиге, мелочь, а приятно :)
скорость восстановления если машина рухнула состоит из времени поднятия машины+копирования бекапа+ разархивирования его + поднятие базы в среднем занимает около 3-5 минут, ну так если сервер рухнул в любом случае демоны не могут до стучаться до базы пока сервер лежит… теряется время в отличии от стандартного подъема сервера отличается только на копировании и развертывании бекапа…
слейвы при подъеме мастера со слейвы поднять меньше минуты…
про mysqldump забыли уже давно… бекапим методом снапшотов LVM, а данном случае снапшотов памяти
опыт сейчас работает
слейвы при подъеме мастера со слейвы поднять меньше минуты…
про mysqldump забыли уже давно… бекапим методом снапшотов LVM, а данном случае снапшотов памяти
опыт сейчас работает
у вас на 100 апдейтов одной записи идет одно ее чтение. Вывод — 99 из 100 апдейтов бесполезны и их можно выбросить.
зачем вам тут вообще база? складывайте сериализованные данные по пользователю на FS одним файлом. Придет пользователь снова — прочитаете. Или храните все его объекты в одном поле в бд в виде блоба или xml между сессиями.
зачем вам тут вообще база? складывайте сериализованные данные по пользователю на FS одним файлом. Придет пользователь снова — прочитаете. Или храните все его объекты в одном поле в бд в виде блоба или xml между сессиями.
Чтений на много больше только их отдает демон С++ (У нас данные не в базе и даже не в кеше, а в памяти демона на C++ (то есть на время сессии мастер копия данных будет в памяти, а не в базе). Вся база данных, которая не относится к пользователям — опять же хранится в памяти демона.) если это выключить и оставить на базе, то селектов будет около 5000 к 500 апдейтов и 100 инсертов. Когда такое было не помогал ни мемкеш не что либо… поэтому и был написан демон робота которого как мемкеш только на С++ поэтому в разы быстрее… и в итоге уперлись в апдейты при работе с дисками…
Ну да, так это не противоречит моему утверждению. Из самой базы вы читаете редко, а значит постоянные ее апдейты просто мозолят диск, создавая ненужный overhead. Ошибки здесь две:
1) вам абсолютно не нужна здесь реляционная база для хранения стейта пользователя. без разницы, где все это хранить. на файловой системе, в key-value или еще где то.
2) если все же хочется мускуль. зачем вам в базе квантовать состояние игры пользователя до отдельных объектов? собирайте их в один большой массив, объект или что у вас там, сериализуйте его и пишите с той же частотой в базу. Апдейтов будет в N раз меньше, где N — количество объектов под одним пользователем.
1) вам абсолютно не нужна здесь реляционная база для хранения стейта пользователя. без разницы, где все это хранить. на файловой системе, в key-value или еще где то.
2) если все же хочется мускуль. зачем вам в базе квантовать состояние игры пользователя до отдельных объектов? собирайте их в один большой массив, объект или что у вас там, сериализуйте его и пишите с той же частотой в базу. Апдейтов будет в N раз меньше, где N — количество объектов под одним пользователем.
Sign up to leave a comment.
MySQL в tmpfs