Давайте попробуем в таком GUI редакторе открыть схему БД любой прикладной системы на базе платформы 1С:Предприятие. Там будет даже не десяток таблиц. Но что мы там увидим? А решения на базе 1С я бы просто так из рассмотрения не исключал. Это одна из лидирующих платформ на рынке.
Чем не устраивают решения класса Data Catalog? Та же OpenMetadata, например
Если не нужны внешние ключи, скорее всего не нужна реляционная СУБД. Есть же MongoDB, Cassandra и др. Они там нюансами отличаются, надо просто подобрать ту, которая лучше подойдёт под решение. Cassandra на вставку очень быстрая. Монга умеет какие-то джоины по минималкам. Но вы не любите внешние ключи поэтому вряд-ли Монга...
Возможно проблема не в СУБД. У вас есть ORM слой в прикладухе? Hibernate? SQLAlchemy? Если есть - очень сочувствую. Любой ORM превращает православный SQL в ООП месиво, которым невозможно управлять. Взять, и поверх очень красивого, одного из самых лучших декларативных языков программирования на планете, поставить ООП фасад...
Могли бы в явной форме подождать завершения этой конкретной, заведомо известной и идентифицированной, влияющей транзакции. Но вы как-то игнорируете возможность и необходимость попадания в требуемую точку актуальности. Ну и кто виноват?
Дак вот же! Вы говорите про Event Sourcing! Про те самые неизменяемые данные! Я могу попасть в любую точку реальности. Даже в точку "параллельной" реальности. Которая возникла, но по каким то причинам откатилась. Это как в Git. Гуляй себе по веткам репозиторя. Но только РСУБД для этого не предназначены.
Хочу вбить гвоздь в крышку всех уверовшавших в РСУБД. )
Какой уровень изолированности транзакций используется в прикладных решениях,, работающих с РСУБД, с которыми вам приходилось сталкиваться (я сейчас обращаюсь к гипотетическому оппоненту, никаких переходов на личности)? Тот уровень, который установлен по умолчанию в конкретной РСУБД? Не рассказывайте, пожалуйста, что при уровне Serializable ваше прикладное решение хоть как то ворочается в плане производительности и не встаёт колом. И зачем после этого рассказывать про консистентность и необходимость внешних ключей?
Далее... Какой RPO/RTO заложен в систему? Вы правда используете синхронную репликацию и тем самым гасите производительность и доступность системы в два раза? В любом другом случае у вас данные могут просто пропасть.
РСУБД очень плохо масштабируются горизонтально. Вообще никак. Это при том, что сами РСУБД никаких 100% ACID вам и не гарантируют: данные могут быть протухшими и даже неконсистентными.
Вот я пытаюсь сделать выборку, когда кто-то другой совершает транзакцию с данными, которые в мою выборку, логически, должны попасть. Но его транзакция завершается чуть позже моей. Я в этом случае получу неактуальные, но консистентные (возможно) данные. Никто Read uncommitted не выставляет как правило. Вопрос, возможно, каких-то миллисекунд. А кто выставил этот интервал в миллисекунды? Он актуален для бизнеса? Может если это будут секунды - это тоже всех устроит? Может мне надо изменения класть в высокопроизводительный брокер сообщений, а не в РСУБД, а там уже разберут кому куда надо. В конце концов по очередям брокера тоже можно запросы шарашить. Eventual Consistency. А чем она от не Eventual отличается? Да ничем. Временным интервалом.
Коллеги! Тема спорная, чисто для обсуждения. Как и сама статья выше. Буду благодарен за обратку )
Тут возникло недопонимание. Ошибки, конечно, никто не отменял. Ошибки можно и в РСУБД наколбсить, даже с использованием внешних ключей.
Тут вопрос о том, какой инструмент из портфолио архитектора необходимо достать, чтобы решить ту или иную задачу. Если отталкиваться от видов данных, которые существуют в любой организации, а их выделяют пять:
Метаданные.
Мастерданные.
Операционно-учётные данные
Аналитические данные.
Слабоструктурированные или неструктурированные данные или контент.
то очевидно, что для управления каждым видом используется свой инструмент. РСУБД, в то время как они в первую очередь предназначены для управления операционно-учётными данными где катастрофически важен ACID, очень часто пытаются натянуть на работу с аналитическими данными. При небольших объёмах данных и необходимости построения real-time отчётности, это допускается. Т.н. ROLAP. И допускаются техники денормализации для повышения производительности.
Но современные реалии диктуют другие подходы: Data Lakehouse, Data Mesh и прочее. Я бы оставил внешние ключи в РСУБД. А для отчётов, которые требуют производительности, использовал специализированные решения. В конце концов CQRS никто не отменял )
Давайте попробуем в таком GUI редакторе открыть схему БД любой прикладной системы на базе платформы 1С:Предприятие. Там будет даже не десяток таблиц. Но что мы там увидим? А решения на базе 1С я бы просто так из рассмотрения не исключал. Это одна из лидирующих платформ на рынке.
Чем не устраивают решения класса Data Catalog? Та же OpenMetadata, например
Да. Автору спасибо )
Если не нужны внешние ключи, скорее всего не нужна реляционная СУБД. Есть же MongoDB, Cassandra и др. Они там нюансами отличаются, надо просто подобрать ту, которая лучше подойдёт под решение. Cassandra на вставку очень быстрая. Монга умеет какие-то джоины по минималкам. Но вы не любите внешние ключи поэтому вряд-ли Монга...
Возможно проблема не в СУБД. У вас есть ORM слой в прикладухе? Hibernate? SQLAlchemy? Если есть - очень сочувствую. Любой ORM превращает православный SQL в ООП месиво, которым невозможно управлять. Взять, и поверх очень красивого, одного из самых лучших декларативных языков программирования на планете, поставить ООП фасад...
Дак вот же! Вы говорите про Event Sourcing! Про те самые неизменяемые данные! Я могу попасть в любую точку реальности. Даже в точку "параллельной" реальности. Которая возникла, но по каким то причинам откатилась. Это как в Git. Гуляй себе по веткам репозиторя. Но только РСУБД для этого не предназначены.
В этом мире нет внешних ключей
Хочу вбить гвоздь в крышку всех уверовшавших в РСУБД. )
Какой уровень изолированности транзакций используется в прикладных решениях,, работающих с РСУБД, с которыми вам приходилось сталкиваться (я сейчас обращаюсь к гипотетическому оппоненту, никаких переходов на личности)? Тот уровень, который установлен по умолчанию в конкретной РСУБД? Не рассказывайте, пожалуйста, что при уровне Serializable ваше прикладное решение хоть как то ворочается в плане производительности и не встаёт колом. И зачем после этого рассказывать про консистентность и необходимость внешних ключей?
Далее... Какой RPO/RTO заложен в систему? Вы правда используете синхронную репликацию и тем самым гасите производительность и доступность системы в два раза? В любом другом случае у вас данные могут просто пропасть.
РСУБД очень плохо масштабируются горизонтально. Вообще никак. Это при том, что сами РСУБД никаких 100% ACID вам и не гарантируют: данные могут быть протухшими и даже неконсистентными.
Вот я пытаюсь сделать выборку, когда кто-то другой совершает транзакцию с данными, которые в мою выборку, логически, должны попасть. Но его транзакция завершается чуть позже моей. Я в этом случае получу неактуальные, но консистентные (возможно) данные. Никто Read uncommitted не выставляет как правило. Вопрос, возможно, каких-то миллисекунд. А кто выставил этот интервал в миллисекунды? Он актуален для бизнеса? Может если это будут секунды - это тоже всех устроит? Может мне надо изменения класть в высокопроизводительный брокер сообщений, а не в РСУБД, а там уже разберут кому куда надо. В конце концов по очередям брокера тоже можно запросы шарашить. Eventual Consistency. А чем она от не Eventual отличается? Да ничем. Временным интервалом.
Коллеги! Тема спорная, чисто для обсуждения. Как и сама статья выше. Буду благодарен за обратку )
Тут возникло недопонимание. Ошибки, конечно, никто не отменял. Ошибки можно и в РСУБД наколбсить, даже с использованием внешних ключей.
Тут вопрос о том, какой инструмент из портфолио архитектора необходимо достать, чтобы решить ту или иную задачу. Если отталкиваться от видов данных, которые существуют в любой организации, а их выделяют пять:
Метаданные.
Мастерданные.
Операционно-учётные данные
Аналитические данные.
Слабоструктурированные или неструктурированные данные или контент.
то очевидно, что для управления каждым видом используется свой инструмент. РСУБД, в то время как они в первую очередь предназначены для управления операционно-учётными данными где катастрофически важен ACID, очень часто пытаются натянуть на работу с аналитическими данными. При небольших объёмах данных и необходимости построения real-time отчётности, это допускается. Т.н. ROLAP. И допускаются техники денормализации для повышения производительности.
Но современные реалии диктуют другие подходы: Data Lakehouse, Data Mesh и прочее. Я бы оставил внешние ключи в РСУБД. А для отчётов, которые требуют производительности, использовал специализированные решения. В конце концов CQRS никто не отменял )
Автор отчасти прав. Никаких изменений, нарушающих целостность, быть не должно. Вот в этих книгах изложено подробнее:
Искусство неизменяемой архитектуры.
Чисто функциональные структуры данных.
Дата-ориентированное программирование.
и др.
Хотя среднестатистического программиста вряд ли кто-то сможет выгнать из реляционного рая.