Django Fixture загружается в Google App Engine очень медленно

Я развернул веб-сайт Django с помощью Google App Engine и использую команду

python manage.py remote loaddata my_data.yaml

для заполнения хранилища исходными данными из файла фикстуры в формате yaml. Вот образец моего файла yaml:

- fields: {team: 10, first_name: Jeff, last_name: Adrien, age: 25, pos: SF, gp: 8, mp: 63, 
fg: 7, fga: 16, ft: 7, fta: 12, three_pointers: 0, threes_attempted: 0, orb: 5, drb: 17, 
ast: 1, stl: 0, blk: 2, tov: 2, pf: 13, pts: 21
}
  model: players.player
  pk: 1
- fields: {team: 7, first_name: Arron, last_name: Afflalo, age: 26, pos: SG, gp: 62, mp: 2086, 
fg: 329, fga: 699, ft: 197, fta: 247, three_pointers: 88, threes_attempted: 221, orb: 40, 
drb: 157, ast: 149, stl: 36, blk: 13, tov: 85, pf: 134, pts: 943
}
  model: players.player
  pk: 2

Общий размер файла yaml примерно в 20 раз больше (это pk: 478). Я не думал, что это так много, но загрузка в хранилище данных занимает невероятно много времени (несколько минут), хотя у меня довольно быстрое сетевое соединение (1 Мбит / с).

Кроме того, после загрузки я проверяю панель инструментов Google App Engine, и там говорится, что я выполнил 0,04 миллиона операций записи в хранилище данных. По моим расчетам, учитывая, что у меня есть 21 поле выше, плюс одно для pk, умноженное на 478 экземпляров модели, я должен выполнять только около 10K операций записи, а не 40K.

Произошла ли дополнительная запись из-за того, что я использую django-dbindexer для добавления индексов для полей first_name и last_name? И если да, то почему загрузка моих данных занимает так много времени?


django google-cloud-datastore google-app-engine django-nonrel
person GChorn    schedule 03.08.2012    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Удаленный API очень медленный. Если вы читали старый список рассылки google-appengine-python (вы можете найти его в группах Google), было отмечено, что он бесполезен для массовой передачи данных. API завершает выполнение HTTP-запроса для каждого запроса на чтение или запись. Итак, это известно. Похоже, что массовый загрузчик - это способ загрузки массовых данных (лично я не пробовал).

Ваши записи зависят от количества проиндексированных свойств, которые у вас есть, что, в свою очередь, зависит от количества ваших индексов. Возможно, dbindexer добавляет дополнительные индексированные поля. Вы должны иметь возможность просматривать фактические объекты в вашем хранилище данных с помощью администратора хранилища данных, чтобы узнать, есть ли у них поля, созданные dbindexer. Вы увидите дополнительные поля, такие как «idxf_first_name_iexact», если это ошибка dbindexer.

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

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

Я предлагаю вам очень скептически относиться к dbindexer. Я не использовал его широко, но операции JOIN, которые он может выполнять для вас, плохо масштабируются, поэтому, на мой взгляд, это просто игрушка, а не полезная функция. Вероятно, есть еще несколько вещей, для которых вы можете его использовать. Например, если вы хотите выполнять поиск без учета регистра, он автоматически добавит для вас поле 'iexact', вместо того, чтобы делать это вручную.

person dragonx    schedule 03.08.2012