Перед выполнением задания вы можете ознакомиться с дополнительными материалами.
Архитектор ПО решил проконсультироваться у вас, какой тип БД лучше выбрать для хранения определенных данных.
Он вам предоставил следующие типы сущностей, которые нужно будет хранить в БД:
- Электронные чеки в json виде
- Склады и автомобильные дороги для логистической компании
- Генеалогические деревья
- Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутенфикации
- Отношения клиент-покупка для интернет-магазина
Выберите подходящие типы СУБД для каждой сущности и объясните свой выбор.
Ответ:
- Электронные чеки в json виде - Документоориентированная БД, например MongoDB ее формат хранения данных бинарный json, т.е. в данном случае не будет затрат времени и вычислительных ресурсов на "конвертирование" json в другой формат.
- Склады и автомобильные дороги для логистической компании - судя по лекции подходит графовая БД, эта БД создана для того, чтобы описывать разнообразные связи между объектами. Иногда подобные задачи реализуются с помощью реляционных БД, например PostgreSQL (OpenStreetMap). Хотя если разбираться дальше, Postgres не в чистом виде, а как AgensGraph или с расширениями, postgis и AGE, что приближает его к графовым БД.
- Генеалогические деревья - Сетевая БД - она имеет иерархическую структуру, но в отличие от иерархических баз данных, где у одного узла может быть только один родительский узел, сетевой узел может иметь отношения с несколькими объектами.
- Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутентификации - БД ключ-значение. Например Redis или Memcached такие БД созданы для работы в качестве кеша, т.к. обладают высоким быстродействием, за счет простой структуры данных.
- Отношения клиент-покупка для интернет-магазина - Просто клиент-покупка, подойдет даже иерархическая БД т.к. есть родитель - клиент и дети - разные товары в покупке, но если принять во внимание, что это интернет-магазин и у него есть другие сущности, то наиболее правильным будет использовать реляционную БД. Одни из самых распространенных вариантов в данной области - Mysql(MariaDB) и PostgreSQL они позволяют достаточно гибко настроить схему данных под бизнес-процесс при достаточном быстродействии.
Вы создали распределенное высоконагруженное приложение и хотите классифицировать его согласно CAP-теореме. Какой классификации по CAP-теореме соответствует ваша система, если (каждый пункт - это отдельная реализация вашей системы и для каждого пункта надо привести классификацию):
- Данные записываются на все узлы с задержкой до часа (асинхронная запись)
- При сетевых сбоях, система может разделиться на 2 раздельных кластера
- Система может не прислать корректный ответ или сбросить соединение
А согласно PACELC-теореме, как бы вы классифицировали данные реализации?
Ответ:
- Данные записываются на все узлы с задержкой до часа (асинхронная запись) - AP, EL-PC
- При сетевых сбоях, система может разделиться на 2 раздельных кластера - AP, PA-EL
- Система может не прислать корректный ответ или сбросить соединение - CP, PA-EC
Доработка:
- Данные записываются на все узлы с задержкой до часа (асинхронная запись) - CA, PA-EL
- При сетевых сбоях, система может разделиться на 2 раздельных кластера - AP, PA-EC
- Система может не прислать корректный ответ или сбросить соединение - CP, PC-EC
Могут ли в одной системе сочетаться принципы BASE и ACID? Почему?
Ответ: нет не могут, эти принципы преследуют противоположные цели. ACID - высокая надежность, пусть и за счет снижения скорости, BASE - высокая производительность, пусть и за счет снижения надежности.
Вам дали задачу написать системное решение, основой которого бы послужили:
- фиксация некоторых значений с временем жизни
- реакция на истечение таймаута
Вы слышали о key-value хранилище, которое имеет механизм Pub/Sub. Что это за система? Какие минусы выбора данной системы?
Ответ:
Эта система называется Redis.
Изначально Redis разработан, как key-value хранилище, может использоваться для кеширования, хранения сессий, синхронизации между сервисами (брокер сообщений), в нем можно задавать время жизни ключей.
Он поддерживает различные структуры данных, такие как строки, хэши, списки, наборы, отсортированные наборы с запросами диапазона, растровые изображения, гиперлоглоги, геопространственные индексы с запросами радиуса и потоки.
Он достаточно быстрый и легкий.
Судя по документации реакция на истечение таймаута должна быть обеспечена приложением-клиентом, т.к. Redis только удаляет ключи с закончившимся временем жизни (После установки некоторого таймаута на некий ключ Redis, значение времени действия для данного ключа будет сохраняться в виде некоторого абсолютного временного штампа UNIX. Таким образом, даже если Сервер Redis будет отключён какое- то время, данный временной штамп срока действия не будет утрачен и значение ключа всё равно прекратит своё действие после того как сервер вновь вернётся в рабочее состояние, а часы пройдут значение этого временного штампа UNIX. Когда срок действия некоторого ключа истечёт, а соотвтетствующий клиент попробует осуществить к нему доступ, Redis немедленно удалит этот ключ из памяти. Такой способ удаления Redis ключей называется пассивным истечением срока действия. Что если срок действия некоторого ключа истёк, но к нему больше никогда не осуществляется доступ? Redis также выполняет и активное удаление ключей с истекшим сроком действия периодически запуская некий вероятностный алгоритм. В частности, Redis случайным образом прихватывает 20 ключей, связанных с заданным таймаутом. Ключи с истекшим сроком действия будут немедленно удалены. Если среди выбранных ключей истёк срок действия более 25% ключей и они были удалены, Redis случайным образом вновь опять выхватывает 20 ключей и повторяет данный процесс. По умолчанию данный процесс выполняется 10 раз в секунду, однако это настраиваемый параметр со значением hz в имеющемся файле настроек.).
Минусы:
- Требуется определить что важнее, надежность хранения данных или производительность, во время условного отключения электричества данные с момента последней синхронизации с диском будут потеряны.
- Надо иметь достаточный объем оперативной памяти и следить за ее испльзованием, т.к. БД находится в ней.
- Redis не гарантирует доставку сообщений при использовании механизма pub/sub. Если подписчик не активен, он не будет получать сообщения, на которые он подписан
- Redis не поддерживает постоянные сообщения, поскольку это хранилище данных в памяти (в данной задаче не очень актуально).
Выполненное домашнее задание пришлите ссылкой на .md-файл в вашем репозитории.