Какую структуру данных использует Google Firebase Firestore для индекса по умолчанию

Мне любопытно, знает ли кто-нибудь или может догадаться, какую структуру данных использует Google Firestore для индексации произвольных документов NoSQL по каждому полю. Я хочу построить что-то подобное, сделав его максимально эффективным.

Некоторая информация о том, как работает их индекс по умолчанию:

  • все поля индексируются по умолчанию, но работает только для поиска равенства, а не диапазона (‹,>)
  • поиск любого диапазона требует дополнительных индексов
  • Источник: https://firebase.google.com/docs/firestore/query-data/indexing

Маловероятно, что это стандартный индекс btree для каждого поля, потому что поиск по диапазону будет работать без добавления требования для другого индекса. Кроме того, если вы добавите новое поле (легко с хранилищем документов), потребуется время, чтобы создать индекс и коллекции с миллиардами элементов.

Одна теория: 1 большой указатель на документ. Индексируйте «field_name: value» для каждого поля в каждом документе. Индекс сопоставляется с идентификаторами документов отсортированного списка, которые содержат эту пару поле / значение. Он сможет выполнять поиск равенства (мое объединение отсортированных идентификаторов документов для каждого требования равенства), но не поиск по диапазону. В основном перевернутый индекс.

Есть ли какие-либо предложения по поводу более эффективных способов реализации подобного паттерна?


person scosman    schedule 19.03.2018    source источник


Ответы (1)


Уточнение, индексы с одним полем поддерживают запросы диапазона / неравенства, составные индексы предназначены для объединения нескольких фильтров полей в одном запросе. Дополнительную информацию о типах индексов см. На этой странице: https://firebase.google.com/docs/firestore/query-data/index-overview.

Каждый индекс поля хранится в собственном диапазоне ключей, при этом смежные области назначаются серверу с независимым масштабированием вычислений и хранилища. Cloud Firestore обрабатывает индексы примерно так же, как Cloud Datastore (но не на 100%).

Вы можете увидеть базовый обзор моей прошлогодней сессии конференции Cloud Next.

person Dan McGrath    schedule 19.03.2018
comment
Думаю, я понимаю, но подтверждаю, что базовый индекс bigtable хранится как что-то вроде Key = builtinIndexPrefix- [kind] - [field] - [value] - [entity-key] (свойства не требуются). Затем для запроса равенства вы используете поиск по префиксу builtinIndexPrefix- [вид] - [поле] - [значение] - чтобы получить отсортированный список ключей объекта? Это сработает и будет довольно быстро, но запрос с множественным равенством потребует повторения нескольких разделов индекса, чтобы найти N ключей, которые есть в каждом. Это было бы довольно быстро, но технически не линейно с размером набора результатов. Я что-то упускаю? - person scosman; 20.03.2018
comment
Обратите внимание на предыдущий комментарий, [entity-key] мог быть в свойстве вместе с ключом, либо работать. Меня больше интересует линейность результатов запроса с несколькими фильтрами, и понимаю ли я структуру данных. Спасибо! - person scosman; 20.03.2018