Share This
Связаться со мной
Крути в низ
Categories
//📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

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

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

vybiraem hosting dlja mobilnogo prilozhenija chast vtoraja bazy dannyh i sistemy keshirovanija 1f32a1e - 📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

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

Этот цикл статей написан совместно с нашим партнером – компанией Selectel.

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

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

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

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

vybiraem hosting dlja mobilnogo prilozhenija chast vtoraja bazy dannyh i sistemy keshirovanija 18c631d - 📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

PostgreSQL

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

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

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

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

vybiraem hosting dlja mobilnogo prilozhenija chast vtoraja bazy dannyh i sistemy keshirovanija 30780f1 - 📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

MongoDB

MongoDB – это система управления базами данных, ориентированная на документы, и в настоящее время она является самым популярным на рынке решением NoSQL.

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

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

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

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

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

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

Index Clients TPS – Транзакций в секунду
Inclusive B-Tree 1 9387
Inclusive B-Tree 10 18761
RocksDB FDW 1 138350
RocksDB FDW 10 122369
RocksDB 1 166333
RocksDB 10 141482

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

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

Система управления базами данных Postgres в 4–15 раз быстрее MongoDB при тестировании производительности транзакций, проведенном OnGres – компанией, специализирующейся на предоставлении программного обеспечения и услуг для баз данных и спонсируемой EnterpriseDB. С одной стороны, Postgres умеет вставлять записи в таблицы без индексов практически с линейной скоростью записи на диск (сотни мегабайт в секунду). Однако если таблица содержит индексы, а вставленные ключи имеют случайные значения, тогда мы наблюдаем резкое снижение производительности.

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

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

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

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

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

vybiraem hosting dlja mobilnogo prilozhenija chast vtoraja bazy dannyh i sistemy keshirovanija 05ee9fe - 📱 Выбираем хостинг для мобильного приложения. Часть вторая: базы данных и системы кеширования

Redis

Redis позиционирует себя как система управления базами данных класса NoSQL, работающая с парами ключ-значение. К базовым характеристикам можно отнести то, что Redis хранит данные в оперативной памяти (In Memory), при этом обеспечивает постоянное хранение и на дисковых накопителях (персистентность). Одно из ключевых отличий Redis от других решений заключается в поддержке различных типов данных: строки, списки, множества, хеш-таблицы, упорядоченные множества. Еще одним важным отличием является реализация системы обмена сообщениями по модели «издатель-подписчик» (PubSub). C его помощью вы сможете создать шину данных приложения, открывать каналы, подписываться и публиковать сообщения.

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

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

Когда Redis используется в качестве кеша, ему можно дать указание автоматически удалять старые данные при добавлении новых. Это поведение известно сообществу разработчиков как алгоритм LRU, и применяется по умолчанию в популярной системе memcached. LRU – фактически только один из поддерживаемых алгоритмов освобождения данных.

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

Итог

Выбор базы данных для вашего приложения во многом зависит от специфики проекта и уровня ваших разработчиков. Если использование PostgreSQL можно считать начальным уровнем, то разработка на основе MongoDB уже требует знаний сравнимых с уровнем Intermediate.

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

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

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

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

*** Чтобы ускорить работу системы, выберите провайдера инфраструктуры, который наилучшим образом соответствует требованиям вашего ресурса: объем накопителя, процессор и количество ядер, объем оперативной памяти и ежемесячного трафика, наличие резервного копирования, быстрая техническая поддержка. Эта статья написана совместно с нашим партнером – компанией Selectel.

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

Интересно, посмотреть тарифы Selectel

  • 1 views
  • 0 Comment

Leave a Reply

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Связаться со мной
Close