Что лучше разбить ОГРОМНЫЕ таблицы в SQL Server?

Question

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

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

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

Спасибо

Кстати, я спрашиваю об этом, поскольку я начинаю на EntityFramework и, кажется, я не могу использовать его для создания таблиц во время выполнения без добавления ADO.NET, поэтому мне нужно заранее знать, какие таблицы мне нужны (и поэтому я не могу добавить новые таблицы для новых ценных бумаг).Или я все неправильно понял?

Answer 1

Таблицы могут быть разделены поверх хранилища, однако это может не быть в ваших интересах:

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

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

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

Answer 2

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

Answer 3

Вам должно быть хорошо с одной таблицей и соответствующим выбором индексов и ограничений.

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

Я бы, наверное, подумал, что кластерный индекс будет тикером (может быть суррогатом int в таблице тикеров или просто тикером) и временем.

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

Answer 4

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

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

Если это абсолютно необходимо, вы можете разбить таблицу. В SQL 2008 или выше вы также можете создавать отфильтрованные индексы , которые охватывают только часть строк в таблице.

Обновления не будут отличаться от задач в отдельных таблицах.

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