Индексирование только отдельных значений в массивах свойств (вместо индексации каждой комбинации этих значений) в хранилище данных Google

Question

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

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

Я НЕ ссылаюсь, просто не индексируя конкретное свойство.

Бонус Вопрос:

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

Answer 1

Действительно, не должно возникать проблем с созданием встроенного индекса, как указано в приведенном выше ответе. Тем не менее свойства со значениями массива могут вести себя в surprising ways. Для более чем одного фильтра все условия, определяемые фильтрами, должны удовлетворяться хотя бы одним из индивидуальных значений массива, чтобы он соответствовал запросу. Это не применяется в случае фильтров равенства.

Порядок сортировки также необычен: первое значение, указанное в индексе, определяет порядок сортировки объекта.

Answer 2

Я не думаю, что индекс свойства (aka Built-in Index) по свойству Array создает индекс с различными комбинациями значений. Я считаю, что каждое значение в массиве индексируется. Например, если у вас есть Книга с двумя тегами, индекс будет иметь две записи для каждого тега. Добавление другой книги с тремя тегами добавит еще 3 записи в индекс тегов. Этот индекс позволяет запрашивать книги на основе одного тега, а также нескольких тегов.

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

У вас не должно возникнуть проблем со встроенным индексом в категории/теге.

На ваш другой вопрос об объекте индексирования, созданный/измененный метка времени, я вижу, что Best Practices говорит, чтобы избежать индексации такого свойства.

Не индексируйте свойства с монотонно увеличивающимися значениями (например, a Срочная метка NOW()). Поддержание такого индекса может привести к горячей точке , что воздействие Облака Datastore задержка для приложений с высоким чтением и писать цены

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