Эффективно ли моделировать схему фида в хранилище данных Google Cloud?

Question

Я использую GCP / App Engine для создания Фида, который возвращает сообщения для данного пользователя в порядке убывания оценки сообщения (измененная временная метка).Сообщения, которые не «видны», возвращаются первыми, а подписчики - по сообщениям, где «увидено» = true.

Когда пользователь создает сообщение, для каждого из его подписчиков создается сущность Ленты (т.е.Модель out inbox)

Приведет ли моя текущая модель индекса к взрывному индексу и / или конфликту в индексе «Score», если много пользователей загружают свой фид одновременно?

index.yaml
indexes:
- kind: "Feed"
  properties:
  - name: "seen" // Boolean
  - name: "uid" // The user this feed belongs to
  - name: "score" // Int timestamp
    direction: desc

// Other entity fields include: authorUid, postId, postType

Фид пользователяполучается:

SELECT postId FROM Feed WHERE uid = abc123 AND seen = false ORDER BY score DESC

---

Будет ли лучше поставить префикс «оценка» с идентификатором пользователя?Повысит ли это производительность индекса оценки? например, оценка = "{буквенно-цифровой идентификатор пользователя} - {метка времени unix}" *

Из документов :

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

Имея всего 4 объекта, я вижу 44 индекса, которые кажутся чрезмерными.

Answer 1

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

Ситуация ухудшается в случае объектов с несколькими свойствами, каждое из которых может принимать несколько значений.Чтобы приспособить такую ​​сущность, индекс должен включать запись для каждой возможной комбинации значений свойств.Пользовательские индексы, которые ссылаются на несколько свойств, каждое из которых имеет несколько значений, могут комбинаторно «взорваться», что потребует большого количества записей для сущности с относительно небольшим числом возможных значений свойств.Такие взрывающиеся индексы могут значительно увеличить размер хранилища объекта в облачном хранилище данных из-за большого количества записей индекса, которые должны быть сохранены.Взрывающиеся индексы также могут легко привести к тому, что сущность превысит число записей индекса или ограничение размера.

44 встроенных индекса - это не что иное, как индексы, созданные для нескольких индексированных свойств ваших четырех объектов (вероятно, ваша модель сущности имеет около 11 проиндексированных свойств).Что нормально.Вы можете уменьшить это число, отменив использование вашей модели и пометив как неиндексированные все свойства, которые вы не планируете использовать в запросах.

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

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

Что бы я сделал:

• объединяет функциональность *Свойства 1032 * и score в одном: значение score 0 может использоваться, чтобы указать, что сообщение еще не было просмотрено, любое другое значение будет указывать метку времени, когда оно было просмотрено.Меньше индексов, меньше обновлений индексов, меньше места для хранения.
• В данном конкретном случае я не стал бы беспокоиться о шардинге:
  • чтение сообщения занимает немного времени, один последователь, прочитавший несколько сообщений, выигралОбычно это происходит достаточно быстро, чтобы обновления индекса для конкретного подписчика представляли серьезную проблему.В редком худшем случае уже прочитанное сообщение может показаться непрочитанным - ИМХО не достаточно плохое для оправдания.
  • Задержки обновления индексов для всех последователей снова - ИМХО, не большая проблема - это может занять немного больше времени длязапись, отображаемая в ленте подписчика