Моделирование данных App Engine для комментариев

Я реализую раздел Комментарии для моего текущего приложения. Раздел "Комментарии" можно рассматривать как серию сообщений пользователя на данной странице. Мне интересно, какой дизайн будет наиболее эффективным в нереляционной базе данных (Google App Engine).

Дизайн 1: Сгруппируйте комментарии по groupId и отфильтруйте их результаты.

Comment Entity >> [id, groupId, otherData...]

Запросы для всех комментариев, относящихся к странице, будут выглядеть так:

Select from Comments filter by groupId

Схема 2: Сохраните один ключ для всех комментариев в группе и используйте Саморасширяющийся список, если количество записей превышает 5000 записей.

Comment Entity >> [id, SELid]

Запросы просто выполняют поиск идентификатора / ключа.

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

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

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

Источник

1 ответ

Решение

В случае App Engine и Datastore подход, который вы выберете, зависит главным образом от модели согласованности (сильной и конечной), которая требуется для ваших сущностей. В Google Cloud Datastore есть понятие группы объектов. Группа сущностей (сущность и ее потомки) - это единица с высокой последовательностью, транзакционностью и локальностью, но также накладывает некоторые ограничения (1 запись в секунду).

Соображения

  1. Вам требуются сильные последовательные результаты?
  2. Как часто будут публиковаться комментарии на странице?
  3. Сколько комментариев на страницу вы ожидаете?
  4. У вас есть вариант использования, требующий транзакционного поведения?

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

Дизайн 1

  1. Возможный последовательный поиск по groupId
  2. Проще поддерживать (вам не нужно иметь дело с лимитом 5000 сущностей)

Дизайн 2

  1. Сильный последовательный поиск по entityGroupId
  2. Сложнее поддерживать (вы ДОЛЖНЫ иметь дело с лимитом 5000 сущностей)
  3. Как уже упоминалось, одна сущность, представляющая все сообщения для страницы, может быть узким местом (может быть уменьшено с помощью Memcache)

Я бы, вероятно, пошел с первым подходом, хотя он может напоминать реляционную модель данных.

Источник
Другие вопросы по тегам