Выполнение [домашнего задания](https://github.com/netology-code/virt-homeworks/blob/master/06-db-01-basics/README.md) 
по теме "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](https://habr.com/ru/post/278237/). Что это за система? Какие минусы выбора данной системы?

Система с реализацией механизма `Pub/Sub` - это система, которая поддерживает асинхронное взаимодействие между
несколькими сервисами. В данном случае некоторые сервисы выступают в роли `publisher`, то есть публикуют некое сообщение в определённый топик (тему),
а некоторые - в роли `subscriber`, то есть подписываются на определённые темы и читают сообщения.
Система `Pub/Sub` хранит сообщения и обрабатывает запросы сервисов-`publisher` и сервисов-`subscriber`.

В данном случае, если выбрать подобную систему, то это приведёт к усложнению логики сервиса-`subscriber`,
которому дополнительно придётся выступать в качестве сервиса-`publisher`. Это обусловлено тем,
что время жизни некоторых значений задаётся внутри публикуемого сообщения, и чтобы узнать время жизни, нужно вычитать сообщение.
И в случае, если TTL не истёк, то необходимо заново опубликовать это сообщение.

Некоторые системы нативно поддерживают задание значения времени жизни, 
но в этом случае нет возможности сделать реакцию на его истечение.