Pull to refresh

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

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



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

Читать дальше →
Total votes 50: ↑50 and ↓0 +50
Views 7.2K
Comments 23

Структуры данных в memcached/MemcacheDB. Часть 1

Website development *
Достаточно часто нам приходится хранить данные в memcached или MemcacheDB. Это могут быть относительно простые данные, например, закэшированные выборки из базы данных, а иногда необходимо хранить и обрабатывать более сложные структуры данных, которые обновляются одновременно из нескольких процессов, обеспечивать быстрое чтение данных и т.п. Реализация таких структур данных уже не укладывается в комбинацию команд memcached get/set. В данной статье будут описаны способы хранения некоторых структур данных в memcached с примерами кода и описанием основных идей.

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

Иногда проект разрабатывается изначально для нераспределенного случая (работа в рамках одного сервера), однако предполагая будущую необходимость масштабирования, лучше использовать сразу такие алгоритмы и структуры данных, которые могут обеспечить легкое масштабирование. Например, даже если данные будут храниться просто в памяти процесса, но интерфейс к доступа к ним повторяет семантику memcached, то при переходе к распределенной и масштабируемой архитектуре достаточно будет заменить обращения к внутреннему хранилищу на обращения к серверу (или кластеру серверов) memcached.
Читать дальше →
Total votes 47: ↑47 and ↓0 +47
Views 4.5K
Comments 23

Создание системы авторизации в высоконагруженном проекте с использованием MemcacheDB

Lumber room
Здравствуйте!

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

Где хранить аутентификационную базу пользователей?
Как быстро авторизовать пользователя по его строковому логину?
Как собирать распределенные по нескольким шард-таблицам и нескольким базам данных пользовательские данные?
Как заставить все это работать и как в этом нам может помочь MemcacheDB?

Читать подробности
Total votes 17: ↑17 and ↓0 +17
Views 1.6K
Comments 31

IMemcacheClient: нереляционность как религия

PHP *
Никакой проект не обходится без базы данных. Мы привыкли видеть в ней хранилище множества связанных объектов, с множеством условий. Это бесспорно очень удобно, но в силу разных обстоятельств, в нагруженной системе, чаще всего приходится прибегать к другим методам, т.к. кол-во выборок и транзакций ограничено современным железом, а запросто распределить на несколько серверов не получится. В ряде случаев можно использовать репликацию, но и это не паноцея на данный момент.
Читать дальше →
Total votes 6: ↑5 and ↓1 +4
Views 875
Comments 3

Redis — высокопроизводительное хранилище данных

Website development *
Бодрый день, хаброчеловеки!

Что такое Redis?


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

Чем Redis отличается от существующих решений?


API для работы с Memcached (MemcacheDB) позволяет хранить массивы, но эти массивы будут сериализованы и сохранены как строки, таким образом атомарные операции над такими массивами не возможны.
Redis позволяет хранить как строки, так и массивы, к которым можно применять атомарные операции pop / push, делать выборки из таких массивов, выполнять сортировку элементов, получать объединения и пересечения массивов.

Производительность


110000 запросов SET в секунду, 81000 запросов GET в секунду на Linux-сервере начального уровня (тесты).

Высокая скорость работы Redis обеспечивается тем, что данные хранятся в оперативной памяти и сохраняются на диск либо через равные промежутки времени, либо при превышении определённого количества не сохранённых запросов. Из этого вытекает, что используя Redis, вы можете потерять результаты нескольких последних запросов, что вполне приемлимо для большинства веб-приложений, учитывая, что обращение к Redis по скорости сравнимо с обращением к оперативной памяти. Тем не менее, потерь можно избежать через избыточность — Redis поддерживает неблокирующую master-slave репликацию.

Sharding


Redis, как и Memcached, может работать как распределённое хранилище на многих физических серверах. Такой функционал реализуется в клиентских библиотеках, и к сожалению, «из коробки» этот функционал реализован пока только в Ruby API, однако это не мешает вам хешировать ключ самостоятельно и получать ID сервера, к которому с этим ключом обращаться.

API


API доступно для следующих языков:
  • Ruby
  • Python
  • PHP
  • Erlang
  • Tcl
  • Perl
  • Lua
  • Java


API для PHP доступно как в виде модуля, написанного на C, так и в виде PHP5 класса, который общается с Redis-сервером через сокеты, таким образом не требуется устанавливать модуль.
Кроме того существует PHP5 класс от отечественного разрабочика (с именем, заслуживающим доверия. Я серьёзно.) — IMemcacheClient. (Спасибо DYPA за наводку)

Перспективы развития


Разработка ведётся очень активно, комиты происходят почти каждый день, сейчас доступна версия Redis 0.900 (1.0 release candidate 1), которая очень скоро станет версией 1.0
В ближайшем будущем авторы обещают внедрить разные интересные фичи, в том числе и сжатие данных.

Лицензия и поддерживаемые платформы


Redis — написан на ANSI C и работает на большинстве POSIX-систем (Linux, MacOS X). Это бесплатное открытое ПО под BSD лицензией =)

Up: Rediska — удобный PHP-клиент для key-value базы Redis. Оф.сайт.
Total votes 79: ↑75 and ↓4 +71
Views 100K
Comments 126

Memcached. Как найти ключи по паттерну?

Website development *
Доброе утро|день|вечер|ночь, %username%!

При использовании Memcached, иногда могут возникнуть вопросы: «А как посмотреть все ключи Memcached?» или «Как найти все ключи по маске „*“ или „sql_*“ ?»
Вот тогда открываются мануалы и начинается поиск такой функции, но, к сожалению, такой не оказывается :-(
Потом начинается Гугление… И там особо ничего нет :-(
А потом начинается поиск незадокументированных возможностей :-) и тут «Ура! Нашел!»

Читать дальше →
Total votes 61: ↑39 and ↓22 +17
Views 9K
Comments 44

История одного бага или почему следует знать не только РНР

PHP *
Все началось с того, что стал падать мемкеш, вернее мемкешДб. И падал он как-то хитро. Переустановка мемкеш+мемкешДб+BerkeleyDb ничего не дала. После некоторых эмперических вычислений стало понятно, что падает на методе MultiGet, при том очень интересен тот факт, что падение зависит от порядка задания ключей и кол-во ключей должно быть более 3х.
Читать дальше →
Total votes 14: ↑7 and ↓7 0
Views 2.2K
Comments 5

MemcacheDB против Kyoto Tycoon — экспресс тестирование

NoSQL *
Недавно, чисто случайно, попался на глаза продукт от FAL LabsKyoto Tycoon, легкий сервер данных. В основе данного продукта — QDBM (Quick Database Manager) — хранилище данных типа ключ-значение. Зацепило меня то, что с этим «Магнатом из Киото» можно общаться по memcached-like протоколу.
Поскольку уже некоторое время использую MemcacheDB, захотелось сравнить их характеристики (протокол общения один, и там и там NoSQL-хранилище ключ-значение). Недавно подвернулся удобный случай — экспортировал некоторый объем данных из одного самопального хранилища в MemcacheDB. Для тестирования осталось только развернуть на том-же сервере Kyoto Tycoon.
Вот что у меня получилось:
Читать дальше →
Total votes 35: ↑35 and ↓0 +35
Views 3.2K
Comments 24