Обработка сотен из 1000000 строк в T-SQL2005 - PullRequest
Новая
       20

Обработка сотен из 1000000 строк в T-SQL2005

3 голосов
/ 21 июля 2010

У меня есть пара баз данных, содержащих простые данные, которые необходимо импортировать в схему нового формата. Я придумал гибкую схему, но она полагается на критические данные старых БД, которые будут храниться в одной таблице. Эта таблица имеет только первичный ключ, внешний ключ (оба типа int), поле даты и времени и десятичное поле, но добавление количества строк из двух более старых баз данных указывает, что общее количество строк для этой новой таблицы будет составлять около 200 000 000 строк.

Как мне поступить с таким количеством данных? Это данные за 10 лет и должны быть доступны. К счастью, нам не нужно извлекать даже 1% из них при выполнении запросов в будущем, но все это должно быть доступно.

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

Любая помощь, идеи, предложения очень, очень, очень ценятся,

Мт.

Ответы [ 3 ]

1 голос
/ 21 июля 2010

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

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

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

  • Дизайн базы данных будет очень трудным для понимания (особенно если учесть, что элементы одного и того же типа не могут быть естественными в разных местах).

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

  • Требуется автоматизировать кучу задач. Давайте посмотрим, у вас есть стол в год. Если новая запись будет вставлена ​​в 2011-01-01 00: 00: 00.001, будет ли создана новая таблица? Будете ли вы проверять каждую вставку, нужно ли создавать новую таблицу? Как это повлияет на производительность? Вы можете проверить это легко?

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

1 голос
/ 21 июля 2010

С таким маленьким размером кортежа (2 дюйма, 1 дата-время, 1 десятичная дробь) я думаю, что у вас все будет хорошо, если у вас будет одна таблица со всеми результатами в ней. SQL Server 2005 не ограничивает количество строк в таблице.

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

РЕДАКТИРОВАТЬ: Предполагая, что вы используете DECIMAL (9) или меньше, ваш общий размер кортежа составляет 21 байт, что означает, что вы можете хранить всю таблицу в менее чем 4 ГБ памяти. Если у вас есть приличный сервер (8+ ГБ памяти) и это основной пользователь памяти, тогда таблица и вторичный индекс могут быть сохранены в памяти. Это должно обеспечить сверхбыстрые запросы после более медленного времени прогрева перед заполнением кэша.

1 голос
/ 21 июля 2010

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

Теперь, для предложений, вы рассмотрели разделение?Вы можете создать разделы по временному диапазону или один раздел с 1% общего доступа, а другой - с 99% данных.

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

С другой стороны, может иметь смысл разделить таблицы на «текущие» и «исторические».

Еще одно возможное улучшение размера - использование int(как в эпоху) вместо datetime и предоставляют функции для преобразования из datetime в int, таким образом, имея такие запросы, как 

SELECT * FROM megaTable WHERE datetime > dateTimeToEpoch('2010-01-23')

Эта экономия размера, вероятно, будет иметь эффективность с точки зрения затрат, если вам нужно выполнять сложные запросы datetime, Хотя для кубов существует стандартная техника хранения, вместо эпохи, int в формате ГГГГММДД.

...