Архитекторы переосмысливают «процесс хранения»

Архитекторы баз данных Ping Kai отмечают, что процессы хранения в корпоративных системах были популярны в прошлом из-за требований к производительности, но с появлением облачных и распределенных эпох возможности эволюции системы важнее производительности. Хотя хранимая процедура несет основную бизнес-логику, ее проблемы с конкуренцией ресурсов, трудности с обслуживанием и технической связь ограничивают развитие системы. AICoding еще больше усиливает эти проблемы из-за отсутствия стандартизированной инженерной семантики для хранимых процедур. В результате архитекторы продвигают логику на уровень приложений, чтобы включить наслоение баз данных и приложений, сокращение муфты и повышение способности к миграции. Когда уровень приложений отвечает за бизнес-логику, а уровень базы данных фокусируется на управлении данными, система может продолжать развиваться в области ИИ и будущих технологий. Эта корректировка расчищает путь для будущего развития системы, стремясь сделать базу данных надежной базой и приложением стать гибким бизнес-слоем.

Если взять на себя корпоративную систему, которая работает уже более 10 лет, велика вероятность, что в базе данных много хранимых процедур. В некоторых проектах обновления системной архитектуры, участвующих в базе данных Pingkai, эта ситуация на самом деле не является редкостью. Несколько десятков линий, несколько сотен или даже тысяч линий. Документы являются неполными и сложными отношениями вызовов, но они несут основную бизнес-логику системы.

Многие команды трепетно относятся коду: двигаться, насколько это возможно.

Но в последние годы заметные изменения начали происходить во все большем количестве проектов рефакторинга систем: архитекторы начали активно сокращать процедуры хранения.

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

В эпоху дорогих серверов и ограниченной пропускной способности сети сделать бизнес-логику максимально приближенной к исполнению данных может значительно снизить сетевую поездку в оба конца и повысить эффективность системы. Поэтому база данных отвечает не только за хранение данных, но и несет много вычислительной и контрольной логики. Многие бизнес-системы выросли в этом контексте.

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

Фокус системной архитектуры также медленно смещается. Проблема уже не только в производительности. Вопрос в том, может ли система продолжать развиваться.

Проблема не в производительности, а в эволюции.

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

Но в реальной системе предприятия проблема производительности сама по себе может стать новым бременем.

Когда в процессе хранения базы данных сосредоточено большое количество сложной логики, эти задачи часто занимают множество вычислительных ресурсов базы данных. Как только ресурсы базы данных будут заняты в течение длительного времени, могут появиться другие обычные запросы SQL и отставание; и отставание в запросе еще больше повлияет на эффективность выполнения хранимой процедуры, общая пропускная способность системы будет снижаться и даже формировать порочный круг взаимного усиления.

Поэтому в некоторых системах хранимая процедура не только не становится средством оптимизации производительности, но и может превратиться в централизованную точку конкуренции за ресурсы базы данных.

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

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

По мере расширения масштабов бизнеса сложность системы продолжает увеличиваться. Зрелая корпоративная система часто требует непрерывной итерации в течение более десяти лет, в течение которых она будет подвергаться многочисленным корректировкам бизнеса, архитектурным обновлениям и замене технологий. В таких долгосрочных циклах часто более важно, чтобы систему была легкой в обслуживании и проверке масштабов воздействия модификации, чем эффективность одного исполнения.

Эта способность развиваться, как правило, ограничена, когда в процессе хранения базы данных ускоряется большое количество бизнес-логики. Процессы хранения часто трудно включить в полную систему разработки программного обеспечения по сравнению с кодом приложения. Например, код прикладного уровня может быть выполнен в версии с Git, командной совместной работы с помощью Code Review или автоматизированного тестирования и непрерывного развертывания на конвейере CI/CD. Процесс хранения часто зависит от ручного развертывания скриптов, отслеживание версий является неполным, а автоматизированную тестовую систему трудно установить.

В сложных системах, казалось бы, простая хранимая процедура может быть неоднократно вызвана несколькими модулями. Когда его необходимо изменить, команде разработчиков часто трудно быстро судить о его сфере влияния. Из-за отсутствия систематического механизма тестирования любые изменения могут представлять потенциальные риски, поэтому многие команды становятся более осторожными перед лицом этих логик и даже формируют ситуацию «не может двигаться».

