ограничения транзакций хранилища данных

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

  • user.cash уменьшен
  • user.contracts увеличивается на число
  • Contracts.current_price обновляется.
  • market.no_of_transactions увеличивается на 1.

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

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

edit: я явно пропустил группы сущностей. Теперь я был бы признателен за дополнительную информацию о том, как они используются. Еще один момент, который нужно уточнить, это то, что Google говорит: «Используйте группы сущностей только тогда, когда они необходимы для транзакций. Для других отношений между сущностями используйте свойства ReferenceProperty и значения Key, которые можно использовать в запросах». означает ли это, что я должен определить как ссылочное свойство (поскольку мне нужно их запрашивать), так и отношения родитель-потомок (для транзакций)?

редактировать 2: и, наконец, как определить двух родителей для объекта, если объект создается для установления отношения n-to-n между двумя родителями?


python google-cloud-datastore google-app-engine transactions
person shanyu    schedule 07.05.2009    source источник

Ответы (3)


arrow_upward
0
arrow_downward

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

person shanyu    schedule 08.05.2009

arrow_upward
0
arrow_downward

Позвольте мне добавить цитату из документации хранилища данных:

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

Вы можете создать псевдокорневую сущность и поместить все ниже нее. Затем вы выполняете все в транзакции.

person Manuel    schedule 24.01.2010

arrow_upward
0
arrow_downward

shanyu, вы упомянули уровень распределенных транзакций, который позволяет вам работать с произвольно большим количеством групп сущностей в одной транзакции. на самом деле он был выпущен, просто его не очень громко рекламировали. она была разработана и написана Дэниелом Уилкерсоном и Эриком Армбрустом при некоторых моих консультациях. Дэн описывает это в этом выступлении.

ник джонсон также описал как выполнять операции типа "перенос" между объектами группы, подобные тому, что вы описываете. это не такое универсальное средство, как тапиоковая форма, но оно проще и легче.

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

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

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

person ryan    schedule 25.01.2011
comment
@systempuntoout Я имел в виду, что вы должны писать в другую группу сущностей в обработчике задач, а не в исходной транзакции. - person ryan; 06.06.2011
comment
недоразумение, мой бесполезный комментарий испарится через несколько минут :). - person systempuntoout; 06.06.2011