Запросы Geohashes в Firestore - PullRequest
Новая
       41

Запросы Geohashes в Firestore

0 голосов
/ 12 октября 2018

Недавно я играл с Geohashes и Firestore.Мой сценарий todo состоит в том, чтобы иметь коллекцию документов (ресторанов), и каждый ресторан будет иметь список геохешей, который доставляет.

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

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

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

document:{ restaurantName: "aRestaurant", 
deliveryArea: Arraylist<String> }

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

Я впервые играю с базами данных документов и Firestore.Любое руководство будет высоко ценится.

Ответы [ 2 ]

0 голосов
/ 12 октября 2018

firebaser here

Наша оригинальная библиотека GeoFire для базы данных Firebase Realtime решила именно эту проблему, имея отдельный узел верхнего уровня для геохешей.Каждый ключ под этим узлом обычно соответствует ключу фактической сущности в другом узле верхнего уровня.

Так что-то вроде: 

locations
  key1: { g: "sa7ads", l: [ 14.5232, -156.17843 ] },
  key2: { g: "fds347", l: [ -127.172, 167.1324 ] }
restaurants
  key1: { name: "This is the first restaurant", ... },
  key2: { name: "This is the second restaurant", ... },

С этой структурой вы выполняете гео-запрос на/locations, а затем прочитайте дополнительную информацию о каждом ресторане в диапазоне от /restaurants/$key.Это очень хорошо масштабировалось.

Я бы рекомендовал такой же подход с Cloud Firestore.У вас будет две коллекции верхнего уровня: одна с (меньшими) данными о местоположении, а другая с (большими) дополнительными данными о каждом ресторане.Это уменьшает объем данных, которые вы читаете, хотя в конечном итоге вы будете читать больше документов.Вам придется сопоставить эти два значения (пропускная способность и чтение документов) друг с другом.

Несколько месяцев назад я выступил с докладом о выполнении гео-запросов в Cloud Firestore , который может стоитьпроверка.

0 голосов
/ 12 октября 2018

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

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

Максимальный размер документа: 1 МБ (1 048 576 байт)

Как видно, вы ограничены 1 МБ данных в одном документе.Когда мы говорим о сохранении текста, вы можете хранить в значительной степени, но если вы используете сложные объекты, это не вариант.

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

Это хорошее решение.Структура вашей базы данных должна выглядеть следующим образом: 

Firestore-root
   |
   --- restaurants (collection)
        |
        --- restaurantId (document)
                |
                --- geohashes (collection)
                      |
                      --- geohashId (document)
                            |
                            --- //details about the location

Таким образом, запрос, который может позволить вам получить все geohash объекты определенного ресторана, будет работать отлично.

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

Не плохое решение, но вы должны создать дополнительный get() звонок, чтобы получить информацию о ресторане, но даже еслиЭто неплохой вызов, нет проблем с вложенными запросами в Firestore.Нет необходимости в операции OR.

Редактировать: Согласно вашему комментарию, да, вы правы, вы не можете запросить базу данных, чтобы вернуть объекты ресторана, но мы имеем здесьработа вокруг тоже.В этом случае вам следует подумать об увеличении структуры данных, чтобы разрешить обратный поиск, добавив новую коллекцию, подобную этой: 

Firestore-root
   |
   --- geohashes (collection)
         |
         --- geohashId (document)
               |
               --- geohashRestaurants (collection)
                        |
                        --- restaurantId
                               |
                               --- //restaurant details

Этот метод называется denormalization, что, как вы видите, подразумевает дублирование данных.Но вы должны знать, что нет проблем с дублированием данных, когда речь идет о Firebase.Это довольно распространенная практика, и для этого я рекомендую вам посмотреть это видео, Денормализация нормальна для базы данных Firebase .Предназначен для баз данных реального времени Firebase, но тот же принцип применим и к Cloud Firestore.

Когда вы дублируете данные, есть одна вещь, которую нужно иметь в виду.Точно так же, как вы добавляете данные, вы должны поддерживать их.Другими словами, если вы хотите обновить / обнаружить элемент, вы должны делать это в каждом месте, где он существует.

...