8.3 KiB
Выполнение домашнего задания по теме "6.1. Типы и структура СУБД".
Q/A
Задание 1
Архитектор ПО решил проконсультироваться у вас, какой тип БД лучше выбрать для хранения определенных данных.
Он вам предоставил следующие типы сущностей, которые нужно будет хранить в БД:
- Электронные чеки в json виде
- Склады и автомобильные дороги для логистической компании
- Генеалогические деревья
- Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутенфикации
- Отношения клиент-покупка для интернет-магазина
Выберите подходящие типы СУБД для каждой сущности и объясните свой выбор.
- Электронные чеки в json виде
В данном случае лучше всего использовать документо-ориентированную базу данных. Так как данные уже находятся в формате json, то и дополнительных манипуляций с данными не нужно производить, что упрощает поддержку системы.
- Склады и автомобильные дороги для логистической компании
Здесь необходимо более подробные бизнес-требования. В общем случае, лучше использовать традиционную реляционную БД, так как в ней можно хранить как связи между сущностями дорог и складов, так и хранить дополнительную информацию для гео-информационных систем для отображения, построения маршрутов и т.п. Но есть вероятность, что для данного примера более оптимальным решением может быть графовая БД, когда необходимы, например, только расчёты только построения кратчайшего пути.
- Генеалогические деревья
Идеально хранить данную информацию в графовой БД, так как данные представляют собой узлы и связи между ними.
- Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутенфикации
В данном случае лучшим решением будет использовать key-value хранилище, так как данные имеют время жизни и доступ к ним нужен только по уникальному идентификатору.
- Отношения клиент-покупка для интернет-магазина
Оптимально будет использовать реляционную БД, так как необходима поддержка транзакционности при работе с деньгами.
Задание 2
Вы создали распределенное высоконагруженное приложение и хотите классифицировать его согласно CAP-теореме. Какой классификации по CAP-теореме соответствует ваша система, если (каждый пункт - это отдельная реализация вашей системы и для каждого пункта надо привести классификацию):
- Данные записываются на все узлы с задержкой до часа (асинхронная запись)
- При сетевых сбоях, система может разделиться на 2 раздельных кластера
- Система может не прислать корректный ответ или сбросить соединение
А согласно PACELC-теореме, как бы вы классифицировали данные реализации?
- Данные записываются на все узлы с задержкой до часа (асинхронная запись)
PC - то есть Partition tolerance (несколько узлов) и Consistency (согласованность данных, хоть и с задержкой).
- При сетевых сбоях, система может разделиться на 2 раздельных кластера
PA - то есть Partition tolerance (может работать на нескольких узлах), и Availability (при сбоях упор делается на доступность).
- Система может не прислать корректный ответ или сбросить соединение
Не относится к какому-либо классу по теореме PACELC, так как не обеспечивает необходимые свойства.
Задание 3
Могут ли в одной системе сочетаться принципы BASE и ACID? Почему?
В реальной жизни, насколько я смог найти, систем, которые бы реализовывали все принципы BASE и ACID нет.
Но возможна такая реализация, которая будет основана на одном принципе, при этом частично реализуя другой принцип.
Задание 4
Вам дали задачу написать системное решение, основой которого бы послужили:
- фиксация некоторых значений с временем жизни
- реакция на истечение таймаута
Вы слышали о key-value хранилище, которое имеет механизм Pub/Sub. Что это за система? Какие минусы выбора данной системы?
Система с реализацией механизма Pub/Sub - это система, которая поддерживает асинхронное взаимодействие между
несколькими сервисами. В данном случае некоторые сервисы выступают в роли publisher, то есть публикуют некое сообщение в определённый топик (тему),
а некоторые - в роли subscriber, то есть подписываются на определённые темы и читают сообщения.
Система Pub/Sub хранит сообщения и обрабатывает запросы сервисов-publisher и сервисов-subscriber.
В данном случае, если выбрать подобную систему, то это приведёт к усложнению логики сервиса-subscriber,
которому дополнительно придётся выступать в качестве сервиса-publisher. Это обусловлено тем,
что время жизни некоторых значений задаётся внутри публикуемого сообщения, и чтобы узнать время жизни, нужно вычитать сообщение.
И в случае, если TTL не истёк, то необходимо заново опубликовать это сообщение.
Некоторые системы нативно поддерживают задание значения времени жизни, но в этом случае нет возможности сделать реакцию на его истечение.