Требуются ли хранимые процедуры для больших наборов данных?

Question

Я только начал свою первую работу по разработке для компании разумного размера, которая должна управлять большим количеством данных. Средняя база данных составляет 6 ГБ (из того, что я видел до сих пор). Одной из работ является отчетность. Как это делается в настоящее время -

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

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

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

Итак, мой вопрос - требуются ли хранимые процедуры, когда у вас очень большой набор данных? Действительно ли запросы так долго обрабатываются для такого большого объема данных, или есть проблема с серверами БД или с тем, как данные расположены (и проиндексированы?). У меня такое ощущение, что что-то не так.

Answer 1

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

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

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

Вы также можете рассмотреть возможность использования служб SQL Server Analysis Services для обслуживания ваших требований к отчетности, поскольку в ваших отчетах содержится много агрегированных данных. Хранение и обработка данных с целью быстрого подсчета и анализа - это именно то, чем занимается SSAS. Похоже, для вашего бизнеса настало время выглядеть как хранилище данных.

Надеюсь, это поможет, но, пожалуйста, не стесняйтесь запрашивать дополнительную информацию.

Ура, Джон

Answer 2

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

В этом случае ваши непосредственные преимущества в производительности:

1. Во-первых, потому что, если SP включает в себя какую-либо обработку, кроме простого выбора, обработка данных в базе данных может быть на несколько порядков быстрее, чем отправка строк по сети в вашу программу для обработки там.
2. Вы получаете некоторые преимущества в том, что SP хранится скомпилированным. Это обычно незначительно по сравнению с 1. если обрабатывать большие объемы

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

1. Структуры данных могут быть абстрагированы от логики программы, что позволяет изменять структуры базы данных, не требуя изменений в программах, обращающихся к данным. Любой, кто потратил часы на поиск корпоративной базы кода для SQL, используя [mytable], прежде чем вносить простые изменения в базу данных, оценит это.
2. SP могут обеспечить уровень безопасности, хотя его можно использовать слишком много и использовать слишком много.

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

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

Answer 3

При обработке большого количества строк, когда индексы доступны и SQL настроен относительно, ядро ​​базы данных, выполняющее операции на основе набора непосредственно над данными - скажем, через SQL - почти всегда будет превосходить построчную обработку ( даже на одном сервере) в инструменте клиента. Данные не пересекают какие-либо физические или логические границы, чтобы покинуть процессы сервера базы данных или покинуть сервер базы данных и выйти через сеть. Даже выполнение RBAR (ряд за агонизирующей строкой) на сервере будет быстрее, чем выполнение его в клиентском инструменте, если только ограниченный объем данных действительно должен покинуть сервер, потому что ...

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

Все это на самом деле не имеет ничего общего с хранимыми процедурами. Хранимые процедуры (в SQL Server) больше не дают больших преимуществ по сравнению с пакетным SQL. Хранимые процедуры предоставляют большое количество других преимуществ, таких как модульность, инкапсуляция, управление безопасностью, проектирование по контракту, управление версиями. Производительность, однако, больше не является преимуществом.

Answer 4

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

Answer 5

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

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

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

Я предполагаю, что ваша база данных отчетов является хранилищем данных, а данные ETL-данных и хранятся в формате для целей отчетности. Там, где я сейчас работаю, это обычная практика.

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

Answer 6

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

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

Если вы перемещаете большие объемы данных на другие серверы, я бы подумал об использовании DTS (при использовании SQL Server 2000) или служб SSIS. Это может еще больше ускорить ваши процессы, но это будет сильно зависеть от того, что вы делаете и как.

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

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

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

Answer 7

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

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

Если указать объем данных, которые нужно перемещать, если бы я использовал SQL-сервер, я бы посмотрел на SSIS или DTS - у оракула будет нечто подобное. Служба SSIS выполняет преобразования данных во многих потоках, одновременно заботясь о многих деталях.

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

Answer 8

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

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

И да, в зависимости от сложности отчета, такой запрос может занять полчаса или дольше ...

Answer 9

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

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

Answer 10

Я мог бы придумать больше, но несколько моментов.

1. Предполагая, что современные БД хранимые процедуры, вероятно, не будут заметно быстрее обычных процедур из-за кэширования и тому подобного.
2. Преимущества безопасности хранимых процедур несколько переоценены.
3. Изменение это зло. Последовательность - король.

Я бы сказал, что # 3 превосходит все остальные проблемы, если только хранимые процедуры не вызывают законную проблему.