SQL vs NoSQL 🥺

Частый вопрос на собеседованиях - когда выбрать SQL хранилище а когда NoSQL.
Сейчас мы рассмотрим два самых популярных представителя этих двух фракций - Postgres и Mongo.

Главным плюсом NoSQL хранилищ, а в частности Монги всегда была масштабируемость. Монга позволяет из под коробки развернуть кластер, также механизмы репликации и шардирования есть из под коробки

Постгря же таких плюсов не имеет, и горизонтальное масштабирование является серъезной задачей(хоть механизм WAL репликаций все таки имеется)

Но также издавна постгрес и другие реалиацонные базы данных брали двумя вещами - транзакции и индексы. Но уже давно в монге появились и транзакции и индексы, хоть и транзакции довольно кастрированные - ведь могут гарантировать атомарность на уровне одного документа(есть и на уровне коллекции но там также есть нюансы). Короче считать денюжки , например, через монгу не стоит(хотя врятли кому то хотелось :)

Также монга позволяет не иметь четких схем, что позволяет нам быстро вносить изменения при смене бизнесовых требований(НО также мы можем получить от этого много головной боли, и бекенд должен учитывать возможную ситуацию когда у одних сущностей разные поля)

Про производительность. Монга быстрее на простых запросах, так как все документы денормализованы, но если нам нужна сложная выборка то SQL like базы будут быстрей - так как SQL умный а еще планировщик запросов

Но также не стоит забывать что JSONB не так плох, с ним есть много операций, и даже есть индексы на поля, и иногда им не грех воспользоваться, хоть и большие документы в нем хранить не рекомендуется

#интересное

Что такое foo, bar, spam and eggs и так далее 🥚

Частенько в чужом коде, особенно в учебных видосах вы могли видеть переменные или функции с названиями foo, bar и тому подобное. Так оказывается у этого даже есть название - метапеременная. Это названия переменных заменителей, вместо которых может стоять что угодно.

А spam and eggs это локальная шуточка в питон комьюнити, отсылается к любимому шоу Гвидо - Монти Пайтон

#интересное

Про UUID🤷‍♂️

Юиды это универсально(не универсальный) уникальный айди, вроде понятно да? То есть это способ генерации айдишника, который гарантирует нам уникальность.

Что нам это дает?

Самый главный и жирный плюс - это распределенные системы. У нас например есть 3 микросервиса, и наша сущность композиционно разбита на эти 3 микросервиса(например заказ в интернет магазине)

И мы можем каждой из композиционной сущности дать один и тот же айди, автоинкримент же нам такого не дает, так как имеет стейт(sequence чаще всего, привет пайтон ментор я там опять обосрался знаю)

Также огромным плюсом есть то, что мы можем сгенерировать UUID на клиенте, даже временно не имея доступ к серверу - полезно в кассах, а также для дурабилити в любой клиент-сервер системе.

Также плюсом можно выделить что UUID ничего не дает нам о себе понять при первом прочтении, перебирать айдишники не получится да хацкеры

НУ И ПОСЛЕДНЕЕ, про скорость. У нас на одном проекте после видоса Миши Ларченко(мы как раз тогда чета архитектили) про юиды и их маленькую скорость - мы решили отказаться от юидов в каком то месте системы. Но ему там даже в комментах накидали про uuid v8 и все такое. Мораль - проверяйте инфу

#интересное

Dependency Inversion и Dependency Injection(чутка по базе) 🦔

Вообще одни из самых важных принципов SOLID и чистого кода, так как борьба со связностью или ж коуплингом это вообще основа.
Все эти DDD, Чистые / Луковичные / Гексагональные архитектуры, все это в том числе для того чтоб понизить связность, зацепления, чтоб все наши сущности были легкозаменяемые и одно изменения не провоцировало изменения во всей системе(это применимо и к микросервисам и вообще по жизне)

Так вот, инверсия зависимости как раз про это, сущности не должны зависеть от нижестоящих сущностей, все должно зависеть от интерфейсов и абстракций.
А инъекция зависимости это способ достижения этого, когда мы не храним хард код ссылки на зависимости, а передаем их извне.
То есть одно без другого невозможно, как то так

Ну и резюмируя, что нам это все дает:
- низкая связность, в итоге система более гибкая к изменениям
- возможность мокать все что угодно, без этого юнит тесты впринципе будут полумерой
- можно избавиться от глобальных зависимостей, в следствии избавиться от проблемы доступа к шаред ресурсам и уродства глобальных переменных
- и так далее и тому подобное;

Если хотите больше про чистую архитектуру, накидайте лайков, напишу еще постик

#интересное