С инженерной точки зрения такое положение дел означает, что система постепенно теряет свою эволюционную эластичность. Производительность может быть все еще стабильной, но архитектуру стало трудно приспособить.

Во-вторых, логика.

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

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

Во многих проектах по миграции в базы данных технические группы часто обнаруживают, что миграция структуры таблиц не является самой сложной частью. Действительно сложными являются те вложенные звонки, комплекс логических ветвей и отсутствие документации хранимых процедур. Поскольку эти коды часто полагаются на конкретные механизмы синтаксиса и выполнения баз данных, даже если синтаксис совместим, их эксплуатационное поведение может быть не полностью последовательным.

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

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

В-третьих, возвращение структуры: наслоение и разъединение

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

В этой архитектурной идее основная задача базы данных заключается в обеспечении стабильных и эффективных возможностей управления данными, в то время как сложная бизнес-логика постепенно переносится на уровень приложения или сервиса. В некотором дизайне архитектуры базы данных нового поколения эта «база данных, ответственная за данные, ответственную логику приложений» также становится все более распространенной практикой, что подчеркивает база данных Ping Kai: база данных отвечает за надежное хранение и высокопроизводительные запросы, а службы приложений отвечают за бизнес-правила, управление процессами и вычислительную логику.

Самым большим изменением, вызванным этим наслоением, является уменьшение системной связи.

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

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

В конечном счете, эта архитектурная настройка является не простым техническим выбором, а проявлением способности системы устойчиво развиваться.

Когда прикладной уровень отвечает за «умный» и уровень базы данных отвечает за «надежность», надежность всей системы сделает качественный скачок.

Усилители трендов: Прибытие кодирования ИИ

Если облачные аборигены изменили способ развертывания систем, кодирование ИИ меняет способ производства программного обеспечения. В этом контексте некоторые проблемы с хранимой процедурой еще более усиливаются.

Повышенная эффективность ИИ в области НИОКР в значительной степени зависит от стандартизированной инженерной семантики и открытой цепочки инструментов. Современный код приложений (например, Java, Go, Python) имеет зрелую систему тестирования и развертывания, и в ИИ легко участвовать.

Но хранимые процедуры часто используют диалекты баз данных, не имеют стандартизированных описаний и их трудно включить в современные процессы CI/CD. Когда ИИ пытается участвовать в обслуживании хранимых процедур, его рекомендации по генерации часто трудно проверить из-за отсутствия контекста и среды тестирования.

Тогда возникает ситуация, когда уровень применения быстро улучшается в эффективности с помощью ИИ, в то время как процесс хранения постепенно стал «длинным хвостом», чтобы замедлить эффективность команды.

В то же время меняется способ взаимодействия программного обеспечения и данных.

Будущий доступ к данным больше не является простым SQL-запросом, а все больше и больше осуществляется через сервисные интерфейсы или семантические вызовы. Если логика жестко закодирована внутри базы данных, эта тесно связанная структура напрямую ограничивает гибкость системы.

С этой точки зрения, хранимая процедура больше похожа на менее прозрачный «логический черный ящик». Чем более мощный ИИ, тем очевиднее эволюционные трения, которые приносит эта архитектура.

Таким образом, появление ИИ-кодирования привело к тому, что архитектура системы ускорила «выживание наиболее приспособленных». Архитекторы переосмысливают процессы хранения, не отрицая инженерную мудрость прошлого, а расчищая путь для «разумной эволюции» будущего. Когда уровень приложения является «умным и гибким», а уровень базы данных достаточно «надежный и чистый», система может оставаться легкой в волне ИИ и достичь истинной непрерывной эволюции.

Когда система начнет развиваться таким образом, база данных может вернуться к своей лучшей роли - стабильной, эффективной базе данных и больше пространства для бизнес-логики. Это то, чего пытаются достичь многие архитектурные проекты баз данных: пусть база данных фокусируется на данных, и позволяет приложению сосредоточиться на бизнесе. Конечно, это также то, что было подчеркнуто в архитектурном дизайне базы данных Pingkai. Для многих компаний эта корректировка является не только технологическим выбором, но и важным шагом для системы, чтобы двигаться в будущее.