Тут проблема в то что мы обычно помогаем сервисам с относительно не большим количеством средств на развитие, несколько серверов на авторизацию — это сильно затратно.
А тут стоит себе MemcacheDB и авторизует, и при этом на этом же сервере еще многое вполне себе работает. А таблица широкая, да, вы угадали, опять же досталась в наследство.
Просто мы в условиях ограниченности ресурсов пытаемся максимально снизить нагрузку оставляя возможность для быстрых откатов от изменений, а посему проводим эксперименты в пределах заинтересованности заказчиков :)
И еще один вопрос, опять же про MyISAM
при отрубившемся питании — сколько времени на ней будет идти repair, и что будут делать все это время пользователи? :)
Прошу обратить внимание что Memcache и MemcacheDB это очень разные вещи как я уже сказал.
MemcacheDB это persistent-ная база данных, хранящая свои данные в BerkeleyDB и использующая memcache как систему кэширования часто выдаваемых данных, соответственно 10 миллионов записей туда войдут, в настоящий момент у нас сохранено 4 миллиона пар и видно что это даже не толика предела.
К сожалению, я не указал в статье что помимо инсертов и селектов на таблицу ложится большое число апдейтов, таких как смена профайл пиков и другой информации — таких операций ОЧЕНЬ много.
MemcacheDB же как раз способен снять нагрузку с MySQL для выборок и записей по primary ключам, работая при этом быстрее.
290 миллионов записей?
Из картинки я вижу что между чеком и апдейтом прошли сутки.
Таблица в MyISAM-е, а следовательно table-lock-и на инстертах и апдейтах.
Два вопроса —
Как часты у вас операции чтения на ней?
Что будет если ее начнут апдейтить и инсертить каждую секунду, при гораздо большей частоте селектов, с учетом тейбл локов?
Это понятно, однако здесь играют роль еще несколько факторов:
1. Сервер нагружен и другой работой.
2. Пользователи довольно часто хотят получить данные о своих друзьях, к сожалению не могу привести конкретный пример — NDA, но — для примера это могут быть какие-либо данные созданные пользователями-друзьями.
Понятно что классический пример здесь — создание очередей для каждого пользователя, но здесь в силу вступает проблема разработки — исходная база проекта не наша и мы постепенно оптимизируем ее, поэтому очереди только в планах, а пока — MemcacheDB для того чтобы не нагружать MySQL выборками.
Любая регистрация или изменение данных пользователя влечет за собой запись в MySQL, то есть старая схема — она осталась такой же как есть, на тот случай если ее понадобится быстро вернуть, просто в нее делаются только записи, нет никакого чтения.
С недавних пор некритичные изменения в данных мы записываем только в MemcacheDB, полагаясь на реплицированную бэкапную базу MCDB.
В идеале — мы хотим чтобы MySQL стал лишь надежным хранилищем данных а основная работа бы легла на MemcacheDB и memcache. Для логики сортировок — приглядываемся к redis (http://code.google.com/p/redis/)
Дело в том что Memcache и MemcacheDB — это разные вещи.
Первое — это key-value кэш в оперативной памяти.
Второе носит свое название из-за интеграции Memcache и BerkeleyDB и состоит из кэша memcache и базы BerkeleyDB.
Записанные ключ-значения сохраняются в постоянно существующую базу BerkeleyDB и кэшируются в memcache.
При запросе ключа происходит вот что:
1. MCDB проверяет наличие этого ключа в кэше себственного memcache.
2. Если есть — MCDB отдает данные непосредственно из memcache если нет то:
3. MCDB получает данные по ключу из BerkeleyDB базы, кэширует это значение в memcache и отдает результат.
4. При повторных запросах этого же ключа — результат берется из memcache.
База может быть объемом в несколько гигабайт, при этом memcache-кэш может занимать например 512 мегабайт и там будут храниться только часто требуемые пары.
Таким образом если memcache — это временное хранилище пар ключ-значение, которые со временем уходят, ну собственно — кэш, то MCDB это постоянна хранящая значения база данных.
Для данных которые нужно только кэшировать и которые не страшно со временем потерять — лучше использовать memcache.
Для данных которые можно получать по ключу и которые нужно ХРАНИТЬ — можно использовать MemcacheDB.
Их вполне можно использовать вместе.
В MySQL мы пишем лишь для контроля целостности MCDB — если из-за какой то ошибки он перестанет работать и слетит бэкап, или если окажется что он нам не подходит (все таки 2 месяца не слишком большой срок и неизвестно что еще может появится).
Я предполагаю что проблемы у нас возникли прежде всего из-за того, что каждый второй пользователь — новый, и соответственно при 50 тысячах уникальных посетителей в день мы имеем 25 тысяч новых регистраций.
В любом случае — если возникнут проблемы и будет необходима помощь — пишите, всегда готов помочь!
Вообще тут две вещи.
1. Делать репликацию на еще один мцдб для быстрого восстановления.
2. Дублировать все в бэкэнд в виде мускуля и по крону раз в день проверять целостность например.
Вообще я тут статейку накатал как мы делали, сейчас в течении получаса в блог засуну свой :)
Для аналогичных целей мы используем MemcacheDB.
Первоначально для всего использовался связка mysql+memcache, естественно активно применяли шардинг, но когда число пользователей перешло за полтора миллиона, поняли что систему авторизации надо перевести на что-то простое и быстрое.
Главная проблема с которой стокнулись — ошибка connection timed out при росте MemcacheDB базы данных на модуле pecl-memcache на PHP.
Пытались достигнуть стабильности несколько дней, менятяя таймауты, версии MemcacheDB, собирая отдельные компоненты из разных версий.
В итоге, отчаяшись написали письмо Steve Chu, автору MCDB — и, о чудо, через день пришел ответ с рекоммендацией использовать модуль pecl-memcached (http://pecl.php.net/package-info.php?package=memcached) от небезызвестного Andrei Zmievski, использующий libmemcached в качестве средства соединения с memcache.
В итоге авторизация уже два месяца стабильно работает на memcachedb показывая значительно лучшие результаты по сравнению с mysql+memcache
Каждой задаче — свое решение :)
А тут стоит себе MemcacheDB и авторизует, и при этом на этом же сервере еще многое вполне себе работает. А таблица широкая, да, вы угадали, опять же досталась в наследство.
Просто мы в условиях ограниченности ресурсов пытаемся максимально снизить нагрузку оставляя возможность для быстрых откатов от изменений, а посему проводим эксперименты в пределах заинтересованности заказчиков :)
при отрубившемся питании — сколько времени на ней будет идти repair, и что будут делать все это время пользователи? :)
MemcacheDB это persistent-ная база данных, хранящая свои данные в BerkeleyDB и использующая memcache как систему кэширования часто выдаваемых данных, соответственно 10 миллионов записей туда войдут, в настоящий момент у нас сохранено 4 миллиона пар и видно что это даже не толика предела.
К сожалению, я не указал в статье что помимо инсертов и селектов на таблицу ложится большое число апдейтов, таких как смена профайл пиков и другой информации — таких операций ОЧЕНЬ много.
MemcacheDB же как раз способен снять нагрузку с MySQL для выборок и записей по primary ключам, работая при этом быстрее.
Здесь: memcachedb.org/benchmark.html можно посмотреть некоторые бенчмарки.
Если остались вопросы — задавайте! Буду рад ответить :)
Из картинки я вижу что между чеком и апдейтом прошли сутки.
Таблица в MyISAM-е, а следовательно table-lock-и на инстертах и апдейтах.
Два вопроса —
Как часты у вас операции чтения на ней?
Что будет если ее начнут апдейтить и инсертить каждую секунду, при гораздо большей частоте селектов, с учетом тейбл локов?
1. Сервер нагружен и другой работой.
2. Пользователи довольно часто хотят получить данные о своих друзьях, к сожалению не могу привести конкретный пример — NDA, но — для примера это могут быть какие-либо данные созданные пользователями-друзьями.
Понятно что классический пример здесь — создание очередей для каждого пользователя, но здесь в силу вступает проблема разработки — исходная база проекта не наша и мы постепенно оптимизируем ее, поэтому очереди только в планах, а пока — MemcacheDB для того чтобы не нагружать MySQL выборками.
С недавних пор некритичные изменения в данных мы записываем только в MemcacheDB, полагаясь на реплицированную бэкапную базу MCDB.
В идеале — мы хотим чтобы MySQL стал лишь надежным хранилищем данных а основная работа бы легла на MemcacheDB и memcache. Для логики сортировок — приглядываемся к redis (http://code.google.com/p/redis/)
Первое — это key-value кэш в оперативной памяти.
Второе носит свое название из-за интеграции Memcache и BerkeleyDB и состоит из кэша memcache и базы BerkeleyDB.
Записанные ключ-значения сохраняются в постоянно существующую базу BerkeleyDB и кэшируются в memcache.
При запросе ключа происходит вот что:
1. MCDB проверяет наличие этого ключа в кэше себственного memcache.
2. Если есть — MCDB отдает данные непосредственно из memcache если нет то:
3. MCDB получает данные по ключу из BerkeleyDB базы, кэширует это значение в memcache и отдает результат.
4. При повторных запросах этого же ключа — результат берется из memcache.
База может быть объемом в несколько гигабайт, при этом memcache-кэш может занимать например 512 мегабайт и там будут храниться только часто требуемые пары.
Таким образом если memcache — это временное хранилище пар ключ-значение, которые со временем уходят, ну собственно — кэш, то MCDB это постоянна хранящая значения база данных.
Для данных которые нужно только кэшировать и которые не страшно со временем потерять — лучше использовать memcache.
Для данных которые можно получать по ключу и которые нужно ХРАНИТЬ — можно использовать MemcacheDB.
Их вполне можно использовать вместе.
В MySQL мы пишем лишь для контроля целостности MCDB — если из-за какой то ошибки он перестанет работать и слетит бэкап, или если окажется что он нам не подходит (все таки 2 месяца не слишком большой срок и неизвестно что еще может появится).
В любом случае — если возникнут проблемы и будет необходима помощь — пишите, всегда готов помочь!
1. Делать репликацию на еще один мцдб для быстрого восстановления.
2. Дублировать все в бэкэнд в виде мускуля и по крону раз в день проверять целостность например.
Вообще я тут статейку накатал как мы делали, сейчас в течении получаса в блог засуну свой :)
Первоначально для всего использовался связка mysql+memcache, естественно активно применяли шардинг, но когда число пользователей перешло за полтора миллиона, поняли что систему авторизации надо перевести на что-то простое и быстрое.
Главная проблема с которой стокнулись — ошибка connection timed out при росте MemcacheDB базы данных на модуле pecl-memcache на PHP.
Пытались достигнуть стабильности несколько дней, менятяя таймауты, версии MemcacheDB, собирая отдельные компоненты из разных версий.
В итоге, отчаяшись написали письмо Steve Chu, автору MCDB — и, о чудо, через день пришел ответ с рекоммендацией использовать модуль pecl-memcached (http://pecl.php.net/package-info.php?package=memcached) от небезызвестного Andrei Zmievski, использующий libmemcached в качестве средства соединения с memcache.
В итоге авторизация уже два месяца стабильно работает на memcachedb показывая значительно лучшие результаты по сравнению с mysql+memcache