, med hovedsæde i Australien, bygger verdensklasse softwareplatforme og produkter, der muliggør overvågning, kontrol, optimering og orkestrering af en bred vifte af distribuerede energiressourcer og utility-skala aktiver. Evergen Evergen Evergens mission er at dekarbonisere energisystemet ved at lette overgangen til modstandsdygtige og vedvarende energisystemer.Dens cloud-native tilgang sikrer, at alle interessenter i den vedvarende energikæde har adgang til de oplysninger, de har brug for til at træffe informerede beslutninger om deres energiforbrug og -produktion. Som Evergens infrastruktur voksede, søgte det en tidsserie- og realtidsanalyseplatform, der kunne skalere med sine behov. Her er hvordan Evergen opdagede TigerData (skaberne af TimescaleDB), og hvordan TigerData forvandlede sine operationer - baseret på et interview med Evergens ledende softwareingeniør Jose Luis Ordiales Coscia. Hvorfor Evergen havde brug for en Time-Series Database "Optimering af vedvarende energi," siger Jose, "er en stor del af Evergens forretning, og tidsseriedata er afgørende for det. Evergen havde oprindeligt anvendt MongoDB Atlas til tidsserier, fordi det havde været deres standarddatabase for regelmæssige ikke-tidsserier data. Men Evergens tidsserier installation ved hjælp af MongoDB viste sig at være omkostningseffektiv og teknisk begrænsende: "Vores team skabte deres eget skema på toppen af MongoDB ved at gemme data i buckets, hvor hver bucket er en dag. "Vi så, at da dataene gik igennem, blev MongoDB tungere at bruge, fordi vi patchede flere data og lagrede flere data på samme tid," siger Jose. Teknisk kompleksitet og skalerbarhedsbegrænsninger Den tekniske udfordring begyndte med rå datalagringsgrænser i MongoDB. Evergen har hundredvis af integrationer for at sikre kompatibilitet på tværs af enhedsproducenter, og med regelmæssige mellemrum trækker data fra hver af disse integrationer og sender det til et Kafka-tema, hvor det offentliggør alle de rå prøver. "Vi lavede præ-aggregationer i hukommelsen," siger Jose, "fordi det var for dyrt for os at gemme alle de rå observationer i MongoDB. Hvis vi ønskede at have både rå data og aggregeringerne, måtte vi gøre alt det manuelt for hver enkelt.” Kontinuerlige aggregater Kontinuerlige aggregater På grund af den høje datamængde var deres Kafka-strømforarbejdningstjeneste enorm. Evergen kørte omkring 30 instanser af den tjeneste, som udgjorde en stor procentdel af deres brug i Kubernetes. De forsinkede data – mere end 15 minutter for den fem-minutters aggregering og en time for den 30-minutters aggregering – blev tabt, fordi de ikke længere havde de foraggregerede data i hukommelsen. Manglende rå data skabte mangel på gennemsigtighed for auditspor og debugging. MongoDB ydeevne for tidsserie, ifølge Jose, var sub-par: "Alle slags vidste, at det ikke var ideelt, men det var en af de ting, du tror, på et tidspunkt vil vi rette det, men ingen faktisk gjorde. Database evalueringsprocessen I deres evalueringsproces kiggede Evergen kort på InfluxDB, men da det faldt i støtte til Australiens region på det tidspunkt, var det en no-go fra starten. Fordi al deres infrastruktur er i AWS, og de bruger andre AWS-tjenester, evaluerede Evergen først Amazon Timestream.   Forsinket ydeevne (selv indsamling af data for en dag eller en uge var i rækkefølge af 2-5 sekunder) og mangel på forespørgsel eller ydeevne tuning. Manglende evne til at køre en Timestream-database lokalt med Docker (selvom det var nemt at køre Postgres og TimescaleDB lokalt) – kørsel af lokale tests med Timestream krævede forbindelse til AWS for at oprette en faktisk database og derefter fjerne den i slutningen. Ikke anvendelig til forudsigelse af vedvarende energi - hvorved Timestream kun tillod lagring af data op til 15 minutter i fremtiden. De havde job og logik til at flytte data fra Redis til Timestream over tid, men data relateret til enheder og steder var stadig i MongoDB. ”Vi havde tre databaser med forskellige typer data, og hver gang vi var nødt til at slutte disse tre kilder, Det var en af de vigtigste ting, vi kiggede på, da vi startede denne evalueringsproces – at kunne bruge en enkelt database til alle vores data: tidsserie og ikke-tidsserie. Det var et stort salgspunkt for os, da det kom til TimescaleDB, fordi det kun er Postgres nedenfor. Du kan bruge det som en regelmæssig relationsdatabase.   Evergen forsøgte også tidsseriestøtte i MongoDB: "De har denne nye type samling i MongoDB, der håndterer tidsseriedata. men de manglede en masse funktioner, som TigerData har, såsom kontinuerlige aggregater, rettighedspolitikker og komprimering. Opdagelse og test af TigerData Jose opdagede oprindeligt om TigerData gennem en ven, der arbejdede der som backendingeniør. Efter at have lært om produktet, havde Jose ansøgt om at arbejde hos TigerData, da han ønskede at skifte roller fra et tidligere firma. Så, da han sluttede sig til Evergen, blev han en stor fortaler for at bruge TimescaleDB, da hans team begyndte at overveje det - han kendte allerede dens funktioner, og at det var bygget på kamptestet, kedelig gammel teknologi, som er "stor for en database - du vil ikke have nogen overraskelser der." Under evalueringen af TimescaleDB udnyttede Evergen TigerData-ressourcerne: "Den officielle dokumentation var meget omfattende og let at forstå og følge. TigerData-bloggen har også nogle rigtig gode diskussioner om kompromisser af forskellige tilgange.   Evergens bevis på koncept involverede oprettelse af dobbeltskrivninger og dobbeltlæsninger ved at køre MongoDB og TimescaleDB parallelt. Dette gjorde det muligt for dem at teste TimescaleDB uden at forstyrre operationer eller påvirke kunder.Når de havde et par måneder af data gemt i TimescaleDB, lavede de skiftet. Fra et skalerbarhed, operationelt og udvikleroplevelsesperspektiv tjekkede TimescaleDB alle bokse - leverer indtag / forespørgselspræstation, fleksibilitet og brugervenlighed. "Fordi vi har hundredtusinder af enheder, og potentielt ser på millioner af enheder i fremtiden, skal vi sørge for, at indtagelsesfrekvensen er glat. Hidtil har det været fantastisk med TigerData." - Jose Luis Ordiales Coscia, Lead Software Engineer hos Evergen "Fordi vi har hundredtusinder af enheder, og potentielt ser på millioner af enheder i fremtiden, skal vi sørge for, at indtagelsesfrekvensen er glat. Hidtil har det været fantastisk med TigerData." - Jose Luis Ordiales Coscia, Lead Software Engineer hos Evergen "Fordi vi har hundredtusindvis af enheder, og potentielt ser på millioner af enheder i fremtiden, skal vi sørge for, at indtagelsesfrekvensen er glat. Hidtil har det været fantastisk med TigerData," siger Jose. Evergen værdsatte også TimescaleDB's forespørgselspræstation, fordi disse data giver mulighed for real-time kundeorienterede dashboards: "Du ønsker ikke, at dine brugere skal vente 5-10 sekunder bare for at se disse diagrammer." Tilgængeligheden af udviklerværktøjer var også en afgørende faktor: "Fordi Postgres er en så etableret spiller på markedet, er der tusindvis af biblioteker og værktøjer at arbejde med." Så var bekendtskab med, hvordan man forespørger dataene: "Alle kender SQL på et eller andet niveau, selv ikke-tekniske mennesker. "Vi kan give nogen i datalogi-teamet eller kundesupportteamet adgang til TimescaleDB, og de vil finde ud af, hvordan man forespørger dataene, hvilket ikke var tilfældet med MongoDB." - Jose Luis Ordiales Coscia, ledende softwareingeniør hos Evergen "Vi kan give nogen i datalogi-teamet eller kundesupportteamet adgang til TimescaleDB, og de vil finde ud af, hvordan man forespørger dataene, hvilket ikke var tilfældet med MongoDB." - Jose Luis Ordiales Coscia, ledende softwareingeniør hos Evergen Sikkerhed var også en overvejelse. opfylder Evergens krav. TigerDatas sikkerhedsfunktioner TigerDatas sikkerhedsfunktioner Hvordan Evergen bruger TigerData Udskiftning af MongoDB med TimescaleDB for tidsseriedata og oprettelse af en "Telemetry Service" opnåede datacentralisering, der ikke var mulig før. "Vi forsøger at indkapsle og isolere adgangen til den ene tjeneste, der håndterer tidsseriedata. Et mål med denne migration var at konsolidere alle læsninger og skrivninger til ét sted - "Telemetry Service". (managed TimescaleDB) instance på Evergen. En undtagelse er, at de giver adgang til deres data science team til udforskende forespørgsel af dataene. af hoveddatabasen, kun for det team, hjælper, da det giver adgang uden at påvirke ydeevnen. Tiger sky Læs replikken Tiger sky Læs replikken Evergen bruger også TigerDatas integrerede PopSQL IDE. Jose siger: "Det er et godt værktøj til at udforske databaser og dele forespørgsler. Vi havde ikke det med MongoDB. Vi måtte logge ind på MongoDB Atlas-siden hver gang og manuelt skrive ned vores forespørgsler." Hvordan Tiger Cloud-fordele ender kunder Med MongoDB kunne Evergen kun gemme tre måneder af data på grund af omkostningsbegrænsninger. ”Nu med TigerData,” deler Jose, ”det er op til os at definere disse opbevaringspolitikker. Lige nu har vi det sat på to år, og vi har komprimering og lageret lagring. Det er helt sikkert et salgspunkt for vores produktteam, hvilket gør det muligt at lave en Home Energy-rapport for det forgangne år mod én for kun de sidste tre måneder.”   Query ydeevne var en anden stor gevinst: "Før, du måtte vente et par sekunder, når du får adgang til din web-app eller mobilapp for at se disse diagrammer. Nu er det lige under 500 millisekunder, hvilket er virkelig, virkelig godt. De tidsseriedata, der nu håndteres af TigerData, er også afgørende for Evergens energioptimeringstjeneste.Den tjeneste omfatter bag-the-meter optimering (maskineindlæringsoptimering, der leverer avanceret individualiseret elomkostningsminimering) og front-of-meter optimering (som gør det muligt at monetere afsendelige aktiver). Hvad vedtagelsen af Tiger Cloud betød for Evergen For Evergen reducerede udskiftningen af MongoDB med Tiger Cloud brugen af Kubernetes-klusterressourcer med mere end 50%. omkostningsbesparelser, effektiv komprimering, lageret lagring og konstant adgang til historiske data betød nyfundet teknisk og forretningsmæssig agilitet. "At have den frihed til at beslutte, hvor meget data der skal gemmes, hvad der er nyttigt, og hvad der ikke er," siger Jose, "har været en stor gevinst, fordi der før var en hård grænse for, hvor meget data vi kunne gemme. Nu har vi den fleksibilitet til at sige disse gamle data - vi vil holde det i S3. Det vil være langsommere at få adgang, men det er fint. og vi vil holde denne masse data i høj ydeevne lagring. Tiger Cloud forenklede også Evergens stack: "Forenkling af vores arkitektur - at være i stand til at erstatte alle disse forskellige specifikke databaser - det er en stor ting for den overordnede kompleksitet af arkitekturen, som gør det lettere at udvide dette i fremtiden også."   Adgang til alle de rå data betød, at de kunne referere det til debugging og spore det til bestemte enheder - hvilket er meget lettere at gøre med rå data end med foraggregerede data. "Muligheden for at gemme alle de rå data," forklarer Jose, "betyder, at vi kan oprette nye aggregeringer, som vi ikke engang har overvejet - på fly. Vi kunne ikke gøre det før. Med TigerData, hvis vi i morgen beslutter, at vi har brug for disse nye data, der stammer fra de rå data, kan vi bare oprette en ny aggregering, køre hele backfill-processen, og det er det - vi har det. "Fordi alle kender SQL, på et eller andet niveau, og alle har arbejdet med SQL på et tidspunkt i deres karriere, var det nemt for [nyligt ansatte ingeniører] bare at hoppe ind i lagerkoden og finde ud af, hvad der foregik." Fremtidsplaner ved hjælp af TigerData Valget af TigerData hjalp Evergen med at bevise fremtiden for deres arkitektur, da de skalerede. ”Det er sandt – du kan bruge Postgres til alt i disse dage. Der er en udvidelse til absolut alt. Det var en anden stor faktor for beslutningen – at tænke på, hvad hvis vi skal gemme denne type data i fremtiden? Med TigerData, Evergen opbygget et datasystem for skalerbarhed til at understøtte deres planer om at nå nye markeder og øge mængden af enheder, de har i størrelsesorden. Evergen planlægger også at bruge en funktion TigerData arbejder på, som ville gøre de data Evergen har i Tiger Cloud til rådighed for andre teams, der måske bruger forskellige værktøjer. Jose's råd til ingeniører, der overvejer at skifte: "Når du opretter abstraktioner i din kodebase, skal du holde alt relateret til en bestemt teknologi isoleret fra resten af koden, da det gjorde det meget lettere for os at køre vores dual-read og dual-writes-eksperiment - fordi der var et enkelt sted i kodebasen, som vi måtte gå og ændre for at det skulle ske.

This story contains new, firsthand information uncovered by the writer.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Denne lyd er produceret på historiens originalsprog!

Hvordan Evergen bruger TigerData til at skalere sin overvågningsarkitektur for vedvarende energi

About Author

KOMMENTARER

HÆNG TAGS

DENNE ARTIKEL BLEV PRÆsenterET I

Related Stories

Meet IONOS: HackerNoon Company of the Week

Meet KuCoin Community Chain: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Surfshark: HackerNoon Company of the Week

Meet IONOS: HackerNoon Company of the Week

Meet KuCoin Community Chain: HackerNoon Company of the Week

Meet Bybit: HackerNoon Company of the Week

Meet Surfshark: HackerNoon Company of the Week

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps