Экономичное удаление данных из движка приложения

Question

У меня есть популярная социальная игра, для которой я хранил каждое пользовательское действие как объект события в хранилище данных, а затем раз в день экспортировал эти события из GAE для обработки.Теперь я хотел бы удалить все эти объекты из хранилища данных, все 300 миллионов из них.

Я начал использовать «администратора хранилища данных» для этого.За первые несколько часов работы я смог удалить около 2 миллионов объектов и использовать для этого ЦП на 10 долларов.Так что, кажется, это будет стоить $ 1500, чтобы запустить это удаление.Я начинаю думать, что было бы лучше просто удалить все приложение и скопировать элементы, которые я не хочу удалить, в новое приложение.

Есть ли другие варианты?

Обновление

Я получил совет по использованию #appengine в IRC, который заключается в простом получении ключей от 2000 объектов одновременно и порождениизадачи по их удалению по частям (могут передавать ключи в виде строк задачам) могут быть дешевле, чем использование инструмента администратора Datastore.Я пытаюсь сделать это сейчас и постараюсь не забыть доложить завтра, если это будет дешевле или нет.

Answer 1

Сначала удаление индексов существенно снизит стоимость удаления записей.Вы также можете ограничить частоту удаления, чтобы сохранить 6,5 ЦП в день, которые вы выделяете бесплатно, чтобы не платить.

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

Answer 2

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

Если у вас есть «приемлемая» стоимость ЦП в день, с которой вы бы хотели жить, вы можете уменьшить очередь меньше, в любом случае было бы лучше, если бы для каждого удаления не потребовалось слишком много времени, поэтому не сильно влияет на задержку экземпляра.

Комментарий kevpie относительно очистки может также иметь значение, если у вас есть составные индексы.

Answer 3

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

1. Настройте количество удалений, которое вы делаете, так, чтобы вы делали как можно больше, не получая тайм-ауты. Для меня это было около 200 сущностей на чанк, хотя иногда мне удавалось получить 400, но никогда больше.

2. Если вы можете делать запросы таким образом, чтобы получать только ключи, это более эффективно.

3. Мое наибольшее повышение эффективности было благодаря использованию Курсоров запросов . Это позволило более эффективные запросы с большими размерами чанка.

4. Используйте планирование, чтобы распространить боль. Это может быть автоматическое планирование cron или ручное планирование. Поскольку мой проект все еще был альфа-версией, я проверял свои квоты поздно вечером и выбрасывал неиспользованную квоту, запуская задачи удаления вручную.

5. Пожаловаться на Google. Это заставило меня чувствовать себя лучше.

Answer 4

Попробуйте удалить через remote_api.Это значительно сократит потребление процессорных часов http://code.google.com/appengine/articles/remote_api.html

Answer 5

Вопросы.- Сгруппированы ли объекты вашего мероприятия в группы объектов?- Сколько у вас индексов?Какие-нибудь сложные?Сколько свойств, которые не проиндексированы = False?

Просто пытаюсь определить стоимость удаления.

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

Answer 6

Вы имеете в виду, что вы использовали GQL в администраторе хранилища данных? Как, delete from x...? И это было слишком дорого? Ммм ...

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