Из-за чего низкая скорость обработки больших таблиц (ManyToManyField) в административном интерфейсе Django?

Question

[dustik]

Здравствуйте, уважаемое сообщество. Столкнулся с проблемой, уповаю на ваши всеобъемлющие знания.

Суть проблемы:
Есть вот такие модели приложения каталога книг (elcat):
1.

# Таблица с книгами
class book(models.Model):
    book_id = models.BigIntegerField(primary_key=True, unique=True)
    name = models.CharField(max_length=512)
    ...
    author_id = models.ManyToManyField('author')
    ...

2.

#Таблица с авторами
class author(models.Model):
    author_id = models.BigIntegerField(primary_key=True)
    name = models.CharField(max_length=512)

3. Таблица сгененированная фреймворком Django:


Количество записей в таблицах:
elcat_book = 121525
elcat_author = 49832

Когда работаешь с книгой в стандартном административном интерфейсе Django, то загрузка страницы с книгой происходит довольно медленно, видимо это из-за того, что загружаются все записи из таблицы 'elcat_author' в поле 'elcat_book.author_id'.
Пробовал воспользоваться рекомендацией из книги The Definitive Guide to Django:
filter_horizontal = (author_id',)
, но в этой ситуации загрузка не становится быстрее и кроме этого очень часто JavaScript-сценарий реализующий filter_horizontal совсем перестает работать и броузер приходится принудительно выключать.
Возможно мне может помочь raw_id_fields , но я так и не смог понять будет ли он работать для ManyToManyField.

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

---------------------------------
Версия Django = VERSION = (1, 6, 0, 'final', 0);
python = 2.7.1;
MySQL = '5.6.13-log'.
Все работает на Windows 7 (x64) Pro.

Answer 1

[Hellpain]

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

class AdminBook(ModelAdmin):
    raw_id_fields = ('author_id', )

site.register(Book, AdminBook)

Здесь еще информация об оптимизации скорости работы админки. перейти

Answer 2

[leclecovich]

Во-первых, BigIntegerField в качестве PK не самая лучшая с точки зрения оптимизации идея. Опустите book_id и author_id в author. Django сама подставит AutoField. Кроме того, логичнее relation выглядит когда:

class book(models.Model):
    name = models.CharField(max_length=512)
    ...
    author = models.ManyToManyField('author')

Во-вторых убедитесь, что при выборке средствами ORM будет вызван prefetch_related правильным образом.
Ну и общая рекомендация, используйте вывод запросов в логи для ORM, или воспользуйтесь django-debug-toolbar.

Comments

[dustik]

Спасибо. Воспользуюсь вашими рекомендациями. Конечно, возможно, придется немного повозиться с данными в самой СУБД MySQL, т.к. BigInteger не просто так взялся, это костыль который пришлось использовать для обеспечения уникальности id-шников при конвертации и переносе всего хозяйства из кучи xls-файлов. У меня были мысли про затык именно в этом месте, т.к. уже столкнулся со сложностями при создании индекса для sphinx, пришлось даже новый автоинкрементный столбец добавить.

Еще подскажите, пожалуйста, а вообще по вашему опыту, с учетом моего объема данных в таблицах, при условии что не допущены серьезные ошибки в архитектуре БД, админка django должна справляться? Или при увеличении объема данных нужно присмотреться к другим средствам?

[leclecovich]

@dustik, для миграции в mysql воспользуйтесь south.
Да, с точки зрения админки, проблем не вижу. Но опять же, нужно настраивать админку, начиная с prefetch_related в нужных местах, например, как здесь stackoverflow.com/questions/15563259/django-prefet... Хотя, идеологически правильнее, сделать полноценное django приложение, чем твикать админку.