2023-09-07 16:58
Оригинал
🔤 Авто-масштабирующаяся БД - Реляции + ХХХ = Ляпота 🔤
"Авто-масштабирующаяся БД" – автошар-дируемая база формата 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
"Авто-масштабирующаяся БД" – автошар-дируемая база формата 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
Комментарии: 2
I
За все не буду писать, например, за CockroachDB напишу, это не совсем верное утверждение, что зависимости тяжело удалить.
Под капотом раньше был rocksdb, который оптимизирован на скорость записи и чтения через многоуровневый кэш, включая аппаратные возможности SSD. Но удаление данных архитектура не позволяет сделать быстрым из-за необходимости проставлять флаг на удаления, а потом проходить итерацией, как gc. В итоге, это фоновая тяжёлая операция постоянной очистки при удалении больших данных под нагрузкой записи, да, там ещё acid надо поддерживать, а ещё конкурентный доступ к данным (MVCC), и всё это становится узким горлышком, потому что чтение и запись в приоритете. Команда долгое время контрибьютила оптимизации в rocksdb, пока не решили сделать полностью свою реализацию.
Так образом появилась Pebble, в которой взяли концепцию rocksdb, но изменили гарантии, которые обеспечивает слой выше в CockroachDB в пользу оптимизации удаление данных и ещё некоторых особенностей.
Сейчас удаление данных в CockroachDB работает фоновыми задачами с учётом планировщика запросов, равномерно распределяя нагрузку по кластеру, и на основе этого алгоритма появились TTL опции на таблицу.
Под капотом раньше был rocksdb, который оптимизирован на скорость записи и чтения через многоуровневый кэш, включая аппаратные возможности SSD. Но удаление данных архитектура не позволяет сделать быстрым из-за необходимости проставлять флаг на удаления, а потом проходить итерацией, как gc. В итоге, это фоновая тяжёлая операция постоянной очистки при удалении больших данных под нагрузкой записи, да, там ещё acid надо поддерживать, а ещё конкурентный доступ к данным (MVCC), и всё это становится узким горлышком, потому что чтение и запись в приоритете. Команда долгое время контрибьютила оптимизации в rocksdb, пока не решили сделать полностью свою реализацию.
Так образом появилась Pebble, в которой взяли концепцию rocksdb, но изменили гарантии, которые обеспечивает слой выше в CockroachDB в пользу оптимизации удаление данных и ещё некоторых особенностей.
Сейчас удаление данных в CockroachDB работает фоновыми задачами с учётом планировщика запросов, равномерно распределяя нагрузку по кластеру, и на основе этого алгоритма появились TTL опции на таблицу.
🦾
Ivan Zhuravlev
За все не буду писать, например, за CockroachDB напишу, это не совсем верное утверждение, что зависимости тяжело удалить.
Под капотом раньше был rocksdb, который оптимизирован на скорость записи и чтения через многоуровневый кэш, включая аппаратные возможности SSD. Но удаление данных архитектура не позволяет сделать быстрым из-за необходимости проставлять флаг на удаления, а потом проходить итерацией, как gc. В итоге, это фоновая тяжёлая операция постоянной очистки при удалении больших данных под нагрузкой записи, да, там ещё acid надо поддерживать, а ещё конкурентный доступ к данным (MVCC), и всё это становится узким горлышком, потому что чтение и запись в приоритете. Команда долгое время контрибьютила оптимизации в rocksdb, пока не решили сделать полностью свою реализацию.
Так образом появилась Pebble, в которой взяли концепцию rocksdb, но изменили гарантии, которые обеспечивает слой выше в CockroachDB в пользу оптимизации удаление данных и ещё некоторых особенностей.
Сейчас удаление данных в CockroachDB работает фоновыми задачами с учётом планировщика запросов, равномерно распределяя нагрузку по кластеру, и на основе этого алгоритма появились TTL опции на таблицу.
Под капотом раньше был rocksdb, который оптимизирован на скорость записи и чтения через многоуровневый кэш, включая аппаратные возможности SSD. Но удаление данных архитектура не позволяет сделать быстрым из-за необходимости проставлять флаг на удаления, а потом проходить итерацией, как gc. В итоге, это фоновая тяжёлая операция постоянной очистки при удалении больших данных под нагрузкой записи, да, там ещё acid надо поддерживать, а ещё конкурентный доступ к данным (MVCC), и всё это становится узким горлышком, потому что чтение и запись в приоритете. Команда долгое время контрибьютила оптимизации в rocksdb, пока не решили сделать полностью свою реализацию.
Так образом появилась Pebble, в которой взяли концепцию rocksdb, но изменили гарантии, которые обеспечивает слой выше в CockroachDB в пользу оптимизации удаление данных и ещё некоторых особенностей.
Сейчас удаление данных в CockroachDB работает фоновыми задачами с учётом планировщика запросов, равномерно распределяя нагрузку по кластеру, и на основе этого алгоритма появились TTL опции на таблицу.
Ого, круто, не знал про Pebble
Под "тяжело" я подразумевал скорее то, что большинство подобных баз, которые я видел, не добавляли реляций и причин этого не делать на мой взгляд может быть 2 – (1) сложность реализации или (2) очень осознанный выбор отказаться от реляций.
Вторая меня смущает тем, что "логически" и исторически люди привыкли к реляциям, поэтому отказ от них – это свдиг парадигмы.
С другой стороны, это не БД для обывателей (может, только PlanetScale, каким-то образом смогла ворваться в ряды стартапер и инди кодеров, став более продвинутой альтернативой Firebase), поэтому и объяснять отказ от реляций особо не нужно.
Ну а с третьей стороны, среди нубов крайне распространены документарные базы, которые реляций и не имели, поэтому и объяснять почему их нет в этих БД не нужно.
Поэтому суммируя: "если БД имеет реляции – заебись, но будьте крайне аккуратными, если не имеет – абсолютно ничего страшного, но посмотрите есть ли CDC чтобы облегчить вам жизнь"
Под "тяжело" я подразумевал скорее то, что большинство подобных баз, которые я видел, не добавляли реляций и причин этого не делать на мой взгляд может быть 2 – (1) сложность реализации или (2) очень осознанный выбор отказаться от реляций.
Вторая меня смущает тем, что "логически" и исторически люди привыкли к реляциям, поэтому отказ от них – это свдиг парадигмы.
С другой стороны, это не БД для обывателей (может, только PlanetScale, каким-то образом смогла ворваться в ряды стартапер и инди кодеров, став более продвинутой альтернативой Firebase), поэтому и объяснять отказ от реляций особо не нужно.
Ну а с третьей стороны, среди нубов крайне распространены документарные базы, которые реляций и не имели, поэтому и объяснять почему их нет в этих БД не нужно.
Поэтому суммируя: "если БД имеет реляции – заебись, но будьте крайне аккуратными, если не имеет – абсолютно ничего страшного, но посмотрите есть ли CDC чтобы облегчить вам жизнь"