Στην ανάπτυξη λογισμικού, κάποιος συναντά συχνά ενδιαφέρουσες προκλήσεις, ιδιαίτερα όταν λειτουργεί υπό αυστηρούς περιορισμούς πόρων και προσπαθεί να ελαχιστοποιήσει το κόστος πριν το MVP αποδείξει την αξία του.
Αντίστροφη γεωγραφία
Στα τέλη του 2019, μαζί με μερικούς φίλους, εργάστηκα στην ανάπτυξη μιας μικρής εφαρμογής iOS που ονομάζεταιAWAYΗ εφαρμογή επιτρέπει στους χρήστες να διατηρούν μια λίστα με τις χώρες που έχουν επισκεφθεί και να τη μοιράζονται με άλλους.Η βασική ιδέα πίσω από αυτό είναι ότι οι χρήστες δεν χρειάζεται να εισάγουν χειροκίνητα τις χώρες που έχουν επισκεφθεί.
Εδώ είναι πώς λειτουργεί: Εάν το τηλέφωνό σας περιέχει φωτογραφίες, η εφαρμογή, όταν ζητά και λαμβάνει πρόσβαση στη βιβλιοθήκη μέσων ενημέρωσης, μπορεί να διαβάσει το πλάτος και το μήκος του τόπου όπου κάθε φωτογραφία τραβήχτηκε από τα μεταδεδομένα EXIF.
Αυτή η διαδικασία λήψης μιας διεύθυνσης (σε αυτή την περίπτωση, το όνομα της χώρας) από τις γεωγραφικές συντεταγμένες ονομάζεταιreverse geocodingΓια αναφορά, το αντίστροφο αυτής της διαδικασίας - η απόκτηση γεωγραφικών συντεταγμένων από μια διεύθυνση κειμένου - είναι γνωστό ως προοδευτική γεωκωδικοποίηση.
Λύσεις τρίτων
Κατά την ανάπτυξη του MVP μας, ξεκινήσαμε με την απλούστερη διαθέσιμη και χρησιμοποιούμενη επιλογήΗ προεπιλεγμένη λύση της AppleΗ εφαρμογή λειτούργησε, οι χώρες προστέθηκαν αυτόματα στη λίστα και αρχίσαμε να προσελκύουμε τους πρώτους χρήστες μας.
Ωστόσο, σύντομα συναντήσαμε σημαντικούς περιορισμούς. η λύση της Apple ήταν πολύ αργή λόγω των αυστηρών ορίων τιμών στις αιτήσεις δικτύου για το API της και δεν σχεδιάστηκε για την παρτίδα επεξεργασίας συντεταγμένων. Δεδομένου ότι οι βιβλιοθήκες μέσων χρήστη συχνά περιείχαν χιλιάδες φωτογραφίες, η διαδικασία προσδιορισμού των χωρών ήταν εξαιρετικά χρονοβόρα, μερικές φορές χρειάζονταν πάνω από 30 λεπτά για να ολοκληρωθούν.
Τέτοιες μεγάλες περιόδους αναμονής αναπόφευκτα υπονόμευαν την ιογένεια της εφαρμογής μας. Αντί να λαμβάνουν αμέσως μια λίστα με τις χώρες που επισκέφθηκαν και να τη μοιράζονται στο Instagram ή το Facebook, οι χρήστες απλά έφυγαν χωρίς να περιμένουν να ολοκληρωθεί η διαδικασία.
Δεν μπορούσαμε να βρούμε μια πιο κατάλληλη λύση τρίτου μέρους.google,Το Mapbox, και άλλα παρόμοια API είτε είχαν τα ίδια προβλήματα με την Apple - είναι ακατάλληλα για την επεξεργασία παρτίδων και δεν προσφέρουν κανένα πλεονέκτημα εξοικονόμησης χρόνου - ή θα ήταν απίστευτα ακριβά δεδομένου του όγκου των συντεταγμένων που χρειαζόμασταν να χειριστούμε.Υποψηφιότηταθα ήταν πολύ ακριβό λόγω του κόστους ενοικίασης ενός κατάλληλου διακομιστή.
Χωρίς προσιτές επιλογές off-the-shelf διαθέσιμες, εγώ, υπεύθυνος για το backend, άρχισα να χτίζω το δικό μας API.
Γεωργίου
Πριν από αυτό το έργο, δεν είχα καμία εμπειρία εργασίας με γεωχωρικά δεδομένα, οπότε έπρεπε να μάθω τα πάντα καθώς αναπτύξαμε την εφαρμογή.
Το πρώτο πράγμα που χρειαζόμουν για την εφαρμογή ήταν πληροφορίες σχετικά με τα σύνορα των χωρών για να ταιριάζουν οι συντεταγμένες.GeoJSON.
Το GeoJSON είναι ένα πρότυπο αρχείο JSON με μια συγκεκριμένη δομή που σας επιτρέπει να περιγράψετε σημεία, γραμμές και σχήματα αυθαίρετης πολυπλοκότητας.
Για παράδειγμα, ας υποθέσουμε ότι θέλουμε να αποθηκεύσουμε πληροφορίες σχετικά με την επικράτεια της Ιταλίας.Feature
Τα σύνορα της χώρας θα περιγραφούν εντός ενόςMultiPolygon
Κάθε πολυγόνο αποτελείται από μία ή περισσότερες σειρές ζευγαριών συντεταγμένων, όπου το πρώτο και το τελευταίο ζευγάρι συντεταγμένων[lon, lat]
Το σχήμα που περιγράφεται στην πρώτη σειρά θα προστεθεί στη συνολική γεωγραφική ζώνη, στην περίπτωση αυτή, η ίδια η Ιταλία, μαζί με το νησί της Σαρδηνίας (το νησί θα περιγραφεί σε ξεχωριστό πολύγωνο).
Οποιαδήποτε μεταγενέστερη σειρά εντός του πολυγώνου είναι προαιρετική και αντιπροσωπεύει αποκλεισμένες περιοχές. Αυτό θα είναι απαραίτητο για να αποκλειστούν εδάφη όπως οι πόλεις-κράτη πλήρως περικυκλωμένες από την Ιταλία, όπως το Σαν Μαρίνο και το Βατικανό. Οι συντεταγμένες σε αυτές τις σειρές πρέπει να αναγράφονται ανά ώρα. Όσο περισσότερα σημεία προσδιορίζουμε, τόσο πιο ακριβή θα είναι τα σύνορα της χώρας.
Μεταδεδομένα, όπως το όνομα της χώρας, μπορούν να συμπεριληφθούν σε έναproperties
το αντικείμενο.
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"geometry": {
"type": "MultiPolygon",
"coordinates": [
[ // Polygon
// Exterior ring, Italy
[ [20, 35],[10, 30],[10, 10], ... ,[45, 20],[20, 35]],
// Interior "excluding" ring, San-Marino
[ [30, 20],[20, 15],[20, 25], ... ,[30, 20]]
],
[ // Polygon
// Exterior ring, Sardinia
[ [40, 40],[20, 45], [45, 30], ... ,[40, 40]]
]
]
},
"properties": {
"country": "Italy",
}
}
]
}
Προετοιμασία γεωγραφικού
Για να δημιουργήσω έναν παγκόσμιο χάρτη, έπρεπε να δημιουργήσω τα πιο ακριβή αρχεία GeoJSON με τις συντεταγμένες όλων των εθνικών συνόρων, γεγονός που αποδείχθηκε εκπληκτικά δύσκολο.
Έχω βασιστεί σε μια ποικιλία ανοιχτών πηγών, συμπεριλαμβανομένων των συγκεντρωτικών δεδομένων απόΩκεανογραφικά Ινστιτούτα,Πακέτα από το npmjs.org, και ανοιχτά γεωγραφικά δεδομένα απόΥποψηφιότηταΜερικές φορές τα σύνορα επικαλύπτονταν, ιδιαίτερα σε περιπτώσεις πολιτικών διαφορών μεταξύ των περιφερειών. Σε άλλες περιπτώσεις, ήταν διαθέσιμα μόνο δεδομένα που περιλάμβαναν χωρικά ύδατα, τα οποία δεν ήταν κατάλληλα για τις ανάγκες μας.Το Ναυτικό Ινστιτούτο της ΦλάνδραςΜερικές φορές, η ανάλυση (ο αριθμός των συντεταγμένων) ήταν πολύ χαμηλή για αξιόπιστη γεωκωδικοποίηση, απαιτώντας από μένα να αναζητήσω εναλλακτικές λύσεις.
Οι απαιτήσεις της εφαρμογής ήταν αρκετά απαιτητικές: χρειαζόμασταν ακριβή, μη επικαλυπτόμενα όρια για κάθε γεωγραφική περιοχή σε υψηλή ανάλυση χωρίς εδαφικά ύδατα (για εμφάνιση στον χάρτη εντός της εφαρμογής) και όρια χαμηλότερης ανάλυσης, συμπεριλαμβανομένων των εδαφικών υδάτων (για ταχύτερη και πιο αποτελεσματική γεωκωδικοποίηση, ειδικά για φωτογραφίες που τραβήχτηκαν σε πλοία κοντά στις ακτές - ένα πρόβλημα που ανακαλύψαμε όταν εργαζόμασταν με λύσεις τρίτων).
Μετά από μια εβδομάδα και μισή λεπτομερούς εργασίας, κατάφερα να δημιουργήσω δύο αρχεία GeoJSON υψηλής ανάλυσης.countries_maritime.json
περιγράφει τα σύνορα όλων των χωρών, συμπεριλαμβανομένων των χωρικών τους υδάτων, ενώ το άλλο,countries_coastline.json
Κάθε αρχείο ήταν αρκετές εκατοντάδες megabytes σε μέγεθος, και στο τέλος, ένιωσα σαν να είχα επισκεφθεί προσωπικά κάθε γωνιά του κόσμου.
Φωτιά
Όταν ξεκίνησε, η ενημερωμένη έκδοση της εφαρμογής συγκέντρωσε όλες τις προηγουμένως μη επεξεργασμένες συντεταγμένες φωτογραφιών από τη βιβλιοθήκη μέσων ενημέρωσης του χρήστη σε παρτίδες 10.000 και τις έστειλε στο backend μου σε πολλαπλά αιτήματα.
Το backend, που χτίστηκε στο Node.js και φιλοξενήθηκε στο AWS, φορτώθηκε τοcountries_maritime.json
αρχείο στη μνήμη κατά την αρχικοποίηση. Όταν ήρθε ένα αίτημα με μια παρτίδα συντεταγμένων, χρησιμοποίησε τοΠολυγώνια Προοπτικήβιβλιοθήκη για να ταιριάζουν οι συντεταγμένες στις αντίστοιχες περιοχές από το αρχείο, το οποίο περιείχε 250 χώρες.
Η λίστα των συντεταγμένων υποβλήθηκε σε αυστηρή επικύρωση, καθώς, όπως αποδείχθηκε, ορισμένες συντεταγμένες ήταν εκτός του επιτρεπόμενου εύρους. Απορρίψαμε επίσης συντεταγμένες με υψόμετρα άνω των 8.850 μέτρων (λίγο πάνω από την κορυφή του Έβερεστ) για να αποφύγουμε την καταμέτρηση των τυπικών φωτογραφιών με το στυλ του Instagram των φτερών αεροσκαφών (τα αεροπλάνα συνήθως πετούν σε υψόμετρα άνω των 9.000 μέτρων).
Όταν βρεθεί ένας αγώνας, το αναγνωριστικό της χώρας από τοproperty
Μετά την επεξεργασία όλων των συντεταγμένων, η λίστα των καταγεγραμμένων αναγνωριστικών αποδιπλασιάστηκε, προστέθηκε στη λίστα των επισκέψεων του χρήστη και επέστρεψε στον πελάτη για να συγχρονίσει την εφαρμογή με τη βάση δεδομένων backend.
Μετά τη μετάβαση στην προσαρμοσμένη λύση μας, η κορυφήΗ ταχύτητα επεξεργασίας έφτασε τις 10.000 συντεταγμένες ανά δευτερόλεπτο(σε συνθετικές δοκιμές), ο μέσος χρόνος για την επεξεργασία της βιβλιοθήκης μέσων ενημέρωσης ενός χρήστη μειώθηκε σε 20-25 δευτερόλεπτα (από την εγγραφή του χρήστη μέχρι την επιστροφή της λίστας των χωρών που επισκέφθηκε), καιΟ μέσος αριθμός των χωρών που προστέθηκαν αυξήθηκε κατά 225% ανά χρήστηΧάρη στην ακριβέστερη γεωγραφία.
Γεωγραφική Διοίκηση
Καθώς η εφαρμογή συνέχισε να αναπτύσσεται, οι χρήστες άρχισαν να υποβάλλουν αιτήματα χαρακτηριστικών.Ένα από τα πιο συχνά αιτήματα ήταν η προσθήκη αυτόματης αναγνώρισης για περιοχές και μεγάλες πόλεις σε κάθε χώρα.
Η συλλογή δεδομένων υψηλής ποιότητας για τα σύνορα 250 χωρών ήταν ήδη δύσκολη.Η προοπτική συλλογής παρόμοιων δεδομένων για χιλιάδες περιφέρειες και πόλεις ήταν ακόμη πιο τρομακτική.
Για να αντιμετωπιστεί αυτό, μεταφέρω τις περιοχές από το αρχείο JSON σε έναν πίνακα Postgres και ανέπτυξα μια διεπαφή διαχείρισης για τη διαχείριση γεωγραφικών ζωνών.Επιπλέον, ενσωμάτωσα τον πίνακα διαχείρισης με διάφορα εξωτερικά API για να αυτοματοποιήσω τη δημιουργία λιστών για περιοχές και πόλεις με βάση τις μητρικές χώρες τους.
Το πρώτο πρόβλημα που αντιμετώπισα ήταν η εγγενής πολυπλοκότητα των δεδομένων γεωγραφικής περιοχής. Δεν υπάρχει καθολική σαφής διάκριση μεταξύ περιφερειών και πόλεων, και διαφορετικές χώρες έχουν διαφορετικά επίπεδα διοικητικών διαχωρισμών.ΠΕΡΙΠΤΩΣΗ.ΔΕ, χρησιμοποιώντας συνθήκες και επαναλαμβανόμενες κλήσεις για να φιλτράρετε με διοικητικά κέντρα, μέγεθος πληθυσμού και εσωτερικές σχέσεις. Αυτό περιελάμβανε επίσης τη μελέτη του πώς να διαιρέσετε και να οργανώσετε γεωγραφικούς κόμβους, τις σχέσεις τους και τις δομές τους και να διορθώσετε μερικά εσφαλμένα δεδομένα.
Η δεύτερη πρόκληση προέκυψε όταν εργάστηκα με τις πηγές συντεταγμένων για τα όρια της περιοχής. Μετά την ανάκτηση λιστών osmId για τις περιοχές και τις πόλεις, έπρεπε να εξαγάγω τη γεωμετρία των συνόρων τους.Ετικέτα: openstreetmap.orgκαι σχεδόν αδιευκρίνιστηΕτικέτα: openstreetmap.frΑυτές οι πηγές ήταν ελλιπείς, οπότε έπρεπε να στείλω πολλαπλά αιτήματα και να συγκρίνω τα αποτελέσματά τους, επιλέγοντας το καλύτερο ταιριάζει με βάση την ποιότητα των επιστρεφόμενων δεδομένων.
Παρά την έλλειψη τεκμηρίωσης, τις σύνθετες σχέσεις δεδομένων και τις ασυνέπειες στις πηγές, κατάφερα να δημιουργήσω μια σταθερή λύση.Η διεπαφή του πίνακα διαχείρισης τώρα επιτρέπει την αυτόματη φόρτωση των καταλόγων πόλεων και περιοχών για οποιαδήποτε χώρα με λίγα μόνο κλικ, συμπεριλαμβανομένων των μεταδεδομένων τους και των καλύτερων διαθέσιμων γεωμετρικών ορίων.
Για την αντιμετώπιση συχνών προβλημάτων με τα δεδομένα GeoJSON, ανέπτυξα ακόμη και έναν ενσωματωμένο επεξεργαστή που επιτρέπει τη διαίρεση, τη συγχώνευση, την αφαίρεση και τη σχεδίαση ελλείποντων γεωμετρικών ορίων.
Όλα αυτά τα εργαλεία μας επέτρεψαν, με μια ομάδα μόλις δύο ατόμων, να δημιουργήσουμε μια βάση δεδομένων περιοχών και πόλεων που ήμασταν υπερήφανοι να παρουσιάσουμε στους χρήστες μέσα σε ενάμιση μήνα.
Επί του παρόντος, η εφαρμογή υποστηρίζει 3.134 περιοχές και 28.083 πόλεις, το καθένα με ακριβή όρια, και παρακολουθεί τον αριθμό των χρηστών που έχουν επισκεφθεί.
Ελαχιστοποίηση γεωγραφικών δεδομένων
Η διαχείριση 31.467 εδαφών με το Node.js έγινε ανεξέλεγκτη λόγω των περιορισμών της απόδοσης και των πόρων ήδη στο βήμα της αρχικοποίησης του ευρετηρίου.
Όπως ανέφερα νωρίτερα, τα δεδομένα που απαιτούνται για την εμφάνιση εφαρμογών και τη γεωκωδικοποίηση είχαν πολύ διαφορετικές απαιτήσεις: ενώ η προετοιμασία των πλακών χάρτη για την αναπαραγωγή στην εφαρμογή θα μπορούσε να αντέξει να διαρκέσει για λεπτά, η γεωκωδικοποίηση ήταν εξαιρετικά ευαίσθητη στους όγκους δεδομένων, με την ταχύτητά της να συνδέεται άμεσα με τον αριθμό των συντεταγμένων στα εδαφικά σύνορα.
Έχω πειραματιστεί με διάφορους αλγόριθμους για να απλοποιήσω τις αλυσίδες συντεταγμένων των πολυγώνων.
Η πρώτη προσέγγιση ήταν ηΡάμερ-Ντάγκλας ΠούκερΗ προσέγγισή του ήταν ασταθής, οδηγώντας σε ασυνέπειες στα κοινά σύνορα μεταξύ διαφορετικών αρχείων GeoJSON, και επίσης προκάλεσε την απώλεια μικρότερων λεπτομερειών, όπως νησιά.
Τελικά ,Δημιούργησα τη δική μου εφαρμογή(που δημοσιεύεται ως πακέτο npm) με βάση τοΚεφαλογιάννηςWhyattΟι υφιστάμενες εφαρμογές αυτού του αλγορίθμου θα μπορούσαν να εφαρμοστούν μόνο σε συγκεκριμένα μέρη μιας δομής GeoJSON, η οποία έλυσε το πρόβλημα της σταθερότητας των αποτελεσμάτων αλλά εξακολουθούσε να προκαλεί σημαντική υποβάθμιση των συνόρων και την απώλεια μικρών λεπτομερειών.Καλημέρα(με τη γωνία μεταξύ των τριών γειτονικών συντεταγμένων ως στοιχείο σωρού) και την επεξεργάστηκα ως μία καμπύλη με πρόσθετη λογική για τη διατήρηση κοινών σημείων.
Δημιούργησα τη δική μου εφαρμογήΕκτός από τη μείωση των όγκων δεδομένων, αυτή η αναδιάρθρωση των αρχείων GeoJSON βοήθησε να αποκαλυφθούν πολυάριθμα σφάλματα και συγκρούσεις στα δεδομένα:
- Ανεξάρτητα από τις συντεταγμένες.
- Συγκρουόμενες σειρές λόγω λανθασμένης περιστροφής συντεταγμένων.
- Κενά συντεταγμένα ράφια.
- Η υπερβολική ρινίτιδα.
- Αδικαιολόγητη ακρίβεια σε συντεταγμένες.
Έχω αυτοματοποιήσει επιτυχώς την επικύρωση και τη διόρθωση αυτών των σφαλμάτων, εν μέρει χρησιμοποιώντας υπάρχοντα εργαλεία όπως:Πολυγώνια Κλιπ,Ετικέτες geojsonhint,Ετικέτες geojson-rewind,και @mapbox/geojson-extentΑυτές περιλαμβάνουν τη συγχώνευση ξεχωριστών πολυγώνων σε συλλογές πολλαπλών πολυγώνων και γεωμετρίας, τη μείωση της ανάλυσης των συντεταγμένων στο απαιτούμενο επίπεδο, τη διόρθωση της κατεύθυνσης των συντεταγμένων και την αφαίρεση κενών σειρών.
Ως αποτέλεσμα, πέτυχα μια σημαντική βελτίωση στην απόδοση της επεξεργασίας γεωγραφικών δεδομένων.Επιπλέον, η σταθερότητα του αλγορίθμου μου έλυσε το ζήτημα των ακατάλληλων απλουστευμένων συνόρων μεταξύ γειτονικών περιοχών στο χάρτη.
Μικροεξυπηρέτηση
Παρά τη μείωση του υπολογιστικού φόρτου μέσω της απλούστευσης των γεωδεδομένων, έγινε σαφές ότι το Node.js δεν ήταν σίγουρα η ιδανική λύση για τις ανάγκες μας.ΤαχυδρομικάΜετά από εκτεταμένη έρευνα, συμπεριλαμβανομένων των μετρήσεων απόδοσης και κατανάλωσης πόρων, επέλεξα την τελευταία – μια απλή μικροεπιχείρηση που χτίστηκε με το Go.
Η αρχιτεκτονική μικροεξυπηρέτησης έχει σχεδιαστεί για να μεγιστοποιεί την ταχύτητα επεξεργασίας ζεύγους συντεταγμένων ελαχιστοποιώντας παράλληλα τις περιττές λειτουργίες.
Κατά την πρώτη εκτέλεσή του, η μικροεξυπηρέτηση συνδέεται με το PostgreSQL και ανακτά όλα τα σχετικά δεδομένα GeoJSON σε παρτίδες 100 αντικειμένων. Αυτά τα δεδομένα αναλύονται σε δομές, καθένα από τα οποία περιέχει ένα πολύγωνο και το αντίστοιχο αναγνωριστικό εδάφους.
Μόλις δημιουργηθεί η δομή, έναR-ΔέντροΑυτός ο τύπος δέντρου χρησιμοποιείται συχνά για τη δημιουργία δεικτών αναζήτησης για πολυδιάστατα δεδομένα, όπως πολυγώνια. Το δέντρο επιτρέπει αναζητήσεις λογαριθμικού χρόνου για το μικρότερο οριοθετημένο ορθογώνιο που περιλαμβάνει το πολυγώνιο στόχου.
Μετά την κατασκευή του δέντρου, η μικροεξυπηρέτηση εισέρχεται σε κατάσταση ακρόασης, περιμένοντας εισερχόμενα αιτήματα.
Όταν λαμβάνεται ένα αίτημα, το οποίο αποτελείται από ζεύγη συντεταγμένων[lat, lon]
Το αποτέλεσμα είναι ένα σύνολο μοναδικών εδαφικών αναγνωριστικών που περιέχουν τις καθορισμένες συντεταγμένες.
Κάθε συντεταγμένη υποβάλλεται πρώτα σε αναζήτηση μέσω του δέντρου R. Αυτή η αναζήτηση μπορεί να επιστρέψει ένα ορθογώνιο που περιέχει ένα πολυγώνιο, το οποίο ενδεχομένως να περιλαμβάνει τον συντεταγμένο.Ο αλγόριθμος Ray-Castingχρησιμοποιείται. Αυτός ο αλγόριθμος λειτουργεί σε γραμμικό χρόνο, καθιστώντας το το πιο έντονο μέρος της διαδικασίας. Ωστόσο, πριν από την εκτέλεση του ελέγχου εκπομπής ακτίνων, επαληθεύω αν ο αναγνωριστής εδάφους για το πολύγωνο έχει ήδη βρεθεί κατά την επεξεργασία άλλων συντεταγμένων στο αίτημα. Εάν υπάρχει, ο έλεγχος εκπομπής ακτίνων παραλείπεται, μειώνοντας σημαντικά τον χρόνο επεξεργασίας της υπηρεσίας.
Αφού όλα τα νήματα ολοκληρώσουν τη δουλειά τους, το σύνολο των αναγνωριστικών επιστρέφει στο στρώμα Node.js. Παρακάτω, προσπάθησα να αντιπροσωπεύσω την αρχιτεκτονική στο ακόλουθο διάγραμμα:
Η όλη διαδικασία αναζήτησης, εκτός από τη συγκεκριμένη βελτιστοποίηση για να παραλείψετε επαναλαμβανόμενους ελέγχους ακτινοβολίας, αντικατοπτρίζει προσεκτικά τον τρόπο με τον οποίο το PostGIS χειρίζεται μια παρόμοια εργασία όταν χρησιμοποιείΔώροτων δεικτών.
Χρησιμοποιώντας το API που χτίστηκε γύρω από την υπηρεσία μικροεξυπηρέτησης Go,Έχουμε την ικανότητα να επεξεργαζόμαστε περίπου 100.000 ζεύγη συντεταγμένων ανά δευτερόλεπτοΣυγκριτικά, η προηγούμενη λύση Node.js διαχειριζόταν περίπου 10.000 ζεύγη συντεταγμένων για 250 ζώνες, συμπεριλαμβανομένης της ανάλυσης των αιτημάτων δικτύου και των λειτουργιών backend.
Αυτή η σημαντική βελτίωση στην ταχύτητα επεξεργασίας επέτρεψε πολύ ταχύτερη σύνταξη των καταλόγων χωρών που επισκέφθηκαν οι χρήστες.Επιπλέον, με την υποστήριξη για την αναγνώριση περιοχών και πόλεων,Η εφαρμογή είδε 160% αύξηση των ενεργών χρηστών και 107% αύξηση της κοινής χρήσης χρηστώνΤα αποτελέσματά τους.
Η λύση παραμένει σε χρήση σήμερα και συνεχίζει να χειρίζεται έναν αυξανόμενο όγκο αιτημάτων και γεωγραφικές ζώνες αποτελεσματικά.Είναι αξιοσημείωτο ότι ολόκληρο το backend λειτουργεί με λιγότερο από ένα gigabyte μνήμης RAM, παρουσιάζοντας τη βελτιστοποιημένη χρήση πόρων.