Электронные чеки в json виде
Я бы подумал над выбором между MongoDB и Elasticsearch. Обе базы данных ориентированы на json. Вероятно мой выбор бы остановился на MongoDB. Но, кстати, на конференци HiLoad-2021 разработчики из PostgresPro о поддержке данных json, т.ч. не всё однозначно. Но всё же я бы остановилася на MongoDB.
Склады и автомобильные дороги для логистической компании
Что-то из традиционных SQL - PostgreSQL, MySQL вплоть до Oracle и MS SQL, если заказчик уровня федеральной торговой сети. Вероятно мой выбор пал бы на PostgreSQL -с ним знаком лучше, чем с остальными СУБД. В свете последующих заданий, которыые я выполняю не по очереди, в связку с PostgreSQL можно добавить Elasticsearch для ускорения поиска по сложным запросам. Т.е. хранить в Elasticsearch контекстную информацию и ключи для выборки из таблиц реляционной СУБД.
Генеалогические деревья
Строятся на иерархических базах данных. В сети находится Raima Database Manager и IBM Information Management System. Я бы выбрал SQL базу, которая поддерживает следующую форму:
CREATE TABLE employees (
id INTEGER NOT NULL PRIMARY KEY,
managerId INTEGER REFERENCES employees(id),
name VARCHAR(30) NOT NULL
);
Вот этот пример это основа для оганизайии деревьев. Мой выбор падает снова на PostgreSQL
Кэш идентификаторов клиентов с ограниченным временем жизни для движка аутенфикации
В этом случае выбираю между Redis MQ и Rabbit MQ. Сложный выбор. C одной стороны Redis более на слуху, но я с ним не работал. С другой стороны - в нашей компании уже давно используется Rabbit MQ для кластерной инфраструктуры. Всё же я выбираю Rabbit MQ.
Отношения клиент-покупка для интернет-магазина
Скорее всего остановлюсь на MySQL. Разработка веб-приложения для интернет-магазина это довольно типичная задача и уже есть десятки готовых движков. Большинство из них исторически используют MySQL. Если кто-то будет администрировать этот интернет-магазин, то ему будет проще рабоать со знакомой СУБД.
Характеристика ситуаций по CAP и PACELC теоремам
Данные записываются на все узлы с задержкой до часа (асинхронная запись)
CAP: PA (partition tolerance + availability)
PACELC: PA/EL
При сетевых сбоях, система может разделиться на 2 раздельных кластера
Похоже речь идёт о MongoDB
CAP: PA (partition tolerance + availability)
PACELC: PA/EC
Система может не прислать корректный ответ или сбросить соединение
CAP: CP (consistency + partition tolerance).
PACELC: PC/EC
В большой системе могут сочетаться принципы BASE и ACID. Во всяком случае это могут быть комоненты какой-то большой инфраструктуры. Насколько я понял из материала, эти принципы взаимоисключающие, поэтому в пределах одного компонента такое сочетание невозможно.
https://habr.com/ru/company/gaz-is/blog/551986/
ACID не предоставляет гарантии атомарности.
ACID не предоставляет гарантии изоляции.
Что это за система?
Цитата из https://habr.com/ru/post/278237/
"Издатель-подписчик (англ. publisher-subscriber или англ. pub/sub) — поведенческий шаблон проектирования передачи сообщений, в котором отправители
сообщений, именуемые издателями (англ. publishers), напрямую не привязаны программным кодом отправки сообщений к подписчикам (англ. subscribers).
Вместо этого сообщения делятся на классы и не содержат сведений о своих подписчиках, если таковые есть.
Аналогичным образом подписчики имеют дело с одним или несколькими классами сообщений, абстрагируясь от конкретных издателей."
Примеры систем:
Microsoft Azure ServiceBus Topics
Microsoft Azure EventHub
Microsoft BizTalk Server
RabbitMQ
ZeroMQ
microServiceBus
Redis
Какие минусы выбора данной системы?
Нет гарантии доставки. При подходе Pub-Sub гарантию доставки обеспечивает протокол уровнем выше. Это главный минус таких систем.
В зависимости от реализации нет гарантии того, что сообщения могут быть обработаны в порядке поступления