Моделирование сущностей AppEngine - минимизация групп сущностей и достижение атомарного каскадного обновления / удаления

Question

Я изучаю AppEngine и начал разрабатывать новое приложение и хочу кое-что прояснить.

Я понял, что а.Чтобы добиться атомарности обновления / удаления нескольких объектов, нам нужно сделать это в транзакции, и, следовательно, все они должны находиться в одной группе объектов b.Наличие больших групп сущностей не масштабируется, так как вызывает конфликт.(Q1: Правильно?)

Итак, вот модель сущности системы онлайн-экзаменов для обсуждения:

Сущности: Страница предметного экзамена Вопрос Ответ

Как вы можетесмотри сверху, каждая сущность 1 - множество отношений с ближайшей нижней, т. е. 1 у субъекта может быть много экзаменов, 1 экзамен -> много страниц, на 1 странице может быть много вопросов ...

Как видите,я хотел бы установить каскадные отношения обновления / удаления между этими объектами (реализация приложения AppAgine JPA datanucleus поддерживает это (скрыто), помещая все объекты в одну группу объектов (Q2: исправить?), хотя AppEngine изначально не поддерживает это ограничение), такЕстественно, все будет идти под одной и той же группой лиц, так чтоя могу удалить страницу (если это сделал мой пользователь) в транзакции и быть уверенным, что все страницы, вопросы, ответы удалены. б.или я могу полностью удалить тему в транзакции, очистить все, что находится под ней

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

Q3: Пожалуйста, посоветуйте, как переосмыслить этот дизайн (и лучшие практики) и все же достичь того, что мне нужно.Спроси меня больше, если нужно.Было бы замечательно, если бы вы могли указать мне на соответствующие примеры.

PS 1 решение, о котором я мог бы подумать, - это иметь каждую сущность в отдельной группе сущностей и отдельное постоянное поле в каждой сущности (скажем, экзамен) с именем «IS_DELETED».по умолчанию FALSE (значение 0).Как только пользователь удалит экзамен, я установлю поле в 1 (ИСТИНА), и я больше не буду их загружать.Я напишу задание Cron, которое очищает все связанные сущности в отдельной отдельной транзакции в серверной части, которая при необходимости будет повторять попытки при сбоях.Но я уверен, что это не элегантно, и не уверен, сработает ли это.

Спасибо всем за ответы, Хари

Answer 1

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

Имеет смысл использовать сущности Exam в качестве родительских для страниц; с одной стороны, каждый экзамен, вероятно, ограничен небольшим количеством разумных страниц, поэтому его масштабирование вряд ли повредит.

С другой стороны, вероятно это очень много экзаменов по предмету, и по этой причине предметы должны не появляться в предках экзаменов (и, соответственно, страниц ).

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

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

Очередь задач извлекает блок затронутых объектов из хранилища данных, обновляет их и затем проверяет время. Если для продолжения обновлений остается больше времени, он вытягивает другой блок сущностей и т. Д., Пока не останется ни одного. Если время почти истекло, задача просто добавляет себя обратно в очередь, чтобы она могла перезапуститься с того места, на котором она остановилась, когда она возрождается.

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