Наиболее эффективные отношения "один-ко-многим" в хранилище данных Google App Engine?

Извините, если этот вопрос слишком прост; Я вхожу только в 9 класс.

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

Вот пример игрушек для сообщения в блоге и комментариев в отношениях "один ко многим". Что более эффективно - сохранение всех комментариев в StructuredProperty или использование KeyProperty в модели комментариев?

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

Комментарии не будут получены независимо от их соответствующего сообщения в блоге. (Я подозреваю, что это делает StructuredProperty наиболее предпочтительным.)
Комментарии должны быть отсортированы по дате, рейтингу, автору и т.д. (Подпрограммы в хранилище данных не могут быть проиндексированы, возможно, это может повлиять на производительность?)
Оба сообщения и комментарии в блогах могут быть отредактированы (или даже удалены) после их создания.

Использование StructuredProperty:

from google.appengine.ext import ndb

class Comment(ndb.Model):
    various properties...

class BlogPost(ndb.Model):
    comments = ndb.StructuredProperty(Comment, repeated=True)
    various other properties...

Использование KeyProperty:

from google.appengine.ext import ndb

class BlogPost(ndb.Model):
    various properties...

class Comment(ndb.Model):
    blogPost = ndb.KeyProperty(kind=BlogPost)
    various other properties...

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

Спасибо.

Ответ 1

Я мог ошибаться, но из того, что я понимаю, StructuredProperty - это просто свойство внутри объекта, но с суб-свойствами.

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

Писать будет дешевле каждый тоже. Вам нужно будет прочитать op, чтобы получить BlogPost, и пока вы не обновляете какие-либо индексированные свойства, это будет только один способ записи.

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

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

Оптимизируя стоимость, вы попадаете в стену с максимальным размером сущности 1 МБ. Это ограничит количество комментариев, которые вы можете сохранить в блоге.

Переход с KeyProperty будет довольно дорогим.

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

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

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

Это соотношение затрат и функций.

Ответ 2

Как насчет:

from google.appengine.ext import ndb

class Comment(ndb.Model):
    various properties...

class BlogPost(ndb.Model):
    comments = ndb.KeyProperty(Comment, repeated=True)
    various other properties...

Таким образом, вы можете хранить до 5000 комментариев в блоге (максимальное количество повторяющихся свойств) независимо от размера каждого сообщения в блоге. Вам не нужно будет запрашивать блоги для комментариев, вы можете просто сделать ndb.get_multi(blog_post.comments). И для этой операции вы можете попытаться полагаться на memcache ndb. Конечно, это зависит от вашего случая использования, является ли это хорошим предположением или нет.

Ответ 3

Помните об этом предостережении при использовании повторного StructuredProperty:

Не используйте повторяющиеся свойства, если у вас более 100-1000 значений. (1000, вероятно, уже подталкивает его.) Они не были предназначены для такого использования.

См. ответ Guido в GAE ndb дизайн, производительность и использование повторяющихся свойств.

Таким образом, если вы не можете нанести ограничение на 1 Мб сущности с помощью StructuredProperty, вы можете легко выполнить предложенный максимум 100-1000.