Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

README.md

Домашнее задание к занятию "6.1. Типы и структура СУБД"

Перед выполнением задания вы можете ознакомиться с дополнительными материалами.

Задача 1

Архитектор ПО решил проконсультироваться у вас, какой тип БД лучше выбрать для хранения определенных данных.

Он вам предоставил следующие типы сущностей, которые нужно будет хранить в БД:

  • Электронные чеки в json виде
  • Склады и автомобильные дороги для логистической компании
  • Генеалогические деревья
  • Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутенфикации
  • Отношения клиент-покупка для интернет-магазина

Выберите подходящие типы СУБД для каждой сущности и объясните свой выбор.

Ответ:

  1. Электронные чеки в JSON виде технически удобнее хранить в NoSQL документоориентированном хранилище, например MongoDB или Documentdb(Amazon). В данных БД документ хрнаится в JSON формате.
  2. Склады и автомобильные дороги для логистической компании подойдет любая SQL БД, например MySQL, PostgreSQL. Хранение в отдельных таблицах складов, улиц/дорог будет вполне удобным.
  3. Генеалогические деревья удобнее будет хранить в графовой NoSQL БД, причем на самих ребрах будет удобно размещать степень родства (дочь, сын, отец, мать, сводный брат/сестра и т.д.). При этом также подойдет и сетевая NoSQL БД.
  4. Кеш идентификаторов клиентов с ограниченным временем жизни удобно хранить в NoSQL ключ-значение, т.е. Redis или Memcached бкдет оптимальным вариантом. Данные хранятся в памяти+ временное хранение данных.
  5. Отношения клиент-покупка для Интернет-магазина оптимально хранить в любой SQL БД, например MySQL, PostgreSQL.

Задача 2

Вы создали распределенное высоконагруженное приложение и хотите классифицировать его согласно CAP-теореме. Какой классификации по CAP-теореме соответствует ваша система, если (каждый пункт - это отдельная реализация вашей системы и для каждого пункта надо привести классификацию):

  • Данные записываются на все узлы с задержкой до часа (асинхронная запись)
  • При сетевых сбоях, система может разделиться на 2 раздельных кластера
  • Система может не прислать корректный ответ или сбросить соединение

А согласно PACELC-теореме, как бы вы классифицировали данные реализации?

Ответ:

Согласно CAP:

  1. AC, т.е. отсутсвует устойчивость к разделению, т.к. система обязана записать данные на все ноды для получения принципа согласованности и доступности.
  2. AP, т.е. отсутсвует согласованность в связи с возможным разделением систем на два независимых кластера.
  3. CP, т.е. отсутсвует доступность, т.к. сброс соединения допустим.

Согласно PACELC-теореме:

  1. PC/EC (MegaStore, VoltDB/H-Store)
  2. PA/EС или PA/EL в зависимости от требования к задержкам (MongoDB, Cassandra)
  3. PC/EC или PC/EL в зависимости от требования к задержкам (Couchbase, Megastore, VoltDB/H-Store)

Задача 3

Могут ли в одной системе сочетаться принципы BASE и ACID? Почему?

Ответ:

Если мы говорим о системе БД, то принципы взаимоисключающие. В свою очередь принцип ACID может частично достигаться уровнем приложения (напрмиер согласованность).

Задача 4

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

  • фиксация некоторых значений с временем жизни
  • реакция на истечение таймаута

Вы слышали о key-value хранилище, которое имеет механизм Pub/Sub. Что это за система? Какие минусы выбора данной системы?

Ответ:

Принцнип системы в котором отправители и получатели сообщений не привзяаны друг с другом кодом. В данном случае всплывает некая сущность посередине, называемая брокром сообщений (или шина событий). С учетом того, что требуется key-value хранилище с некоторым временем жизни записей, то подходит БД Redis с хранением записей в RAM. В Pub/Sub отправительно и получатель не привзан друг у другу кодом, в этом может закючаться минус в некоторых реалиациях. Например когда необходима моментальная реакция подписчика на Event издателеля.