Обсуждение архитектуры системы баз данных

Question

Я бы хотел начать обсуждение о внедрении системы баз данных.

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

Позвольте мне попытаться описать, что он делает и как он реализован:

Система разделена на 3 основные части, которые обрабатываются 3 различными командами.

1. запись: Entry Team отвечает за создание графических интерфейсов для системы. На заднем плане огромная база данных MS SQL (около 100 таблиц), а графический интерфейс создается с использованием .NET. Существуют разные приложения с графическим интерфейсом, и у каждого приложения есть много разных вкладок для заполнения соответствующих таблиц. Например, если новый столбец добавляется в базу данных, этот столбец добавляется вручную в приложение с графическим интерфейсом.

2. Dataflow: Цель группы обработки данных - выполнять вычисления данных и подготавливать данные для группы отчетности. Это делается через несколько уровней. Позвольте мне попытаться объяснить процесс немного подробнее: команда потока данных использует данные из базы данных Entry, скопированные на другой сервер и в другую базу данных посредством Transactional-Replication (эти данные содержат информацию от всех клиентов). Затем один раз в час самостоятельно написанное приложение проверяет наличие измененных строк во входных таблицах (используя столбец ChangedDate) и затем вызывает хранимую процедуру для каждой выходной таблицы, вычисляя новые данные, используя 1-N входных таблиц. После этого данные копируются в другую базу данных на другом сервере, используя снова Transaction-Replication. Здесь другая хранимая процедура вызывается для расчета дополнительных новых таблиц вывода. Эта хранимая процедура запускается с использованием задания SQL. Оттуда данные разделяются на различные базы данных, каждая база данных зависит от клиента. Это копирование выполняется с помощью другого самостоятельно написанного приложения с использованием команды .NET bulkcopy (фильтрация на клиенте). Эти клиентские базы данных копируются в разные клиентские базы данных отчетов на других серверах через другое самописное приложение, которое сравнивает базу данных отчетов с клиентской базой данных для расчета разницы данных. Копируются только различия в данных (потому что база данных отчетов запускалась в прежние времена на клиентских серверах). Весь этот процесс организован другим самостоятельно написанным приложением, например, для управления. если транзакционные репликации завершены до запуска задания для вызова хранимой процедуры и т. д. Кроме того, здесь также организована синхронизация между различными клиентами. Процесс может быть графически отображен с помощью самостоятельно написанного инструмента мониторинга, который выглядит довольно сложным, как вы можете себе представить ... Статус всех этих компонентов регистрируется и может быть просмотрен другим самостоятельно написанным приложением. Если добавляются новые столбцы или таблицы, все эти компоненты должны быть изменены вручную. Для развертывания инструкции по установке написаны с использованием MS Word. (в этой команде работает около 10 человек)

3. Отчетность: Группа отчетов создала свою собственную платформу, написанную на .NET, чтобы позволить клиенту создавать пользовательские отчеты через графический интерфейс. Отчеты доступны через Интернет.

Самые большие таблицы имеют около 1 миллиона строк. Надеюсь, я не забыл ничего важного.

Хорошо, я хочу обсудить, как другие люди реализуют этот сценарий, я не могу себе представить, что каждая компания пишет свои собственные приложения. Каковы на самом деле возможности разрешить быстрые вычисления в базах данных (рядом с использованием T-SQL). Мне почему-то не хватает ссылки здесь на объектно-ориентированное программирование, к которому я привык из моей старой компании, но мы никогда не имели дело с таким большим количеством данных и, возможно, для быстрых вычислений это способ сделать это ... Или это возможно используя, например, LINQ или BizTalk Server для создания алгоритмов и расчетов, может быть, даже в графическом виде? Вопрос только в том, как преобразовать существующие хранимые процедуры длиной в метр в новый формат ...В будущем мы хотим использовать хранилище данных, но это займет некоторое время, поэтому, возможно, можно сделать отдельный шаг для оптимизации процесса.

Любые комментарии приветствуются.

Спасибо Daniel

Answer 1

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

Какие бы абстракции вы ни пытались выложить (LINQ, Biztalk и т. Д.), Все в конечном итоге преобразуется в чистый SQL. И почти всегда они добавляют накладные расходы и сложность.

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

Это займет некоторое время, но все это стоит знать, как профессионально, так и лично.

Answer 2

С какой стати вы хотите преобразовать существующие рабочие хранимые проки (которые можно настроить на производительность) в LINQ (или я вас неправильно понимаю)? Потому что лично ты не любишь t-sql? Не достаточно веская причина. Они слишком медленные? Затем они могут быть настроены (это то, что вы действительно не хотите делать в LINQ). Вполне возможно, что процесс можно улучшить с помощью SSIS, но такой сложный, как SSIS и количество времени, которое потребовалось бы для переписывания процесса, я не уверен, что вы действительно выиграете, сделав это.

