README

Test example for use Redis on PHP to realise strong report as a WEB application.

Аннотация

Рассмотрена возможность использования Redis для промежуточного хранения данных при реализации отчетов, требующих обработки больших массивов информации, как WEB приложений на PHP. На тестовом примере рассматриваются различные способы загрузки и обработки данных. Дается сравнение с реализацией аналогичного тестового примера на Oracle.

Описание

Суть задачи

Redis позиционируется как не реляционная СУБД, хранящая данные в оперативной памяти. Её применение эффективно, когда важна скорость обработки, например, для обеспечения быстрого доступа к очень загруженным WEB ресурсам. Подобная проблема возникает также BI (Business Intelligence) инструментах, в задачах промежуточной обработки в ETL(Extract, Transform, Load) системах. Например, в QlikView обработка данных реализована тоже в оперативной памяти. В связи с этим представляется интересным посмотреть, насколько можно приспособить Redis к решению задач ETL и BI.

Описание тестового примера

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

Скрипт redisaggregate.sql реализует данную схему на Oracle. Тест строился по следующему алгоритму. На первом этапе производится программная генерация данных:

При заполнении справочников в примере было принято, что в продажах участвуют товары 5 поставщиков, каждый из которых предоставляет по 100 наименований изделий. Цена товара бралась как случайная величина в диапазоне от 10 до 1000.
При моделировании продаж предполагалось, что в каждый их 30 дней покупки фиксируются в 1000 чеках, в каждом по 10 товаров. Распределение товаров разных поставщиков по чекам - случайны. Таким образом, в таблице продаж формируется 300000 записей. Второй этап предполагал агрегирование продаж по по различным показателям (дата, поставщик, чек, товар) с возможностью комбинации показателей.

Методика тестирования и ее реализующая программа

Тестирование проводилось на компьютере с процессором 2.2ГГц, ОЗУ 4Гб, ОС Win7x64. XAMPP 7.0.9. Redis_version:3.2.100. Для тестирования на PHP была разработана программа программа по схеме MVC:

Класс контроллер - ControllerRedis.php.
Вся логика реализована в модели - ModelRedis.php.
Для отображения WEB страниц использована библиотека cform. Приложение имеет следующие пункты меню:
Генерировать данные.
Товары (просмотр таблицы goods).
Продажи (просмотр таблицы sales).
Агрегирование продаж. В этом режиме можно получить отчет по продажам агрегированный по показателям: дата, поставщик, чек, товар. Загрузка данных в таблицы Oracle производилось в соответствии с приведенной выше схемой процедурой createdata.sql. Получение агрегированных отчетов SQL запросами в программе Toad.

Как лучше и быстрее загружать данные в Redis?

Возможны различные варианты загрузки данных в ключи Redis. Первый вариант предусматривал хранение в одном Hash ключе одной строки каждой таблицы. Всего используется 311504 ключа. Во втором варианте каждая таблица хранилась в отдельном ключе в формате json. Всего используется 5 ключей. Ниже приведено время генерации данных в зависимости от способа хранения.

Процесс	Redis. Каждый ключ содержит 1 строку таблицы	Redis. Ключ содержит таблицу целиком	Oracle
Генерация данных. с	84.542	0.359	136
Очистка таблиц, с	0.311	0.003	75

Из таблицы видно, что если хранить данные в большом количестве ключей, запись происходят значительно медленнее. Посмотрим теперь на расход оперативной памяти в Redis (приведен суммарный расход на хранение данных и служебные нужды) и PHP при использовании первого и второго варианта.

Процесс	Redis/PHP. Каждый ключ содержит 1 строку таблицы	Redis/PHP. Ключ содержит таблицу целиком
Генерация данных. Мб	52.15/9.52	17.23/31.52
Очистка таблиц, Мб	0.66/1.53	0.66/1.52

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

Сравнение результатов

Рассмотрим результаты агрегации 300000 продаж. В таблицах ниже приведен пик расхода памяти PHP и время формирования отчета. В Oracle агрегирование проводилось SQL запросами с выражением group by.

Агрегация по параметрам	Redis. Каждый ключ содержит 1 строку таблицы	Redis. Ключ содержит таблицу целиком	Количество строк в результате
Поставщик, Мб	27.53	77.52	5
Дата, Мб	25.53	79.52	30
Дата и поставщик, Мб	25.53	71.52	150
Товар, Мб	23.53	75.52	500
Дата и Товар, Мб	19.53	77.52	15000

Агрегация по параметрам	Redis. Каждый ключ содержит 1 строку таблицы	Redis. Ключ содержит таблицу целиком	Oraclre
Поставщик, с	122.702	1.055	0.140
Дата, с	70.422	0.987	0.112
Дата и поставщик, с	99.697	1.301	0.336
Товар, с	70.374	1.039	0.483
Дата и товар, с	89.962	1.348	0.616

При расчете по первому варианту алгоритм предусматривал циклический перебор ключей (строк таблицы) с хранением накопленного результата также в ключах. Как видно из таблиц, этот вариант работает гораздо медленнее, но требует меньше памяти PHP. При расчете по второму варианту все агрегирование выполнялось в массивах PHP, что гораздо быстрее, причем, чем меньше данных в результате, чем быстрее расчет. Следует отметить, что запросы Oracle выполняются быстрее, но запись в таблицы осуществляется значительно медленнее.

Выводы

Redis демонстрирует вполне приемлемую скорость при загрузке данных при использовании небольшого количества ключей. При этом данные хранятся очень компактно. Поэтому эту БД можно использовать как буфер между ETL и BI системами. Агрегирование (формирование отчета) значительно быстрее при реализации алгоритма в массивах PHP. В целом, при достаточно довольно большом объеме данных подобный подход позволяет обеспечить приемлемую скорость формирования отчета (около 1 секунды).

Установка

composer create-project sergechurkin/redisaggregate redisaggregate "1.1.x-dev"

Параметры настройки и подключения к серверу Redis задаются в params.php. Приложение зарегистрировано на packagist.

sergechurkin / redisaggregate

Maintainers

Details