Как структурировать очень большой стол

Question

Это скорее концептуальный вопрос.Он вдохновлен использованием какой-то чрезвычайно большой таблицы, где даже простой запрос занимает много времени (правильно проиндексирован).Мне было интересно, есть ли лучшая структура, чем просто позволить столу постоянно расти.

В целом я имею в виду более 10 000 000 записей, которые растут каждый день примерно на 10 000 в день.Такая таблица будет бить 10 000 000 дополнительных записей каждые 2,7 года.Допустим, более поздние записи больше всего доступны, но старые должны оставаться доступными.У меня есть две концептуальные идеи, чтобы ускорить его.

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

2) Другой вариант будетбыть, чтобы создать отдельную таблицу для каждого года.Затем снова используйте объединение, чтобы объединить их при запросе.

Есть ли у кого-нибудь еще какие-либо идеи или концепции?Я знаю, что это проблема, с которой столкнулся Facebook, так как вы думаете, как они справились с этим?Я сомневаюсь, что у них есть одна таблица (status_updates), которая содержит 100 000 000 000 записей.

Answer 1

Все основные поставщики СУБД имеют схожие концепции с точки зрения секционированных таблиц и секционированных представлений (а также их сочетаний)

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

С точки зрения управления СУБД, разделение данных на отдельные разделы позволяет выполнять операции на уровне разделов, выполнять резервное копирование / восстановление / индексирование и т. Д. Это помогает сократить время простоя, а также значительно ускорить архивирование, просто удаляя все раздел за один раз.

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

10 миллионов строк не так велики в масштабах больших систем, многораздельные системы могут и будут содержать миллиарды строк.

Answer 2

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

Если ваше ядро ​​базы данных поддерживает «семантическое разбиение», то вы можете разбить одну таблицу на разделы. Каждый раздел будет охватывать некоторый поддиапазон (скажем, 1 раздел в год). Это не повлияет ни на что в синтаксисе SQL, кроме DDL. И движок будет прозрачно выполнять скрытое сканирование логики объединения и секционированного индекса со всем параллельным оборудованием, которое у него есть (ЦП, ввод-вывод, хранилище).

Например, Sybase допускает до 255 разделов, так как это предел объединения. Но вам никогда не понадобится ключевое слово "union" в запросах.

Answer 3

Ваша вторая идея выглядит как разделение.

Я не знаю, насколько хорошо это работает, но в MySQL есть поддержка разделов - см. В его руководстве: Глава 17Перегородки

Answer 4

То, о чем вы говорите, это горизонтальное разбиение или шард .

Answer 5

Часто лучший план - иметь одну таблицу, а затем использовать разбиение базы данных.

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