Как многие говорили, немного преждевременно разбивать вашу таблицу на более мелкие таблицы (горизонтальное секционирование или даже сегментирование). Базы данных предназначены для обработки таблиц такого размера, поэтому проблема с производительностью, вероятно, связана с чем-то другим.
Индексы - это первый шаг, хотя похоже, что вы это сделали. 4 миллиона строк должны быть в порядке, чтобы БД могла обрабатывать индекс.
Во-вторых, проверьте количество запросов, которые вы выполняете. Вы можете сделать это с помощью чего-то вроде панели инструментов отладки django, и вы часто будете удивлены, сколько ненужных запросов будет сделано.
Кэширование — это следующий шаг, используйте memcached для страниц или частей страниц, которые не изменяются для большинства пользователей. Именно здесь вы увидите самый большой прирост производительности при минимальных усилиях.
Если вам действительно нужно разделить таблицы, последняя версия django (1.2 alpha) может справиться с сегментированием (например, с несколькими базами данных), и вы должны быть в состоянии вручную написать решение для горизонтального разделения (postgres предлагает in-db способ сделать это). Пожалуйста, не используйте жанр, чтобы разделить столы! выберите что-то, что вы никогда не будете менять и что вы всегда будете знать, делая запрос. Лайкнуть автора и разделить по первой букве фамилии или что-то в этом роде. Это требует больших усилий и имеет ряд недостатков для базы данных, которая не особенно велика — вот почему большинство людей здесь советуют против этого!
[редактировать]
Я упустил денормализации! Поместите общие подсчеты, суммы и т. д., например, в таблицу авторов, чтобы предотвратить объединение по общим запросам. Недостатком является то, что вы должны поддерживать его самостоятельно (пока django не добавит DenormalizedField). Я бы посмотрел на это во время разработки для ясных, простых случаев или после того, как кэширование подвело вас --- но хорошо перед сегментированием или горизонтальным разделением.
person
Will Hardy
schedule
12.01.2010
