📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

Мы рассмотрели возможные варианты мобильных приложений и протоколы сетевого взаимодействия с серверной стороной проекта. Это позволило получить базовое представление о требованиях к пропускной способности каналов связи и оперативной памяти сервера на основе потребностей приложения и возможностей программистов.

Другие статьи цикла:

• Часть первая: технологический стек

Базы данных для мобильных приложений

Начнем обзор с классических реляционных СУБД, плавно перейдем к NoSQL и завершим обзор решениями для кэширования. Я не поклонник MySQL и ничего хорошего или плохого я об этой базе данных не скажу. Есть причины по которым предпочитаю ей не пользоваться. Поэтому сразу перейдем к PostgreSQL.

PostgreSQL

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

PostgreSQL поддерживает расширяемость множеством способов, такие как хранимые функции и процедуры, использование процедурных языков PL/PGSQL, Perl, Python и др.. Многие расширения предоставляют дополнительные функции, включая PostGIS – модуль для геопространственного анализа.

Если у вас уже есть модель структурированных данных, то PostgreSQL будет лучшим вариантом.

MongoDB

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

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

PostgreSQL vs MongoDB по-честному

Можно посмотреть различные бенчмарки сравнивающие эти две базы данных, и каждый хвалит свое решение. Если же подойти в вопросу с технической стороны, то PostgreSQL использует бинарные деревья для индексирования, которые отлично работают на HDD. В тоже время большинство современных баз данных (RocksDB, MongoDB, Tarantool и т.д.) используют LSM-дерево (Log-structured merge-tree – журнально структурированное дерево со слиянием) вместо классического B-Tree.

Бинарное дерево ориентировано на операции чтения и поиск, дерево LSM ориентировано на доступ к часто изменяемым данным и работу с SDD.

[https://postgrespro.ru/list/thread-id/2503727] пруф от независимого разработчика, поэтому этот источник, вызывает больше доверия, чем рекламные материалы проектов.

Как видите, разница примерно в 10 раз.

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

PostgreSQL представляет классический подход к хранению структурированных, данных в виде таблиц. С другой стороны, MongoDB требует от разработчика переосмысления подхода к хранению данных. Конечно, эта СУБД не дает полной свободы действий, но предоставляет дополнительный инструмент, повышающий производительность базы данных – коллекции.

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

Инструменты кэширования для мобильных приложений

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

Redis

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

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

Начиная с Redis 4.0 доступен новый режим освобождения наименее часто используемых данных – LFU. Этот режим может обеспечивать лучшую эффективность в определенных ситуациях, поскольку в этом случае Redis отслеживает частоту доступа. Данные, которые используются редко, удаляются, в то время как наиболее используемые имеют более высокий шанс остаться в памяти.

Итог

Дальнейшее увеличение производительности базы данных возможно при использовании движков хранилищ данных (встраиваемых key-value хранилищ). Здесь стоит обратить внимание на такие решения, как RocksDB и BadgerDB. Однако они требуют от разработчика еще более серьезных познаний в системах управления базами данных, сопоставимых с уровнем Senior.

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

Естественно, Redis не является единственным решением. Для осознания потребности в реализации собственной системы кэширования, нужно понимать процесс сериализации и десериализации происходящий при каждом запросе к данным, отправке сообщения по шине данных или взаимодействии с Rest API.

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

Selectel предлагает серверы, оснащенные 4-768 ГБ ОЗУ, 2-72 ядрами ЦП, а также с возможностью подключить графический ускоритель и выбрать в качестве сервера даже Raspberry Pi 4 (4/64 ГБ) и Mac mini для iOS-разработчиков.