For et stigende antal applikationer er sporing af placering vigtig. En social applikation forbinder muligvis brugere baseret på placering. En gæstfriheds- eller rejseapplikation bruger muligvis brugerens placering til at påpege interessante seværdigheder eller give tilpassede rejseplaner. En sensorapplikation kan gemme og analysere data, der både er geospatiale og tidsserier, for at udløse en handling som detektering af mønstre, outliers og anomalier.
Efterhånden som geospatial teknologi modnes, udvikler placeringsbaserede applikationer sig fra primært at kortlægge applikationer til sofistikerede, banebrydende programmer, der behandler og analyserer millioner af datapunkter fra mobile brugere, sensornetværk, IoT-enheder og andre kilder. Verden er i konstant bevægelse, og vores apps begynder at fange.
Placeringsdata præsenterer en interessant udfordring for udvikleren, fordi det er nødvendigt at overveje længdegrad (x), breddegrad (y) og undertiden endda højde (z), når man spørger dem eller udfører beregninger af position og afstand. Lokationsdataens flerdimensionelle natur kræver optimerede mekanismer til at behandle dem - at behandle dem som blot heltal er meget ineffektivt. Hvis databasen, hvad enten det er en RDBMS eller en NoSQL-butik, mangler mulighederne for håndtering af geospatiale data, skal applikationsprogrammerere gøre det ekstra arbejde med at forbehandle dataene, eller de er nødt til at opbygge logik, der behandler dataene som geospatiale.
Behandling af geospatiale data er også en realtids big data-udfordring. Applikationer, der bruger og administrerer geospatiale data, skal med minimal forsinkelse tjene et stort antal anmodninger om placering ("Hvor er du?"), Opdateringer til placering ("Jeg er her") og søger efter data efter sted ("Hvem eller hvad er der i nærheden? ”).
Enkle læser (hent placering) og skriv (opdater placering) er udfordrende i skala. Søgning efter yderligere forbindelser udfordringen. Nøglen til at opfylde ovenstående krav er at opretholde effektive indekser til dataene. Et effektivt indeks er et, der kan lette hurtige søgninger og ikke er dyrt at vedligeholde (med hensyn til hukommelse og computerkraft).
Redis egenskaber og ydeevne gør det til en fremragende pasform til placeringsbaserede applikationer. Alt, hvad der manglede, var oprindelig understøttelse af geolokaliseringsdata. Fra og med version 3.2 leveres Redis imidlertid med indbygget geospatial indeksering. Udviklere af applikationer, der er afhængige af geospatiale data, kan nu se til Redis for at gemme, behandle og analysere det - med al den hastighed og enkelhed, de er kommet til forventer af Redis i andre applikationer.
Kort introduktion til Redis
Redis er en datastrukturbutik i hukommelsen, der ofte bruges som en database, en cache og en meddelelsesmægler. Datastrukturer i Redis er som Lego-byggesten, hvilket hjælper udviklere med at opnå specifik funktionalitet med minimal kompleksitet. Redis minimerer også netværksomkostninger og latens, fordi operationer udføres ekstremt effektivt i hukommelsen lige ved siden af, hvor dataene er gemt.
Redis-datastrukturer inkluderer bindestreg, sæt, sorterede sæt, lister, strenge, bitmaps og HyperLogLogs. Disse er meget optimerede, hver med specialkommandoer, der hjælper dig med at udføre kompleks funktionalitet med meget lidt kode. Disse datastrukturer gør Redis ekstremt kraftfuld og giver Redis-baserede applikationer mulighed for at håndtere ekstreme mængder operationer med meget lav ventetid.
Sorterede sæt er særligt vigtige. Unikt for Redis, de tilføjer en ordnet visning til medlemmerne sorteret efter score. Sorterede sæt er enormt fordelagtige til behandling af data som bud, rangeringer, brugerpoint og tidsstempler - så analyser kan udføres et par størrelsesordener hurtigere sammenlignet med almindelig nøgle / værdi eller NoSQL-butikker.
Geospatial indeksering implementeres i Redis ved hjælp af sorterede sæt som den underliggende datastruktur, men med on-the-fly kodning og afkodning af placeringsdata og nye API'er. Dette betyder, at placeringsspecifik indeksering, søgning og sortering alle kan downloades til Redis med meget få kodelinjer og meget lille indsats ved hjælp af indbyggede kommandoer som GEOADD, GEODIST, GEORADIUSog GEORADIUSBYMEMBER.
Når du kombinerer denne geospatiale support med andre Redis-muligheder, bliver nogle interessante funktioner ekstremt enkle at implementere. For eksempel ved at smelte de nye Geo Sets og PubSub er det næsten trivielt at oprette et sporingssystem i realtid, hvor hver opdatering til et medlems stilling sendes til alle interesserede parter (tænk på en løbende eller cykelgruppe, hvor du vil at spore gruppemedlemmers placeringer i realtid).
Geosættet
Geo Set er grundlaget for at arbejde med geospatiale data i Redis - det er en datastruktur, der er specialiseret til styring af geospatiale indekser. Hvert Geo-sæt består af et eller flere medlemmer, hvor hvert medlem består af en unik identifikator og et længdegrad / breddegradspar. I lighed med alle datastrukturer i Redis manipuleres og forespørges Geo Sets ved hjælp af et delsæt af brugervenlige og på samme tid yderst optimale kommandoer.
Internt implementeres Geo Sets med et sorteret sæt. Sorterede sæt udviser en god balance mellem tid og tid ved at indtage en lineær mængde RAM, samtidig med at de giver logaritmisk computerkompleksitet til de fleste operationer.
Oprettelse og tilføjelse til indekset
Redis-kommandoen til at tilføje medlemmer til et geospatialt indeks kaldes GEOADD. Denne kommando bruges både til oprettelse af nye sæt og til tilføjelse af medlemmer. Følgende eksempel, illustreret fra kommandolinjen og Node Redis-klienten, viser dets anvendelse.
Redis kommandoeksempel:
GEOADD placeringer 10.9971645 45.4435245 Romeo
Node Redis-eksempel:
redis.geoadd ('placeringer', '10 .9971645 ', '45 .4435245', 'Romeo');
Ovenstående fortæller Redis at bruge et Geo-sæt kaldet placeringer til lagring af koordinaterne for det medlem, der hedder Romeo. Hvis placeringsdatastrukturen ikke findes, oprettes den først af Redis. Det nye medlem føjes til indekset, hvis og kun hvis det ikke findes i sættet.
Det er også muligt at tilføje flere medlemmer til indekset med et enkelt opkald til GEOADD. Ved batching af flere operationer i en enkelt kommando reducerer denne form for påkaldelse belastningen på databasen og netværket.
Redis kommandoeksempel:
GEOADD placeringer 10.9971645 45.4435245 Mercutio 10.9962165 45.4419226 Juliet
Node Redis-eksempel:
redis.geoadd ('placeringer', '10 .9971645 ', '45 .4435245', 'Mercutio', '10 .9962165 ', '45 .4419226', 'Juliet');
Opdatering af indekset
Når et medlem og dets koordinater er blevet registreret i indekset, giver Redis dig mulighed for at opdatere medlemmets placering. Opdatering af medlemmer i et Geo-sæt sker ved at kalde den samme kommando, der bruges til at tilføje dem, nemlig GEOADD. Når der ringes til eksisterende medlemmer, GEOADD opdaterer blot de geodata, der er knyttet til hvert medlem med de nye værdier. Derfor, når Romeo forlader huset for at begynde sin aftenvandring, kan hans opdaterede placering registreres med følgende.
Redis-kommandoeksempel:
GEOADD placeringer 10.999216 45.4432923 Romeo
Node Redis-eksempel:
redis.geoadd ('placeringer', '10 .999216 ', '45 .4432923', 'Romeo');
Fjernelse af medlemmer fra indekset
Efter at være blevet føjet til indekset, kan det være nødvendigt at medlemmer slettes fra det på et senere tidspunkt. For at lette sletningen af medlemmer fra Geo Set, leverer Redis ZREM kommando. For at slette et medlem (eller medlemmer) fra sættet, ZREM kaldes med det relevante nøglenavn efterfulgt af medlemmerne, der skal slettes fra det.
Redis-kommandoeksempel:
ZREM placeringer Mercutio
Node Redis-eksempel:
redis.zrem ('placeringer', 'Mercutio');
Det geospatiale indeks kan slettes helt. Da indekset er gemt som en Redis-nøgle, bliver DEL kommando kan bruges til at slette den.
Læsning fra indekset
Dataene i et Geo Set-indeks kan læses på flere måder. For det første kan indekset bruges til at scanne gennem alle medlemmerne i det, hvad enten det er i et stort parti eller i flere mindre stykker. Redis giver to kommandoer, der kan bruges til iterering gennem hele indekset: ZRANGE og ZSCAN. Men fordi disse kan bruges til at dække alle de indekserede elementer, er denne type adgang til dataene for det meste forbeholdt offline, ikke-kritiske operationer (for eksempel ETL og rapporteringsprocesser).
Den anden type læseadgang til indekset er til at hente medlemmernes koordinater, og for at opnå det giver Redis to kommandoer. Den første af disse kommandoer er GEOPOS, som returnerer koordinaterne for et givet medlem i et Geo-sæt. Antages det, at Romeo følger med på sin tur, gives svaret på hans nuværende opholdssted ved at udføre følgende.
Redis-kommandoeksempel:
GEOPOS placeringer Romeo
1) 1) 10.999164
2) 45.442681
Node Redis-eksempel:
redis.geopos ('placeringer', 'Romeo', funktion (fejler, svar) {
});
I eksemplet ovenfor er den første linje forespørgslen, mens de følgende linjer er databasens svar. Redis giver en anden kommando kaldet GEOHASH der rapporterer placeringen af medlemmer. Mens begge praktisk talt udfører den samme funktion, er forskellen mellem dem, at output af GEOHASH er kodet som en standard geohash (mere om geohashes nedenfor).
En anden anvendelse af data, der er gemt i indekset, er beregningsafstande mellem medlemmer. For ethvert to medlemmer i Geo Set, GEODIST kommando beregner og returnerer afstanden mellem dem.
Søgning i indekset
Den sidste og måske mest nyttige type læseadgang, som geospatialt indeks muliggør, er at søge i data efter deres placering. Det mest almindelige eksempel på sådanne søgninger er at finde indekserede medlemmer inden for en bestemt afstand fra en given placering. Til dette formål leverer Redis GEORADIUS kommando.
Som navnet antyder, GEORADIUS udfører en søgning inden for en cirkel givet af dens centrum og dens radius og returnerer de medlemmer, der falder inde i den. En anden Redis-kommando, GEORADIUSBYMEMBER, tjener det samme formål, men accepterer et af de indekserede medlemmer som cirkelens centrum. Følgende er et eksempel på en sådan søgning.
Redis-kommandoeksempel:
GEORADIUSBYMEMBER placeringer Romeo 100 m
1) “Juliet”
Node Redis-eksempel:
redis.georadiusbymember ('placeringer', 'Romeo', '100', 'm', funktion (fejler, svar) {
});
Søgekommandoen understøtter også sortering af svarene fra nærmeste til længst (standard) eller omvendt samt returnering af placeringen og afstanden for hvert svar. Redis tillader også lagring af svaret i et andet sæt til yderligere behandling (såsom personsøgning og sætoperationer).
Redis for geospatiale data
Enkelheden ved implementering af placeringsbaseret funktionalitet i Redis betyder, at du ikke kun kan håndtere oversvømmelsen af geodata let, men også implementere intelligens oven på simpel behandling. For eksempel kan den indbyggede radiusforespørgsel hjælpe dig med at implementere enkel funktionalitet som "interessepunkter i nærheden" uden at oversvømme din bruger eller din applikation med for mange valg. Indstil krydsfunktioner kan hjælpe dig med at isolere "interessepunkter" baseret på flere filtre som geografisk placering, brugeregenskaber og præferencer.
En anden fordel ved effektivitet opnås ved den måde, Redis Geo-sæt implementeres på. Geosæt i Redis er simpelthen en anden version af de kraftfulde sorterede sæt med den nøgleforskel, som Geo-sæt bruger geohash af en lokalitets længdegrad og breddegrad som dens score (plus on-the-fly kodning og afkodning, der er gennemsigtig for brugeren). Geohashing, et system opfundet af Gustavo Niemeyer, gør det også muligt at søge ekstremt effektivt. Hele placeringskoordinatsættet behøver ikke sammenlignes hver eneste tidsafstand beregnes; repræsentationen sikrer, at søgninger let kan begrænses og derfor bliver både tids- og rumeffektive.
Andre tilgængelige biblioteker tilføjer interessante muligheder, som at inkludere højde i beregninger. For eksempel sporer du muligvis en drone eller en gruppe droner i forskellige højder og bærer sensorer, der måler vindforhold eller temperaturforskelle et sted. Den krævede kombination af sæt og sorterede sæt findes i denne xyzsets API i Geo Lua-biblioteket, der er tilgængeligt på GitHub.
Stilængdeberegninger, der typisk er nødvendige for at navigere mellem waypoints til bestemte destinationer, kan let udføres med geopathlen API. Realtidssporing implementeres let med denne lokalitetsopdaterings-API.
Hvis din applikation bruger placeringsdata på nogen måde, skal du overveje at aflade meget af det hårde arbejde til Redis. For meget store datasæt kan det være mere omkostningseffektivt at bruge Redis på Flash, som bruger en kombination af RAM og flashhukommelse til at levere den ekstreme gennemstrømning og submillisekund latenstider, der er karakteristisk for Redis. For mere tekniske detaljer om brug af Redis til geospatiale data, herunder geohash-søgning og avancerede funktioner med Lua, se hvidbogen Redis for Geospatial Data.
Itamar Haber er chefudvikler for Redis Labs.
New Tech Forum giver et sted at udforske og diskutere nye virksomhedsteknologier i hidtil uset dybde og bredde. Valget er subjektivt baseret på vores valg af de teknologier, som vi mener er vigtige og af største interesse for læserne. accepterer ikke markedsføringssikkerhed til offentliggørelse og forbeholder sig retten til at redigere alt bidraget indhold. Send alle forespørgsler til [email protected].
