MemcacheDB и MemcacheQ — ключевые компоненты высокопроизводительной инфраструктуры

    Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.



    Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.



    Memcached давно известен как сервер кеширования данных, который используется на многих высоконагруженных проектах, включая Wikipedia и LiveJournal, и позволяет кешировать в памяти любые данные и быстро ими оперировать, при этом поддерживаются только самые простые операции, это уж явно не полноценная база данных. А использование в качестве хранилища данных памяти идеально для случая кеширования данных, но если речь заходит про надёжность или устойчивость к сбоям — здесь работа переложена на сам сервер и оборудование.

    Вот для решения всех этих вопросов, для совмещения высокой скорости, простого интерфейса и принципов работы memcached, и надёжности обычных баз данных, и был разработан MemcacheDB. Это система распределённого хранения данных в виде пар ключ-значение, которая совместима с API memcached, а значит любой клиент прозрачно может работать как с кешем, так и с хранилищем данных, даже не замечая этого. Но, в отличии от кеша, данные в memcacheDB хранятся на диске — в качестве бекенда используется встраиваемая промышленная база BerkeleyDB и используются все возможности для обеспечения эффективности и надёжности хранения, в частности, транзакционность и реплицирование.



    По скорости доступа к данным memcacheDB стоит на уровне того же memcache и сравнимо с специализированными базами данных, например, CouchDB, а в цифрах это составляет десятки тысяч операций записи и чтения в секунду (а вот и бенчмарк, а также сравнение с CouchDB). Сами разработчики предупреждают, что memcacheDB никак не кеш, поэтому не стоит использовать его везде как замену для самого memcached, он просто реализует другую стратегию хранения данных с совместимым доступом, аналогично memcached.

    Несмотря на самые простые операции с данными — запись, чтение, обновление и удаление, такого функционала очень часто хватает для большинства задач, где мы привыкли использовать обычные базы данных. Но если перенести часть операций на специализированные решения, это позволит существенно разгрузить основную базу для операций, где требуются уже серьёзные средства работы с данными. Например, поддерживается команда инкремента/декремента переменных, что позволит реализовать различные счётчики и статистику без обращения к базе, при этом система сможет обслуживать тысячи клиентов в реальном времени.



    Развёртывается memcacheDB просто — устанавливаете и компилируете с исходников, устанавливаете базу данных (она не требует администрирования) и все. Настройте просто параметры доступа для клиентов — порт и несколько других параметров, влияющих на производительность, например, размер буфера данных, каталог для хранения базы данных, размер кеша в памяти. Не думайте, что все операции чтения идут с диска, раз система использует базу данных в виде файла на диске, конечно используется и кеширование, что позволяет сравниваться в скорости с оригинальным memcached, при этом обеспечивая ещё и надёжность хранения.

    Самым интересным свойством memcacheDB является возможность работы на нескольких серверах, используя реплицирование для обмена данными и синхронизации баз данных. При этом memcacheDB может использовать несколько стратегий реплицирования, в зависимости от ваших потребностей, гарантирующих целостность данных или обеспечивающих скорость работы. Основная модель распределённой инфраструктуры, поддерживаемая системой — один мастер-сервер и несколько подчинённых slave-серверов, которые используются только для чтения данных.

    В случае нескольких серверов, система может использовать следующие стратегии репликации:
    • DB_REPMGR_ACKS_ALL — мастер-сервер ожидает подтверждения о успешной записи данных от всех остальных серверов;
    • DB_REPMGR_ACKS_ALL_PEERS — мастер ожидает ответа от всех slave-серверов, которые являются, в свою очередь, мастер-серверами для своих групп (многоуровневая система);
    • DB_REPMGR_ACKS_NONE — не ожидаем никаких подтверждений от других серверов. Самая большая скорость, но нет гарантий, что копии данных есть на других серверах, кроме мастера.
    • DB_REPMGR_ACKS_ONE — ожидаем подтверждения хоть бы одного из серверов;
    • DB_REPMGR_ACKS_ONE_PEER — так же, как в предыдущем случае, но подтверждение ожидается от сервера, который в свою очередь, является мастер-сервером для своей группы.
    • DB_REPMGR_ACKS_QUORUM — ожидаем подтверждения от некоторого минимального числа серверов, которые гарантируют целостность данных и являются также мастер-серверами для своих групп. Эта стратегия используется по умолчанию.




    Пока необходимо, чтобы все сервера в группе использовали одну и ту же стратегию реплицирования, но я не уверен, что это касается именно сложных систем, где много групп — в конце концов можно настроить так, что запрос будет распределятся сначала по одной группе серверов с одной стратегией, а потом данные распределяются по другому алгоритму, при этом корневой сервер даже не подозревает об этом.

    Отдельно поддерживается логгирование и бекап самих файлов базы данных, в том числе и горячий бекап, но это отдельный разговор и конкретика инсталляции и использования.

    И так, у нас есть возможность организовать… такой себе сервис Amazone S3, при этом как угодно распределённый, быстрый и надёжный, с простым и понятным универсальным API. Применения такой системе есть множество, практически в каждом высоконагруженном проекте можно часть логики перенести с базы данных на такую систему хранения и получить высокую отказоустойчивость и обеспечить снятие нагрузки по множеству простых запросов с основной базы данных.

    Второй проект, также основанный на коде memcached — memcacheQ. Это система очередей сообщений, которая имеет ещё более простой API и поддерживает только две команды, запись и чтение. Очередь сообщений это некоторый именованый стек, куда можно записать сообщения, а клиент, указывая имя очереди, в любой другой момент времени может получить все сообщения из очереди. Максимальный размер сообщения равен 64Кб, а сами данные хранятся в той самой базе данных BerkeleyDB, а значит обеспечивается те же условия сохранности данных, реплицирование и другие возможности. Такую систему можно использовать для построения систем общения между пользователей в рамках проекта, почтовых систем, чата и других аналогичных, где требуется такой функционал, умноженный на большую скорость и надёжность.

    Эти два проекта, MemcacheDB и MemcacheQ являются достаточно простыми в плане внешнего интерфейса и, казалось бы, ограниченные в возможностях, но вместе с этим позволяют строить на своей основе очень мощные и высоконагруженные проекты, если вы будете учитывать их возможности ещё на этапе проектирования. Для многих проектов это позволит отказаться или сократить нагрузку на дорогие ресурсы в виде базы данных и обеспечить высокую отказоустойчивость и гибкость.
    Share post

    Comments 23

      0
      Очень многа букв, но честно прочитал все — много общих слов и мало примеров.
        +3
        потому что это обзор. примеров нет принципиально — кому понадобися, тот найдет и посмотрит и сделает, нечего плодить копипаст. так как планирую использовать у себя, то как наберусь практического опыта в использовании, напишу. а так этот материал показывает что есть такое и для чего и как оно устроено в общих чертах.
        +1
        > «По скорости доступа к данным memcacheDB стоит на уровне того же memcache»
        > «Но, в отличии от кеша, данные в memcacheDB хранятся на диске»

        Невозможное возможно? Как им это удалось и куда смотрят остальные разработчики БД?
          0
          почитайте что возможно и за счет чего. ну и код открытый, смотрите :) там таоже база + кеш в памяти но очень узко специализированная база
            0
            Да, согласен, ее скорость (как специализированной БД) может быть выше обычных.
            Но доступ к реплицированной штуке, хранящейся на диске все равно по идее должен быть реально медленее, чем к оперативке той же машины…
            0
            Какая разница, что где хранится? В любом случае на физическом уровне чтение идет из оперативки.
            0
            Интересно познавательно. Но пара примеров использования для одной и второй системы не помешали бы.
              0
              Memcache далеко не панацея, за время эксплуатации замечена особенность, при вытеснении данных, он не вытесняет не только из устаревших данных, в итоге получается, что забит устаревшими данными, но при этом вытесняет еще неустаревшие, в итоге при его забитости эффиктивность может упасть чуть ли не до 0.
                0
                Memcache далеко не панацея, за время эксплуатации замечена особенность, при вытеснении данных, он не вытесняет не только из устаревших данных, в итоге получается, что забит устаревшими данными, но при этом вытесняет еще неустаревшие, в итоге при его забитости эффиктивность может упасть чуть ли не до 0.
                  0
                  с временем жизни играться не прообовали?
                    0
                    Пробовал по разному, не помогло.
                  0
                  Полгода назад MemcacheDB был очень сырой и практически неизвестной разработкой ребят из Google. Я его щупал, но на практике попользоваться не получилось :( Новый проект на новой архитектуре отменился :(
                  По скорости работы с одновременной нагрузкой на проц просто впечатляет. Только полгода назад его возможности были немного недостаточны для полноценного использования. Уже и не вспомню что тогда не понравилось.
                    0
                    пару дней назад вышла как раз ужу 1.1 версия, так что пользоваться можно вроде как
                    0
                    Классное решение для очень нагруженного кэша. И развитая распределённость. Определенно в букмарки!
                      0
                      Спасибо. Очень интересно. Если еще можно лазить напрямую в BDB, то появляется возможность поиска по ключу, чего иногда сильно не хватает в memcached.
                        0
                        Интересно попробовать. Завтра доберусь до работы и проверим, хороша ли система.
                        За статью спасибо!
                          0
                          автор не расскажет каким боком там работаем сам мемкеш? Правильно я понимаю, что идет полное(вернее сколько влезет) дублирования данных из БД? Тогда, если мы изменяем то, что уже вытеснено из кеша, оно там поднимается в новом виде а потом в БД?
                          Сори, самому капаться пока некогда, может в курсе процесса.
                            0
                            Сорри, я не автор, но интересуюсь этими разработками:
                            Да, есть такое понятие как db checkpoint — слить все с памяти на диск. Если данных нет — вытаскиваем из БД
                            0
                            с нетерпением жду возможности попробовать MemcacheQ
                              0
                              Ну как впечатления от MemcacheQ?

                              Мог бы кто-нибудь привести примеры использования системы очередей?
                              0
                              Наверное это очень мощная вещь, но вот из топика я не понял — а чем оно принципиально отличается от самого BerkeleyDB? Только интерфейсом, совместимым с memcached?
                                0
                                Спасибо за наводку. То, что надо, для одной текущей задачи. Хранение с быстрым доступом и примитивным интерфейсом. Хорошо бы еще и запись была пошустрее.
                                Сегодня-вчера поставил, нашел рыбу на запись-чтение, на неделе попробую в работе. Сравню с самопальными индексами.
                                  0
                                  Ага, круто. Еще вроде бы все эти штуки называются «нереляционные базы данных».

                                  Only users with full accounts can post comments. Log in, please.