Эффективность хранилища данных, низкий уровень API
Каждый запрос Cloud Datastore вычисляет свои результаты, используя один или несколько индексов, которые содержат ключи сущностей в последовательности, определенной свойствами индекса, и, необязательно, предки сущностей. Индексы обновляются постепенно, чтобы отразить любые изменения, которые приложение вносит в свои объекты, так что правильные результаты всех запросов доступны без дополнительных вычислений.
Вообще, я хотел бы знать, если
datastore.get(List<Key> listOfKeys);
быстрее или медленнее, чем запрос с подготовленным файлом индекса (с теми же результатами).
Query q = new Query("Kind")(.setFilter(someFilter));
Моя текущая проблема:
Мои данные состоят из слоев и точек. Точки принадлежат только одному уникальному слою и имеют уникальные идентификаторы внутри слоя. Я мог бы загрузить очки несколькими способами:
1) Есть точки со свойством "имя слоя" и запрос с фильтром. - Здесь я не уверен, подготовит ли хранилище данных результаты, потому что, поскольку имя слоя изменяется динамически.
2) Используйте только ключи. Слой должен хранить идентификаторы точек.
KeyFactory.createKey("Layer", "layer name");
KeyFactory.createKey("Point", "layer name"+"x"+"point id");
3) Используйте запросы без фильтров: мне на самом деле не нужен общий вид "Точка", и он может быть более конкретным: вид будет ("имя слоя"+"идентификатор точки") - Каковы затраты на создание большего количества видов? Может ли это быть самым быстрым способом?
Можете ли вы узнать, как работает хранилище данных в деталях?
1 ответ
быстрее или медленнее, чем запрос с подготовленным индексным файлом (с теми же результатами).
По сути, запрос и получение по ключу не гарантируют одинаковые результаты.
Запросы в конечном итоге согласованы, в то время как получение данных по ключам строго согласовано.
Ваша первая задача перед оптимизацией по скорости, вероятно, состоит в том, чтобы убедиться, что вы показываете правильные данные.
Документы хороши для объяснения возможной и сильной согласованности, похоже, у вас есть возможность использовать запрос предка, который может быть строго согласованным. Я также настоятельно рекомендую избегать использования "имени" - которое является динамическим - в качестве имени объекта, это вызовет у вас чрезмерную скорбь.
Изменить: в интересах особой полезности, один вариант для рабочего решения на основе вашего описания будет:
- Присвойте каждому слою уникальный идентификатор (вероятно, uuid), сохраните имя как свойство
- Включите ключ слоя в качестве родительского ключа для каждого точечного объекта
- Используйте запрос предка при извлечении точек для слоя (что строго согласованно)
Альтернативный вариант - хранить точки как внедренные объекты и иметь только одну сущность для всего слоя - это зависит от того, чего вы пытаетесь достичь.