Comments 31
Работаю над сайтом с посещаемостью около 5 миллионов уникальный в месяц, и мы никогда не сталкивались с такой проблемой. Логины проходят нормально, регистраций тоже по несколько тысяч в день.
База с репликацией.
У каждого свои проблемы это понятно, возможно пригодится ваше решение, т.к оно решило ваши проблемы.
Спасибо.
База с репликацией.
У каждого свои проблемы это понятно, возможно пригодится ваше решение, т.к оно решило ваши проблемы.
Спасибо.
Я предполагаю что проблемы у нас возникли прежде всего из-за того, что каждый второй пользователь — новый, и соответственно при 50 тысячах уникальных посетителей в день мы имеем 25 тысяч новых регистраций.
В любом случае — если возникнут проблемы и будет необходима помощь — пишите, всегда готов помочь!
В любом случае — если возникнут проблемы и будет необходима помощь — пишите, всегда готов помочь!
Регистрация пользователя каждые 3.5 (а в пике — каждые полторы) секунды не должна вроде так ложить базу. Средний сервер mysql выдает порядка 100-200 запросов в секунду.
Это понятно, однако здесь играют роль еще несколько факторов:
1. Сервер нагружен и другой работой.
2. Пользователи довольно часто хотят получить данные о своих друзьях, к сожалению не могу привести конкретный пример — NDA, но — для примера это могут быть какие-либо данные созданные пользователями-друзьями.
Понятно что классический пример здесь — создание очередей для каждого пользователя, но здесь в силу вступает проблема разработки — исходная база проекта не наша и мы постепенно оптимизируем ее, поэтому очереди только в планах, а пока — MemcacheDB для того чтобы не нагружать MySQL выборками.
1. Сервер нагружен и другой работой.
2. Пользователи довольно часто хотят получить данные о своих друзьях, к сожалению не могу привести конкретный пример — NDA, но — для примера это могут быть какие-либо данные созданные пользователями-друзьями.
Понятно что классический пример здесь — создание очередей для каждого пользователя, но здесь в силу вступает проблема разработки — исходная база проекта не наша и мы постепенно оптимизируем ее, поэтому очереди только в планах, а пока — MemcacheDB для того чтобы не нагружать MySQL выборками.
И полтора миллиона это ваще нивапрос, мы вот работаем с такими табличками:
img222.imageshack.us/img222/2505/mysql.png
img222.imageshack.us/img222/2505/mysql.png
290 миллионов записей?
Из картинки я вижу что между чеком и апдейтом прошли сутки.
Таблица в MyISAM-е, а следовательно table-lock-и на инстертах и апдейтах.
Два вопроса —
Как часты у вас операции чтения на ней?
Что будет если ее начнут апдейтить и инсертить каждую секунду, при гораздо большей частоте селектов, с учетом тейбл локов?
Из картинки я вижу что между чеком и апдейтом прошли сутки.
Таблица в MyISAM-е, а следовательно table-lock-и на инстертах и апдейтах.
Два вопроса —
Как часты у вас операции чтения на ней?
Что будет если ее начнут апдейтить и инсертить каждую секунду, при гораздо большей частоте селектов, с учетом тейбл локов?
Из картинки я вижу что между чеком и апдейтом прошли сутки.
o_0 сутки !?
Update time: 25.03.2009
Check time: 26.05.2008
да, не обратил внимание, извиняюсь :))
да я тоже не лучше. открыл статью, отвлекся, запостил коммент а тема то уже раскрыта )
И еще один вопрос, опять же про MyISAM
при отрубившемся питании — сколько времени на ней будет идти repair, и что будут делать все это время пользователи? :)
при отрубившемся питании — сколько времени на ней будет идти repair, и что будут делать все это время пользователи? :)
Ага 290М. Между чеком и апдейтом прошел год. Так сложилось что аптайм у железяки — «up 227+18:33:28» :)
В таблицу в основном инсерт. Выборки производятся на последних 35% записей, в основном. Если будет и то и другое очень часто или селектов будет больше — будет плохо, в этом случае нужна репликация на slave server куда будут SELECT идти. И чек такой таблицы где-то 2-3 часа происходит, пользователи пока курят. Но с другой стороны данных-то много и работать как-то нужно. И да, там нет текстовых индексов.
Чудес-то не бывает :)
В таблицу в основном инсерт. Выборки производятся на последних 35% записей, в основном. Если будет и то и другое очень часто или селектов будет больше — будет плохо, в этом случае нужна репликация на slave server куда будут SELECT идти. И чек такой таблицы где-то 2-3 часа происходит, пользователи пока курят. Но с другой стороны данных-то много и работать как-то нужно. И да, там нет текстовых индексов.
Чудес-то не бывает :)
А чем приниципиально схема отличается от обычного Мемкешед? Наличием репликаций?
Всё равно ж система работает как кеш, данные ведь как и ранее так пишутся в базу.
Или ваш суточный крон не просто проверяет целостность, а синхронизирует базы? (т.е. только он пишет в MySQL)
И ещё пару вопросов для уснения:
— memcachedb может использоваться как замена memcached?
— сложно ли перевести проект с memcached на memcachedb. По идее нет, но всё-таки хотелось бы уточнить :)
Всё равно ж система работает как кеш, данные ведь как и ранее так пишутся в базу.
Или ваш суточный крон не просто проверяет целостность, а синхронизирует базы? (т.е. только он пишет в MySQL)
И ещё пару вопросов для уснения:
— memcachedb может использоваться как замена memcached?
— сложно ли перевести проект с memcached на memcachedb. По идее нет, но всё-таки хотелось бы уточнить :)
Дело в том что 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 месяца не слишком большой срок и неизвестно что еще может появится).
Первое — это 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 месяца не слишком большой срок и неизвестно что еще может появится).
Спасибо. И ещё вопрос, запись в MySQL вы делаете по требованию или по времени?
Любая регистрация или изменение данных пользователя влечет за собой запись в MySQL, то есть старая схема — она осталась такой же как есть, на тот случай если ее понадобится быстро вернуть, просто в нее делаются только записи, нет никакого чтения.
С недавних пор некритичные изменения в данных мы записываем только в MemcacheDB, полагаясь на реплицированную бэкапную базу MCDB.
В идеале — мы хотим чтобы MySQL стал лишь надежным хранилищем данных а основная работа бы легла на MemcacheDB и memcache. Для логики сортировок — приглядываемся к redis (http://code.google.com/p/redis/)
С недавних пор некритичные изменения в данных мы записываем только в MemcacheDB, полагаясь на реплицированную бэкапную базу MCDB.
В идеале — мы хотим чтобы MySQL стал лишь надежным хранилищем данных а основная работа бы легла на MemcacheDB и memcache. Для логики сортировок — приглядываемся к redis (http://code.google.com/p/redis/)
у меня возникли схожие вопросы с Davert вопросы. После прочтения статьи не понял почему проблемы возникли именно на логировании?? пусть, к примеру, у нас 10 000 посетителей в день, из них 50% новых. А из оставшихся 50% будут уже залогированные (вы же ведь сделали чекбокс запомнить меня). итого 50 % на регистрацию и, приблизительно, 10-25% на логирование. Как же так получилось, что логирование пользователей стало бутылочным горлышком? Почему остальной функционал используется меньше?
Еще вопрос, зачем данные пользователя хранить в мемкеше, если их удобней хранить в сессии. И еще вопрос, в мемкеш же не ризиновый и влезут ли 10 миллионов записей туда?
Еще вопрос, зачем данные пользователя хранить в мемкеше, если их удобней хранить в сессии. И еще вопрос, в мемкеш же не ризиновый и влезут ли 10 миллионов записей туда?
Прошу обратить внимание что Memcache и MemcacheDB это очень разные вещи как я уже сказал.
MemcacheDB это persistent-ная база данных, хранящая свои данные в BerkeleyDB и использующая memcache как систему кэширования часто выдаваемых данных, соответственно 10 миллионов записей туда войдут, в настоящий момент у нас сохранено 4 миллиона пар и видно что это даже не толика предела.
К сожалению, я не указал в статье что помимо инсертов и селектов на таблицу ложится большое число апдейтов, таких как смена профайл пиков и другой информации — таких операций ОЧЕНЬ много.
MemcacheDB же как раз способен снять нагрузку с MySQL для выборок и записей по primary ключам, работая при этом быстрее.
Здесь: memcachedb.org/benchmark.html можно посмотреть некоторые бенчмарки.
Если остались вопросы — задавайте! Буду рад ответить :)
MemcacheDB это persistent-ная база данных, хранящая свои данные в BerkeleyDB и использующая memcache как систему кэширования часто выдаваемых данных, соответственно 10 миллионов записей туда войдут, в настоящий момент у нас сохранено 4 миллиона пар и видно что это даже не толика предела.
К сожалению, я не указал в статье что помимо инсертов и селектов на таблицу ложится большое число апдейтов, таких как смена профайл пиков и другой информации — таких операций ОЧЕНЬ много.
MemcacheDB же как раз способен снять нагрузку с MySQL для выборок и записей по primary ключам, работая при этом быстрее.
Здесь: memcachedb.org/benchmark.html можно посмотреть некоторые бенчмарки.
Если остались вопросы — задавайте! Буду рад ответить :)
спасибо за ответы.
А Вы рассматривали вариант с распределнными серверами допустим поставить 3-4 читающих сервера и 1 пишущий?
А Вы рассматривали вариант с распределнными серверами допустим поставить 3-4 читающих сервера и 1 пишущий?
я вот еще что подумал, а можно взглянуть на структуру таблиц для юзеров? возможно у вас слишком широкие таблички, в таком случае можно их разбить на несколько более маленьких, допустим по частоте изменения данных
Тут проблема в то что мы обычно помогаем сервисам с относительно не большим количеством средств на развитие, несколько серверов на авторизацию — это сильно затратно.
А тут стоит себе MemcacheDB и авторизует, и при этом на этом же сервере еще многое вполне себе работает. А таблица широкая, да, вы угадали, опять же досталась в наследство.
Просто мы в условиях ограниченности ресурсов пытаемся максимально снизить нагрузку оставляя возможность для быстрых откатов от изменений, а посему проводим эксперименты в пределах заинтересованности заказчиков :)
А тут стоит себе MemcacheDB и авторизует, и при этом на этом же сервере еще многое вполне себе работает. А таблица широкая, да, вы угадали, опять же досталась в наследство.
Просто мы в условиях ограниченности ресурсов пытаемся максимально снизить нагрузку оставляя возможность для быстрых откатов от изменений, а посему проводим эксперименты в пределах заинтересованности заказчиков :)
тогда все становится более понятным. Ну что вариант хорош, еще бы статистических данных бы. Кстати как оказалось BerkeleyDB частоиспользуемая не реляционная БД. Плохо немного то, что юзера хранятся в другой системе, к примеру более сложные поиски по юзерам будут происходить все равно по БД. Вы будете использовать MemcacheDB только когда точно знаете UserID.
Статистику надеемся опубликовать после консультации собственно с заказчиками, у нас довольно строгое NDA к сожалению по этому проекту :(
Насчет выборок — здесь у нас глобальная идея в том чтобы сложные выборки тоже вынести из MySQL в Sphinx превращая атрибуты в полнотекстовые данные вида «AGE_BETWEEN_18_25 CITY_MOSCOW SEX_FEMALE» и соответственно организуя поиск по этим данным например по тексту «CITY_MOSCOW SEX_FEMALE» на полное наличие двух слов. В проектах которые мы делали с нуля этот способ отлично себя зарекомендовал, но это соверешнно отдельная тема, и я думаю сделать про нее отдельную статью. Там уже будет мно-о-о-го статистики :)
Насчет выборок — здесь у нас глобальная идея в том чтобы сложные выборки тоже вынести из MySQL в Sphinx превращая атрибуты в полнотекстовые данные вида «AGE_BETWEEN_18_25 CITY_MOSCOW SEX_FEMALE» и соответственно организуя поиск по этим данным например по тексту «CITY_MOSCOW SEX_FEMALE» на полное наличие двух слов. В проектах которые мы делали с нуля этот способ отлично себя зарекомендовал, но это соверешнно отдельная тема, и я думаю сделать про нее отдельную статью. Там уже будет мно-о-о-го статистики :)
> 1. MemcacheDB на малых больших объемах
На малых или больших?
На малых или больших?
Есть ли возможность в memcacheDB получить все значения ключей? То есть нужен какой-то механизм позволяющий установить одинаковые метки на большое кол-во записей и потом выгрузить все записи по этой метке.
Почему никто не вспомнил про MEMORY(HEAP) таблицы мускула?
В них также прекрасно можно хранить кеш.
В них также прекрасно можно хранить кеш.
Sign up to leave a comment.
Создание системы авторизации в высоконагруженном проекте с использованием MemcacheDB