Зачем мы используем реляционные СУБД, поддерживающие SQL синтаксис? Хранить данные, инкапсулировать работу с данными, делать хитромудрые выборки, сортировки и т.д. Насколько часто Вы (или Ваши разработчики) анализируете определенную задачу на предмет того, какую технологию хранения данных применять? Угадаю — почти никогда. Выбор обычно делается в начале проекта (MySQL, Postgres и т.д.), а потом этот выбор является условием «по умлочанию» для любого рода технических задач, требующих постоянное хранилище.

Если Вы когда-либо сталкивались с проблемами, связанными со скоростью работы СУБД, это не обязательно означает, что Вы пишете плохие SQL запросы. Может Вы пытаетесь решить задачу технологией, которая не особо хорошо подходит для ее решения?

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

Что же такое базы данных «ключ=значение». Это базы данных, которые позволяют хранить и читать значения по ключу… и все! Подробнее про них можно почитать в статье «Key=value (ключ=значение) базы данных». А мы остановимся на одном из ярких представителей подобных продуктов:

Redis — «ключ=значение» база данных. Помимо двух методов записи и чтения, она имеет ряд атомарных операций, например: инкремент/декремент, проверка на существование ключа, множественное получение значений и другие.

Одним важным преимуществом redis перед конкурентами является поддержка структурных данных и примитивов по управлению ими. Такими структурными данными являются наборы (индексированные элементы) и списки (стек элементов). Redis предоставляет возможность доставать эелементы, добавлять, удалять их и даже получать выборки с ограниченным смещеннием (это как LIMIT OFFSET в MySQL).

В чем же сила? В простоте и скорости! Redis использует алгоритм асинхронных комитов на диск, поэтому все операции синхронно выполняются только в памяти и клиенту отдается результат. Это позволяет добится огромного выигрыша в производительности. Учитывая то, что redis не имеет затратных слоев SQL движка, прослойки индексирования, прослойки метаданных, специфических типов данных (для redis'a все — это строка), дополнительных статистических и управляющих процессов, это делает его на порядок (или даже на несколько) быстрее обычных РСУБД.

К тому же, redis поддерживает репликацию. А если у Вас планы покрупнее на него, то организовать шардинг получается весьма просто, т.к. он легко реализуем на среднем уровне (middletier).

Если Вы в следующий раз столкнетесь с задачами, не трубующими сложных выборок, сортировок, агрегации данных и т.п., и если Ваша задача ложится в концепцию «хранить и отдавать значения по ключу», обдумайте свое решение хорошенько!

Обзорная информация про Redis

Метки: hi-liad, hi-performance, highscalability, Optimization, redis, масштабируемость, СУБД