GeoFire 4 соблюдает ключевой размер снимка и выставление счетов - PullRequest
Новая
       73

GeoFire 4 соблюдает ключевой размер снимка и выставление счетов

1 голос
/ 15 февраля 2020

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

Ниже кода, который я использую для введенного ключа: 

/**

            How observers work for goquery
 https://stackoverflow.com/questions/45179245/geofire-swift-3-cant-stop-observing
 */

var itemsProcessed = 0
self.circleQuery!.observe(.keyEntered, with: { (key: String!, location: CLLocation!) in

    itemsProcessed = itemsProcessed + 1
NSLog("Controller | initiateGeoQuery | processed key \(itemsProcessed) with value: '\(key)', it has entered the search area and is at location '\(location)' , cirecleQuery has center: \(self.circleQuery!.center) , and radius: \(self.circleQuery!.radius)")


    NSLog("AEViewController waiting 60 seconds before next key entered")
    sleep(60)

В этом тестовом примере у меня есть 320 узлов вне радиуса, расположенных в Китае, и 2 узла в пределах диапазона, я нахожусь в ЕС.

Я получаю следующий вывод: 

2020-02-15 15:01:55.198665+0000 Renal2[14181:706800] Controller | initiateGeoQuery | processed key 1 with value: 'Optional("adROWaUdK5gd6JKAfMW8DzfXpJB3")', it has entered the search area and is at location 'Optional(<xx.34939780,yy.23826435> +/- 0.00m (speed -1.00 mps / course -1.00) @ 15/02/2020, 15:01:55 Greenwich Mean Time)' , cirecleQuery has center: <xx.34939292,yy.23826781> +/- 65.00m (speed -1.00 mps / course -1.00) @ 15/02/2020, 15:01:54 Greenwich Mean Time , and radius: 50.0
2020-02-15 15:02:55.201683+0000 Renal2[14181:706800] Controller | initiateGeoQuery | processed key 2 with value: 'Optional("9fzIKheb8Ubvmu1tCA9V0uw0DOj1")', it has entered the search area and is at location 'Optional(<xx.34959316,yy.23812573> +/- 0.00m (speed -1.00 mps / course -1.00) @ 15/02/2020, 15:01:55 Greenwich Mean Time)' , cirecleQuery has center: <xx.34939292,yy.23826781> +/- 65.00m (speed -1.00 mps / course -1.00) @ 15/02/2020, 15:01:54 Greenwich Mean Time , and radius: 50.0

На профилировщике Firebase у меня есть, для первого введенного ключа: 

┌────────────────────────────────────────────────┬───────────┬───────┬──────────┐
│ Path                                           │ Total     │ Count │ Average  │
├────────────────────────────────────────────────┼───────────┼───────┼──────────┤
│ /GeoFire                                       │ 118.72 kB │ 4     │ 29.68 kB │

Для второго: 

┌──────┬───────┬───────┬─────────┐
│ Path │ Total │ Count │ Average │
└──────┴───────┴───────┴─────────┘

Это вполне ожидаемо, и также соответствует GeoFire + Swift 3 can не прекращайте наблюдать

Что неожиданно, так это то, что, если я выполню тот же тест, используя 150 ключей вне радиуса вместо 320, пропускная способность будет такой, как указано ниже: Теперь, рассматривая реальный сценарий в современной бизнес-модели, где приложения являются глобальными, нередко, скажем, 1 000 000 ключей распространяются по всему миру. Поскольку луч в моем случае составляет около 50 км, реалистичный сценарий c состоит в том, чтобы в луче было около 20/30 ключей.

Должен ли я платить за 1 000 000 x 0,36 КБ, почти 370 MB? каждый сеанс?

Конечно, я здесь что-то не так делаю, в блоге ниже

https://firebase.googleblog.com/2014/06/geofire-20.html

Я вижу:

GeoFire хорошо разбирается в том, как он ищет ключи в запросе. Для этого не нужно загружать все данные GeoFire в память. Если ваш пользователь ищет магазины велосипедов в Сан-Франциско, GeoFire не будет загружать данные для местоположений в Нью-Йорке только для того, чтобы понять, что они находятся на противоположной стороне страны. Он проверяет только те места, которые на самом деле находятся поблизости. Это делает ваше приложение легким и отзывчивым, независимо от того, насколько велик ваш набор данных.

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

Спасибо большое.

...