Когда имеет смысл иметь один и тот же родительский ключ для объектов разных видов?

#google-app-engine #google-cloud-datastore #datastore

# #google-app-engine #google-cloud-хранилище данных #хранилище данных

Вопрос:

Когда имеет смысл иметь один и тот же родительский ключ для объектов разных видов? Если вы создаете объекты, подобные этому:

 Key k1 = KeyFactory.createKey("X", "x1");
String kind_A = "A";
String kind_B = "B";
Entity e1 = new Entity(kind_A, "a1", k1);       
Entity e2 = new Entity(kind_B, "b1", k1);
        
Query q1 = new Query(k1); //{will return a1, b1}
Query q2 = new Query(kind_A, k1); // will return a1
 

Если e1 имеет имена свойств: p1, p2, p3, а e2 имеет имена свойств: p3, p4, p5, и вы создаете запросы, подобные этому:

 Query q3 = new Query(k1).addSort("p3");
Query q4 = new Query(kind_A, k1).addSort("p3");
 

Сколько индексов будет создано для ключа k1 (X, x1)?

Будут ли индексы для каждого типа: p1_A, p2_A, p3_A, p3_B, p4_B, p5_B, плюс общие индексы для каждого свойства из A и B: p1_Shared, p2_Shared, p3_Shared, p4_Shared, p5_Shared?

Как будут сравниваться значения p3, если они имеют разные типы, например, Long и String, или Blob и String / Long ?

Ответ №1:

Я попытаюсь ответить на несколько вопросов, которые вы здесь задали.

Когда имеет смысл иметь один и тот же родительский ключ для объектов разных видов?

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

Сколько индексов будет создано для ключа k1 (X, x1)?

Несколько разделенных индексов не будут созданы, но одни и те же индексы общего назначения будут использоваться для нескольких разных целей. Для группы <parent_key, kind, id> есть неявная запись индекса первичного ключа. Для свойств есть запись <kind, property_name, property_value> . Таким образом, хранилище данных может эффективно выполнять поиск определенного объекта с его полным ключом, включая родительский, оно может выполнять поиск объектов с определенным родительским объектом или может выполнять поиск по имени / значению свойства, когда тип известен.

Запрос q3 = новый запрос (k1).addSort(«p3»);

Этот запрос недопустим. Нет индекса <parent_key, property_name, property_value> , а составной индекс не поддерживается без вида. Это вынудит Datastore выполнять поиск в потенциально очень большом объеме данных.

Это объясняется в документации: «Запрос без вида и без предка извлекает все объекты приложения из режима хранилища данных. Такие запросы без вида не могут включать фильтры или порядок сортировки по значениям свойств «.

Запрос q4 = новый запрос (kind_A, k1).addSort(«p3»);

Этот запрос также недействителен. нет индекса <parent_key, kind, property_name, property_value> . Тем не менее, вы могли бы создать составной индекс для свойства вида «A» «p3», включая предков.

Как будут сравниваться значения p3, если они разных типов?

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

Комментарии:

1. Я часто использую запросы типа <parent_key, kind, property_name, property_value> . Итак, что заставляет их работать, так это то, что я на самом деле объявляю их, включая предков.

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