Контрольный список для оптимальной производительности в приложении импорта базы данных - PullRequest
Новая
       160

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

0 голосов
/ 13 января 2009

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

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

Я планирую разработать контрольные списки для следующих основных тем:

  1. Оборудование базы данных. Прежде всего, нужно ли доказать, что оборудование сервера подходит?
  2. Конфигурация базы данных. Следующий шаг - убедиться, что база данных настроена на оптимальную производительность?
  3. Схема базы данных - имеет ли схема базы данных звуковой дизайн?
  4. Приложение базы данных - включает ли приложение звуковые алгоритмы?

Ответы [ 3 ]

1 голос
/ 13 января 2009

Хорошее начало. Вот рекомендуемые приоритеты.

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

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

  2. Схема базы данных №2. У вас есть правильные таблицы и правильные индексы? Нагрузка не требует никаких индексов. В основном вы хотите удалить и перестроить индексы.

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

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

  3. Конфигурация. Имеет значение, но намного, намного меньше, чем дизайн схемы и дизайн приложения.

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

1 голос
/ 13 января 2009

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

Если приложение вставляет отдельные строки, есть ли причина для этого? Это использует DTS или BULK INSERT или BCP? Это загрузка в промежуточный стол или таблицу с триггерами? Он загружается партиями или пытается загрузить и зафиксировать весь пакет? Есть ли обширное преобразование или преобразование типов данных строк на их пути? Существует ли обширное преобразование данных в другую схему или модель?

Я не буду беспокоиться о 1 и 2, пока не выясню, являются ли используемые методы ETL разумными, и если они импортируют данные в существующую схему, тогда у вас не будет большого пространства, чтобы что-либо менять 3. Что касается импорта и 4, я предпочитаю не делать много алгоритмов для данных во время загрузки.

Для достижения наилучшей производительности в самых общих случаях загружайте в плоскую промежуточную таблицу с хорошим надежным преобразованием базовых типов и исключениями, сделанными в это время (с использованием служб SSIS или DTS). Для очень больших данных (скажем, многомиллионных ежедневных загрузок) я загружаю 100 000 или 1 000 000 пакетов записей (это легко устанавливается в BCP или SSIS). Любые производные столбцы создаются либо во время загрузки (SSIS или DTS), либо сразу после UPDATE. Запускайте исключения, проверяйте данные и создавайте ограничения. Затем обработайте данные в окончательной схеме как часть одной или нескольких транзакций - ОБНОВЛЕНИЯ, ВСТАВКИ, УДАЛЕНИЯ, ГРУППЫ BY для измерений или объектов или чего-либо еще.

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

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

1 голос
/ 13 января 2009

Три элемента я бы добавил в список:

  1. Массовая вставка - импортируете ли вы данные с помощью массового поставщика (т. Е. BCP или SqlBulkCopy) или с помощью отдельных операторов INSERT / UPDATE?
  2. Индексы. Есть ли у вас индексы на ваших целевых таблицах? Могут ли они быть отброшены до импорта, а затем восстановлены после?
  3. Блокировка - возникает ли конфликт при попытке импорта данных?
...