«Мне почему-то не хватает ссылки здесь на объектно-ориентированное программирование ...» Реляционные базы данных НЕ являются объектно-ориентированными и не могут работать хорошо, если вы пытаетесь обращаться с ними так, как они. Учитесь мыслить в терминах наборов, а не объектов при доступе к базам данных. Вы исходите из мышления одного пользователя за раз, вставляя по одной записи за раз, но это не тот образ мышления, который необходим для передачи больших объемов данных. Для таких вещей лучше использовать базу данных для решения проблемы, чем делать вещи объектно-ориентированным образом. Когда у вас есть большой объем данных и большое количество отчетов, люди гораздо больше интересуются производительностью, чем вы, возможно, привыкли в прошлом, когда использовали некоторые инструменты, которые не могли бы быть столь хорошими для производительности. Нравится ли вам T-SQL или нет, это родной язык SQL Server, и база данных оптимизирована для его использования.

Answer 3

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

Текущий процесс объединен - ​​данные загружаются и обрабатываются в языке Focus и в базе данных Focus, а затем передаются (и сохраняются исторические данные)

В новом процессе, DW загружается, и затем начинается наш процесс. Наши процессы полностью закодированы в SQL, и таблица фактов из миллиона строк (за один месяц) будет относительно небольшой. У нас есть несколько каналов, где ежемесячные данные составляют 25 миллионов строк. Существует несколько статистических таблиц, которые содержат более 200 миллионов строк (в месяц). Обработка может занять несколько часов в месяц, от начала до конца. Мы используем таблицы для хранения промежуточных результатов, и мы гарантируем, что стратегии индексации подходят для обработки. За исключением одного компонента, реализованного в виде потока служб SSIS из базы данных обратно в себя из-за крайне низкой производительности скалярного UDF, вся система реализована в виде серии T-SQl SP.

У нас также есть система мониторинга процессов, аналогичная той, которую вы обсуждаете, а также наличие зависимостей в таблице, которая гарантирует, что каждый процесс выполняется только в том случае, если выполнены все его предпосылки. Недавно я использовал MSAGL для графического отображения и взаимодействия с процессом (ранее я использовал graphviz для генерации статических изображений) из приложения .NET Windows. Таким образом, новая система имеет гораздо более четкую информацию о зависимостях, а также хорошую информацию о производительности процесса, поэтому усилия могут быть сосредоточены на самых медленных узких местах.

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

Answer 4

Вам будет сложно победить производительность BCP и SQL с помощью чего-либо еще. Если процедуры обновления длинные и раздутые, потому что они перебирают таблицы, тогда я точно понимаю, почему вы хотите перейти на .NET. Но вы, вероятно, увеличите производительность, если поймете, как переписать их все красиво и на основе SET. БКП не сможет быть побежденным. Когда я использовал SQL Server 2000, BCP часто был быстрее, чем DTS. И SSIS в целом (из-за всей проверки типов данных), кажется, намного медленнее, чем DTS. Без сомнения, если вы убьете выступление, к вам придут люди. Тем не менее, если вы выполняете тонну построчных сложных вычислений, оптимизация в хранимую процедуру CLR или даже в приложение .NET, вызываемое из SQL Server для выполнения обработки, вероятно, приведет к ускорению. Конечно, если бы вы обрабатывали строки и вам удавалось переписать запросы для выполнения обработки множеств, вы, вероятно, получили бы большую скорость. Но в зависимости от сложности вычислений .NET может помочь.

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

Единственное, что я мог бы сделать, это то, что, возможно, существует много дубликатов SQL, которые выглядят одинаково, за исключением имени таблицы и / или имен столбцов. Если это так, вы, вероятно, можете использовать .NET в сочетании с SQL-SMO (или DMO при использовании SQL Server 2000) для генерации кода.

Вот пример, который я часто вижу для загрузки хранилища данных

Предполагается, что некоторые таблицы строк загружены данными из источника

выбрать измененные строки из источника во временных таблицах
посмотреть, были ли изменены какие-либо важные столбцы
если это так, прекратить существующую строку (или клонировать ее в некоторую таблицу истории)
вставить / обновить новую строку

Я часто вижу один из этих запросов на таблицу, и единственными вариантами являются имена таблиц / столбцов и, возможно, ссылки на ключевой столбец. Вы можете легко получить определения столбцов и ключей из SQL Server, а затем создать программу .NET для создания INSERT / SELECT / ETC. В худшем случае вам может понадобиться сохранить таблицу какого-либо типа с TABLE_NAME, COLUMN_NAME для важных столбцов. Тогда вместо того, чтобы оборачивать сложный процесс ETL и 20 или 200 запросов на обновление, вам просто нужно обернуть голову вокруг ОБНОВЛЕНИЯ и одного запроса. Любые изменения в том, как все делается, можно выполнить один раз и применить ко всем запросам.

В частности, я предполагаю, что вы можете применить эту технику к отдельным клиентским базам данных, если вы еще этого не сделали. Вероятно, все сценарии запросов / массового копирования одинаковы или почти одинаковы, за исключением имени базы данных / сервера. Таким образом, вы можете просто сгенерировать их на основе таблицы КЛИЕНТОВ или чего-то еще .....

Answer 5

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

Answer 6

Судя по тому, что вы говорите, у вас есть три этапа.

1. Входные данные
2. Анализ данных
3. Данные отчета

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

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