Джанго стол с миллионами рядов

Question

У меня есть проект с 2 приложениями (книги и читатель).

Приложение в книгах имеет таблицу с 4 миллионами строк с этими полями:

 book_title = models.CharField(max_length=40)
 book_description = models.CharField(max_length=400)

Чтобы не запрашивать базу данных с 4 мимионами строк, я думаю, чтобы разделить ее на субъект (20 моделей с 20 таблицами с 200 000 строк (book_horror, book_drammatic, ecc).

В приложении «Читатель» я подумываю вставить эти поля:

reader_name = models.CharField(max_length=20, blank=True)
book_subject = models.IntegerField()
book_id = models.IntegerField()

Таким образом, вместо иностранного класса я думаю использовать целое число «book_subject» (которое позволяет получить доступ к соответствующей таблице) и «book_id» (что позволяет получить доступ к книге в таблице, указанной в «book_subject»).

Хорошим решением, чтобы не запрашивать таблицу с 4 миллионами рядов?

Есть альтернативное решение?

Спасибо ^__ ^

Answer 1

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

Индексы - это первый шаг, похоже, что вы сделали это. 4 миллиона строк должны быть в порядке, чтобы БД обрабатывался с помощью индекса.

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

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

Если вам действительно нужно разделить таблицы, последняя версия Django (1.2 Alpha) может обрабатывать Sharding (например, Multi-DB), и вы сможете вручную написать горизонтальное решение для разделения (Postgres предлагает in-db способ сделать это). Пожалуйста, не используйте жанр, чтобы разделить таблицы! Выберите то, что вы когда -либо не измените, и что вы всегда будете знать, делая запрос. Как автор и разделить первую букву фамилии или что -то в этом роде. Это большие усилия, и у него есть несколько недостатков для базы данных, которая не особенно большая-именно поэтому большинство людей здесь консультируют против нее!

редактировать

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

Answer 2

ForeignKey реализован как IntegerField В базе данных, так что вы мало что сэкономите к себе за счет нанесения вреда вашей модели.

Редактировать:И ради Пита, держите его в одной таблице и используйте индексы в зависимости от необходимости.

Answer 3

У вас проблемы с производительностью? Если это так, вам может понадобиться добавить несколько индексов.

Один из способов получить представление о том, где будет помогать индекс, - это просмотреть журнал запросов вашего сервера DB (инструкции здесь Если вы на MySQL).

Если у вас нет проблем с производительностью, просто пошли с этим. Базы данных созданы для обработки миллионов записей, и Django довольно хорош в создании разумных запросов.

Answer 4

Общий подход к этой проблеме Шардин. Анкет К сожалению, в основном это зависит от ORM, чтобы реализовать его (Hibernate делает это чудесно), и Джанго не поддерживает это. Тем не менее, я не уверен, что 4 миллиона рядов на самом деле так плохо. Ваши вопросы все еще должны быть полностью управляемыми.

Возможно, вам следует заглянуть в кэширование с чем -то вроде мемкахед. Анкет Джанго поддерживает это неплохо.

Answer 5

Вы не упомянули, какую базу данных вы используете. Некоторые базы данных, такие как MySQL и PostgreSQL, имеют чрезвычайно консервативные настройки вне коробки, которые в основном не используются для чего-либо, кроме крошечных баз данных на крошечных серверах.

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

Например, с MySQL вам, вероятно, нужно настроить настройки InnoDB; Для PostgreSQL вам нужно изменить wared_buffers и ряд других настроек.

Answer 6

Я не знаком с Джанго, но у меня есть общее понимание БД.

Когда у вас есть большие базы данных, это довольно нормально Установите свою базу данных. Анкет Таким образом, получение данных должно быть довольно быстро.

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

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