Как обрабатывать «справочные данные» (статические данные) в хранилище данных Google App Engine?

Question

У меня есть приложение, над которым я работаю, где у меня есть набор данных, который, хотя и не является технически статичным, не будет меняться очень часто (скажем, в среднем 3 или 4 раза в год).Однако некоторые из этих данных взаимосвязаны.

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

В прошлом я имелСделайте это в реляционной базе данных, имея таблицу состояний и округов, где округ связан с состоянием, в котором он находится, а штат и округа связаны с любыми таблицами, которым требуется их информация.

Эти данныеоднако он не принадлежит, и в хранилище данных Google создается впечатление, что механизм транзакций блокировки будет вызывать блокировки, даже если мы не будем активно изменять эти данные.Каков наилучший способ обработки данных такого типа?Нужно ли иметь сущность для частей, у которых нет родителя (родитель None / null)?Не вызовет ли это в будущем проблемы с блокировкой?

Answer 1

Я бы хотел сохранить это в оптимизированной структуре данных внутри вашего кода и обновить его вручную. Увеличение производительности будет огромным, и, поскольку Google взимает с вас плату за это, вы в конечном итоге поблагодарите его.

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

Простой подход заключается в составлении списка стран, в каждом из которых есть список государств. Вы можете загрузить их в def main (): , прежде чем запускать приложение. Конечно, это принесет всевозможные проблемы, если вы не будете осторожны, но если это так, у вас все будет хорошо.

Более продвинутым было бы хранить в памяти только наиболее используемые данные, а ленивые страны загрузки и выгрузки на лету.