Оптимизация скорости работы базы данных: несколько таблиц с несколькими строками или много таблиц с несколькими строками?

Question

У меня большое сомнение.

Возьмем в качестве примера базу данных для заказов любой компании.

Допустим, что эта компания делает около 2000 заказов в месяц, то есть около 24 тыс. Заказов в год, и они не хотят удалять заказы, даже если ей 5 лет (эй, это пример, цифры дон ничего не значит).

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

Моя идея заключалась в том, чтобы каждый год создавать новую таблицу для заказов, называя такие orders_2008, orders_2009 и т. Д.

Может быть хорошей идеей для ускорения запросов к БД?

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

Я думаю, что лучше иметь приложение, которое для 95% запросов выполняется быстро, а остальные несколько медленнее, чем приложение, которое всегда медленно.

Моя фактическая база данных состоит из 130 таблиц, в новой версии моего приложения должно быть около 200-220 таблиц, из которых около 40% будут реплицироваться ежегодно.

Есть предложения?

РЕДАКТИРОВАТЬ : СУБД, вероятно, будет Postgresql, может быть (надеюсь, нет) Mysql

Answer 1

Меньшие таблицы быстрее. Период.

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

Вот что такое хранилище данных - отделите оперативные данные от исторических данных.

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

Answer 2

Прежде чем беспокоиться о скорости запросов, рассмотрите затраты.

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

Также рассмотрите стоимость машинного времени и времени программиста.

Answer 3

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

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

Answer 4

Для объема данных, которые вы смотрите на разделение данных, кажется большой проблемой для небольшого выигрыша. Postgres может выполнять разбиение, но в прекрасном руководстве [1] сказано, что, как правило, вы должны учитывать это только для таблиц, которые превышают физическую память сервера. По моему опыту, это как минимум миллион строк.

1. http://www.postgresql.org/docs/current/static/ddl-partitioning.html

Answer 5

Я бы не разбивал таблицы по годам.

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

В качестве альтернативы вы можете распределить данные между дисками, поддерживая таким образом производительность, хотя я не уверен, возможно ли это в postgresql.

Answer 6

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

Answer 7

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

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

Индекс ускорит работу, но если данные разбросаны по всему диску, потребуется загрузка чтения блока, что может замедлить его работу.