🔤
Авто-масштабирующаяся БД - Реляции + ХХХ = Ляпота 🔤"Авто-масштабирующаяся БД" – автошар-дируемая база формата master-master (CockroachDB, YDB, ScyllaDB, Clickhouse, PlanetScale, etc.), что позволяет писать много данных быстро и с условно неограниченной параллельностью"- Реляции" потому что в 90% таких БД не будет CONSTAINT, благодаря которым БД при изменении / уничтожении данных чистить / менять связанные с ними данные. Чаще всего, поддержание реляций в распределенных базах - задача, за которую авторы БД не могут дать требуемых каждому отдельному проекту гарантий и времени исполнения.Думаю, большинство разрабов, годик другой поработавших с реляцими очень их любят, поэтому сложно отказаться от такой роскоши как: "если я удаляю User я хочу чтобы все связанные с ним данные тоже удалились и как мне это организовать, если нет реляций?"И для начала, ложка дегтя: я неоднократно слышал и только со временем поверил в то, что
реляции (особено CASCADE DELETE) – палка о двух концах. Это слабо контролируется, весь каскад тяжело увидеть в БД, некоторые случайные удаления могут вызвать необратимые последствия. Статейки
1, 2.Иногда лучше оставить данные на месте "до лучших времен", ведь часто при запросе пользователю или не увидит уже несвязанные с ними данные (из-за отсутствия реляции) или эти данные относятся к "фактам прошлого", которые вообще не стоит удалять.Ок, а если надо удалить, или убрать FORIEGN KEY, или проставить deletedAt?
. Простой вариант – крон, который чистит записи "сироты" (orphaned rows)
. Надежный, но кропотливый – ручками, в каждом отдельном месте понимать что и как нужно удалить / поменять (на сложных проектах иногда приходится к такому прибегать вместо реляций)
. Кривоватый, но рабочий вариант – ORM или свой плагин, который на уровне кода применяет каскадом действия при изменении / удалении сущности. Крайне опасная и часто малопредсказуемая история (хотя, я видел подобный успешный опыт)
. Более продвинуто – закидывать событие об удалении сущности в Queue, читать отдельным сервисов и принимать нужные решения. Придется иметь и настраивать MQ, а еще и не забывать писать все эти ивенты.
. А вот
самый заебись вариант это Change Data Capture (CDC) – механизм базы, который позволяет подписаться на события об изменении данных, которые она будет присылать вам на лету.И вот именно встроенный CDC является тем самым ингридиентом ХХХ, который добавляет этим базам удобства и надежности решения вопроса с реляциями.Поэтому, ищите новенькую топовую базу? Посмотрите чтобы у нее в комплекте шли или реляции, или CDC, а лучше и то и другоеМощной вам прокачки 😎P.S.Я затронул только удаление данных, да, еще существует проверка на существование в момент записи и подобного рода вещи, но это уже решается скорее архитектурой, а не CDC да и пост итак длинный, так что как-нибудь потом
#postgresql #db #highload #ydb