Иерархическая структура данных в firebase с поиском геопространственных данных/геохашей; я делаю это правильно?

Question

Цель:
Создайте каталог аэрофотосъемки. Записи, которые должны быть созданы формами AngularJS, но извлекаются просмотром карты, например, буклет.

Голы:
Получить информацию несколько способов: Flight, коллекции, изображения по идентификатору, и изображения по географии

Структура данных:

Collection: { 
    meta: '', 
    Flights: { 
     meta: '', 
     Aerials: { 
      meta:'', 
      geopoint: [lat, lon], 
      geopoly: [[x1,y1], [x2,y2], [x3,y3], [x4,y4]] 
     } 
    } 
} 

Firebase (попытка денормализация) Конструкция:

• /Коллекции/CID
• /Collections_Flights/CID
• /Collections_Images/CID
• /Рейсы/FID
• /Изображения/IID

(я ссылка this stackoverflow)

Вопросы:

1. Если есть 1 миллион изображений делают денормализацию выглядеть адекватными?(каждый полет будет иметь около 80 изображений, каждая коллекция будет в среднем 100 рейсов ... если это важно)

2. Должен ли я использовать GeoHash ?, если так ли GeoHash стать «ID изображения (IID) "для справки firebase/Images/UID?(Или я должен сделать еще один ссылочный пример:/Images_Geo /)

3. Должен ли я использовать GeoHash как этот example?(На большинстве серверов картографирования я могу передать в ограничительной рамке текущего вида пользователя и сервер возвращает все элементы в этом месте. Не знает, как идти об этом с помощью Firebase.)

Answer 1

Если Collection_Flights и Collections_Images содержат только идентификаторы, и если вы всегда извлекаете их одновременно, вы выбираете Collections/$ CID, тогда вам может не понадобиться денормализовать эти индексы.

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

Разделение на полеты/и изображения /, ссылающееся на индекс, является отличным выбором.

Один миллион изображений по 10 тыс. Каждый будет содержать около 10 ГБ данных; важное соображение. Предполагая, что изображения не изменяются в режиме реального времени, вы, вероятно, захотите оптимизировать, найдя для этих изображений чрезвычайно дешевое хранилище (S3, CDN и т. Д.) И просто сохраняя URL-адреса в Firebase, вместо того, чтобы хранить их как данных и оплаты в режиме реального времени тарифов на пропускную способность и хранение этих громоздких статических активов.

Следует ли использовать GeoHash - огромная тема и довольно спорная; есть много альтернатив, как вы уже указывали. Я не думаю, что кто-нибудь может сказать вам ответ на это огромное решение по реализации в формате Q & A (возможно, в качестве главы в учебнике или в дискуссионной теме в соответствующем списке рассылки).