В какой точке я должен разделять или разделять очень большую, но простую таблицу

Наш сайт имеет несколько больших, но простых таблиц (INT, INT, DATE) для статистики. Каждая таблица имеет до 300 000 000 строк и увеличивается с каждым днем.

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

Однако ...

Я пытаюсь примирить этот совет с заявленной максимальной емкостью для SQL Server - размер базы данных 524 272 терабайт, с строками таблицы, ограниченными только «доступным хранилищем».

На основе этих цифр таблица, описанная выше, может легко иметь centillions строк (10 до мощности 303).

Ага, вы можете сказать, что существует разница между ВОЗМОЖНОСТЬЮ И ВЫПОЛНЕНИЕМ.

Но в практически каждый вопрос о производительности SQL Server отвечает: «Это зависит. .. на дизайн таблицы и дизайн запроса ".

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

8 голосов | спросил Martin Hansen Lennox 2 Jpm1000000pmFri, 02 Jan 2015 23:44:17 +030015 2015, 23:44:17

1 ответ


10

Есть причина, по которой общий совет заключается в том, что это зависит от дизайна таблицы и запросов на ней. Мой ответ на ваш другой пост на Stack Exchange говорит так же. Высказывание «запросов, которые являются простыми операциями count (*), основанные на индексированном поле идентификатора», не дает много информации, поскольку в нем ничего не говорится о мощности рассматриваемого набора строк. Вещи, которые вы можете сделать для смягчения (в настоящее время воспринимаемых) проблем:

  1. Разметка. В частности, ваши данные, похоже, являются данными типа регистрации. Я предполагаю, что вы хотите получить статистику по определенной единице времени (например, «виджеты в день» или «whozits by hour»). Разделение на ваш квант (т. Е. Дни или часы в предыдущих примерах) и иногда перемещать разделы в группы файлов только для чтения

  2. В соответствующей заметке, если данные являются однократными, рассмотрите предварительную агрегацию данных после того, как период времени больше не активен. Вот почему мне нужно постоянно подсчитывать, сколько событий произошло в день с трех лет назад, если эти данные никогда не будут меняться? Как только день закончится, посчитайте все в тот день, сохраните его в другом месте и никогда не пересчитывайте. На самом деле, если вам никогда не нужны подробные данные (т. Е. Вы только когда-либо делаете против них скопления), подумайте об удалении их после того, как вы посчитаете это. Если вы реализуете эту идею, вы можете стать еще более умным с отфильтрованными индексами, которые охватывают только «активный» период, который сделает ваши запросы быстрее, потому что они не будут охватывать подавляющее большинство ваших данных.

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

ответил Ben Thul 3 Jam1000000amSat, 03 Jan 2015 02:20:13 +030015 2015, 02:20:13

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132