SQL Server 2008 - несколько процессов импорта одновременно - PullRequest
3 голосов
/ 17 августа 2011

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

У меня есть одна базовая таблица, которая получает наибольшее количество обращений при запуске процессов импорта.У меня есть 2 варианта:

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

Кто-нибудь может подсказать, какой из них лучше и почему?


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

Запрос касается моделирования данных для основных функций моего приложения.

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

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

У меня есть 2 варианта: 1. Чтобы иметь 2 основных таблицы и выполнить последовательный импорт, создав очередь для процессов импорта.

Таблица 1

ID ClientID SourceID Count ДругоеCol1 AnotherCol2 AnotherCol3

Таблица 2

ID ClientID Порядок идентификаторов AnotherCol4 AnotherCol5 AnotherCol6

  1. Наличие 1000 базовых таблиц, 2 для каждого клиента (У меня может быть максимум 500 клиентов), это позволит пользователям одновременно работать над процессами импорта, не дожидаясь друг друга.

Дополнительная информация о процессе импорта: 1. Эти таблицы не собираютсябыть использованы в любой отчетности.2. Каждый процесс импорта будет вставлять записи по 20–30 тыс. (7 столбцов) в каждую таблицу.И будет около 40-50 таких импортных товаров в день.3. Во время процесса импорта данные могут быть получены из этих таблиц другим пользователем, а также INSERT OR UPATATED.4. Это будет одна из самых полезных таблиц в приложении.5. BULK INSERT будет использоваться для вставки.6. Кластерный индекс находится на первичном ключе, который является столбцом идентификации.7. Мы также рассматриваем разделение таблиц.

Подскажите, пожалуйста, какой вариант лучше и почему?

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


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

Запрос касается моделирования данных для основных функций моего приложения.

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

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

У меня есть 2 варианта: 1. Чтобы иметь 2 основных таблицы и выполнить последовательный импорт, создав очередь для процессов импорта.

Таблица 1

ID ClientID SourceID Count ДругоеCol1 AnotherCol2 AnotherCol3

Таблица 2

ID ClientID Порядок ID CountCol4 AnotherCol5 AnotherCol6

  1. Чтобы иметь 1000 базовых таблиц, 2 для каждого клиента (У меня может быть максимум 500 клиентов), это позволит пользователям одновременно работать над процессами импорта, не дожидаясь друг друга.

Дополнительная информация о процессе импорта:1. Эти таблицы не будут использоваться в любой отчетности. 2. Каждый процесс импорта будет вставлять записи по 20–30 тыс. (7 столбцов) в каждую из этих таблиц. И будет около 40-50 таких импортных товаров в день. 3. Во время процесса импорта данные могут быть получены из этих таблиц другим пользователем, а также INSERT OR UPATATED. 4. Это будет одна из самых полезных таблиц в приложении. 5. BULK INSERT будет использоваться для вставки. 6. Кластерный индекс находится на первичном ключе, который является столбцом идентификации. 7. Мы также рассматриваем разбиение таблиц.

Подскажите, пожалуйста, какой вариант лучше и почему?

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

Ответы [ 2 ]

3 голосов
/ 17 августа 2011

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

Сценарий 1: центральный основной стол

  • Плюсы: центральный стол, легкие глобальные модификации
  • Минусы: более медленный импорт, более сложные модификации на уровне клиента

Сценарий 2: 300 базовых таблиц

  • Плюсы: более быстрый импорт, легкая настройка клиента
  • Минусы: более сложные развертывания изменений для всех 300 базовых таблиц, отчетность, которая должна затрагивать все таблицы, будет более сложной и, вероятно, также более медленной

В конце ответ - то, что действительно работает для вас

2 голосов
/ 17 августа 2011

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

Основная проблемаНаличие нескольких человек в одной таблице означает, что вы не можете делать такие вещи, как TRUNCATE.

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

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

...