Давайте чуть подробнее про DGrid.
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis
Мы привыкли, что СУБД работает с таблицами: строки, столбцы, индексы, SQL-запросы.
Но далеко не для всех задач нужна полноценная реляционная модель.
Иногда нужно просто очень быстро сохранить значение по ключу и так же быстро его получить.
Например, состояние пользовательской сессии, параметр приложения, промежуточный результат расчёта или часто используемое значение.
Для таких задач используется модель key-value, «ключ - значение».
Знаем ключ, сразу получаем связанное с ним значение.
В Digital Q.DataBase эту задачу решает DGrid.
Использовать его можно в двух вариантах.
► Первый - внутреннее KV-хранилище Digital Q.DataBase.
Оно работает отдельным процессом под контролем СУБД, и обращаться к нему можно непосредственно из SQL.
► Второй - DGrid как самостоятельный сервис.
Его можно вынести за пределы конкретного экземпляра СУБД и использовать в распределённой конфигурации с автоматическим перераспределением данных между нодами.
При этом DGrid не ограничивается простым key-value.
Он поддерживает и табличные структуры, а работать с данными можно через SQL-функции, собственный API, а также Redis- и Memcached-совместимые протоколы.
Данные могут храниться на уровне сеанса, пользователя или глобально.
Практические сценарии - хранение Web-сессий, кэширование результатов тяжёлых расчётов и промежуточный кэш между компонентами приложения.
► В составе Digital Q.DataBase DGrid также заменил ранее использовавшийся Tarantool DB.
То есть DGrid не заменяет обычное реляционное хранилище, а дополняет его там, где нужен быстрый доступ к данным и другой способ их хранения.
#СУБД #DGrid #KeyValue #Redis