, amb seu a Austràlia, construeix plataformes i productes de programari de classe mundial que permeten el seguiment, control, optimització i orquestració d'una àmplia gamma de recursos energètics distribuïts i actius a escala d'utilitats. Evergènesi Evergènesi La missió d'Evergen és descarbonitzar el sistema energètic facilitant la transició a sistemes d'energia resilients i renovables.El seu enfocament natiu al núvol assegura que totes les parts interessades a tota la cadena d'energia renovable tenen accés a la informació que necessiten per prendre decisions informades sobre el seu ús i producció d'energia. A mesura que l'infraestructura d'Evergen creixia, buscava una plataforma d'anàlisi de sèrie de temps i temps real que pogués escalar amb les seves necessitats.Aquí està com Evergen va descobrir TigerData (creadors de TimescaleDB), i com TigerData va transformar les seves operacions, basat en una entrevista amb l'enginyer de programari principal d'Evergen, Jose Luis Ordiales Coscia. Per què Evergen necessitava una base de dades de sèrie temporal "L'optimització de les energies renovables", diu Jose, "és una gran part del negoci d'Evergen, i les dades de la sèrie de temps són essencials per a això. Tot i això, la configuració de la sèrie de temps d'Evergen utilitzant MongoDB va resultar ser cost-prohibitiu i tècnicament restrictiu: "El nostre equip va crear el seu propi esquema sobre MongoDB mitjançant l'emmagatzematge de dades en bótes, on cada bótes és un dia. "Vam veure que a mesura que passaven les dades, MongoDB es va fer més difícil d'utilitzar perquè estem patxant més dades i emmagatzemant més dades al mateix temps", diu Jose. Complexitat tècnica i limitacions d'escalabilitat El repte tècnic va començar amb els límits d'emmagatzematge de dades primeres en MongoDB. Evergen té centenars d'integracions per assegurar la compatibilitat entre els fabricants de dispositius, i a intervals regulars, treu dades de cadascuna d'aquestes integracions i l'envia a un tema Kafka on publica totes les mostres primeres. "Hem fet pre-agregacions en memòria", diu Jose, "perquè era massa car per a nosaltres emmagatzemar totes les observacions brutes en MongoDB. Si volíem tenir tant les dades brutes com les agregacions, vam haver de fer tot això manualment per a cadascuna d’elles”. Agregats continuats Agregats continuats A causa de l'alt volum de dades, el seu servei de processament de flux Kafka era enorme. Evergen va executar unes 30 instàncies d'aquest servei, que va representar un gran percentatge del seu ús en Kubernetes. Les dades d'arribada tardana -més de 15 minuts per a l'agregació de cinc minuts i una hora per a l'agregació de 30 minuts- es van perdre perquè ja no tenien les dades preagregades a la memòria. No tenir les dades brutes va crear una falta de transparència per a les pistes d'auditoria i el debug. El rendiment de MongoDB per a la sèrie de temps, segons Jose, va ser sub-par: "Tothom sabia que no era ideal, però era una d'aquestes coses que penses, en algun moment ho corregirem, però ningú realment ho va fer. El procés d'avaluació de la base de dades En el seu procés d'avaluació, Evergen va mirar breument a InfluxDB, però ja que en aquell moment estava perdent suport per a la regió d'Austràlia, que va ser un no-go des del principi. Com que tota la seva infraestructura està a AWS i utilitzen altres serveis d'AWS, Evergen va avaluar primer Amazon Timestream.   Retard en el rendiment (fins i tot recollir dades durant un dia o una setmana era en l'ordre de 2-5 segons) i falta de consulta o ajustament de rendiment. Impossibilitat d'executar una base de dades de Timestream localment amb Docker (encara que executar Postgres i TimescaleDB localment era fàcil) - executar proves locals amb Timestream requeria connectar-se a AWS per crear una base de dades real i després eliminar-la al final. No s'utilitza per a la predicció d'energies renovables, amb la qual cosa Timestream només va permetre emmagatzemar dades fins a 15 minuts en el futur. Evergen va intentar utilitzar Timestream per a dades de sèrie de temps històrica i Redis per a dades de sèrie de temps predictives. tenien tasques i lògica per moure les dades de Redis a Timestream amb el temps, però les dades relacionades amb els dispositius i els llocs encara estaven en MongoDB. Això era una de les coses clau que estem mirant quan vam iniciar aquest procés d'avaluació - ser capaç d'utilitzar una única base de dades per a totes les nostres dades: sèrie de temps i sèrie no-temps. Això va ser un gran punt de venda per a nosaltres quan va arribar a TimescaleDB perquè és només Postgres per sota.   Evergen també va provar el suport de sèrie de temps en MongoDB: "Tenen aquest nou tipus de col·lecció en MongoDB que gestiona dades de sèrie de temps. però estaven perdent un munt de característiques que TigerData té, com ara agregacions contínues, polítiques de retenció i compressió. Descobrir i provar TigerData José va descobrir inicialment sobre TigerData a través d'un amic que hi treballava com a enginyer de backend. Després d'aprendre sobre el producte, Jose havia sol·licitat treballar a TigerData, quan estava buscant canviar de rol d'una empresa anterior. Després, quan es va unir a Evergen, es va convertir en un gran defensor de l'ús de TimescaleDB a mesura que el seu equip va començar a considerar-lo - ja sabia les seves característiques i que estava construït sobre la tecnologia vella avorrida, que és "genial per a una base de dades - no vols cap sorpresa allà ". En avaluar TimescaleDB, Evergen va aprofitar els recursos de TigerData: "La documentació oficial va ser molt completa i fàcil d'entendre i seguir. El blog de TigerData també té algunes discussions molt bones sobre els compromisos de diferents enfocaments.   La prova del concepte d'Evergen va implicar la configuració de doble escriptura i doble lectura executant MongoDB i TimescaleDB en paral·lel. Això els va permetre provar TimescaleDB sense interrompre les operacions o afectar els clients. Un cop tinguessin uns mesos de dades emmagatzemades a TimescaleDB, van fer el canvi. Des d'una perspectiva d'escalabilitat, operació i experiència de desenvolupador, TimescaleDB va comprovar totes les caixes - lliurant rendiment d'ingestió / consulta, flexibilitat i facilitat d'ús. "Com que tenim centenars de milers de dispositius, i potencialment mirant milions de dispositius en el futur, hem de assegurar-nos que la taxa d'ingestió és suau. "Com que tenim centenars de milers de dispositius, i potencialment mirant milions de dispositius en el futur, hem de assegurar-nos que la taxa d'ingestió és suau. "Perquè tenim centenars de milers de dispositius, i potencialment mirant a milions de dispositius en el futur, necessitem assegurar-nos que la taxa d'ingestió és suau. Fins ara ha estat increïble amb TigerData", diu Jose. Evergen també va apreciar el rendiment de la consulta de TimescaleDB perquè aquestes dades donen suport a les taules de control en temps real adreçades al client: "No voleu que els vostres usuaris hagin d'esperar 5-10 segons només per veure aquests gràfics." La disponibilitat d'eines per a desenvolupadors també va ser un factor decisiu: "Perquè Postgres és un jugador tan establert en el mercat, hi ha milers de biblioteques i eines per treballar." Així va ser la familiaritat amb com consultar les dades: "Tothom coneix SQL a algun nivell, fins i tot persones no tècniques. "Tothom coneix SQL en algun nivell, fins i tot persones no tècniques.Podem donar a algú de l'equip de ciència de dades o equip de suport al client accés a TimescaleDB, i esbrinarà com consultar les dades, que no va ser el cas amb MongoDB." - Jose Luis Ordiales Coscia, Enginyer de programari principal a Evergen "Tothom coneix SQL en algun nivell, fins i tot persones no tècniques.Podem donar a algú de l'equip de ciència de dades o equip de suport al client accés a TimescaleDB, i esbrinarà com consultar les dades, que no va ser el cas amb MongoDB." - Jose Luis Ordiales Coscia, Enginyer de programari principal a Evergen La seguretat també és una consideració. Compleix els requisits de l’Everest. Característiques de seguretat de TigerData Característiques de seguretat de TigerData Com utilitza Evergen TigerData La substitució de MongoDB per TimescaleDB per a dades de sèrie de temps i la configuració d'un "Servei de telemetria" va aconseguir una centralització de dades que no era possible anteriorment. "Intentem encapsular i aïllar l'accés a l'únic servei que està tractant dades de sèrie de temps. Un objectiu d'aquesta migració va ser consolidar totes les lectures i escriptures en un sol lloc - el "Servei de telemetria". (Managed TimescaleDB) instància a Evergen. Una excepció és l'accés que proporcionen al seu equip de ciència de dades per a la consulta exploratòria de les dades. de la base de dades principal, només per a aquest equip, ajuda ja que dóna accés sense afectar el rendiment. El núvol tigre Llegeix la replica El núvol tigre Llegeix la replica Evergen també utilitza molt el PopSQL IDE integrat de TigerData. diu Jose: "És una gran eina per explorar bases de dades i compartir consultes. No vam tenir això amb MongoDB. Vam haver de connectar a la pàgina de l'Atles de MongoDB cada vegada i escriure manualment les nostres consultes." Com Tiger Cloud beneficia els clients finals Amb MongoDB, Evergen només podia emmagatzemar tres mesos de dades a causa de les restriccions de cost. "Ara amb TigerData", comparteix Jose, "és a nosaltres definir aquestes polítiques de retenció. Això és sens dubte un punt de venda per al nostre equip de productes, permetent un informe d'energia a domicili per a l'any passat versus un només per als últims tres mesos ".   El rendiment de la consulta va ser una altra gran victòria: "Abans, havíeu d'esperar uns segons en accedir a la vostra aplicació web o a l'aplicació mòbil per veure aquests gràfics. Ara és just sota de 500 mil·lisegons, que és realment, realment bo. Les dades de la sèrie de temps que ara gestiona TigerData també són crítiques per al servei d'optimització energètica d'Evergen.Aquest servei inclou l'optimització darrere del mesurador (optimització d'aprenentatge automàtic que proporciona una minimització avançada de costos d'electricitat individualitzada) i l'optimització davant del mesurador (que permet monetaritzar els actius enviables). Què va significar adoptar Tiger Cloud per a Evergen Per a Evergen, la substitució de MongoDB per Tiger Cloud va reduir l'ús de recursos del clúster de Kubernetes en més del 50%.Economies de costos, compressió eficient, emmagatzematge en capes i accés constant a dades històriques van significar una nova agilitat tècnica i empresarial. "Tenir aquesta llibertat per decidir quant de dades mantenir, el que és útil i el que no és", diu Jose, "ha estat una gran victòria perquè abans hi havia un límit dur de la quantitat de dades que podíem emmagatzemar. Tiger Cloud també va simplificar l'estaca d'Evergen: "Simplificar la nostra arquitectura -ser capaç de reemplaçar totes aquestes diferents bases de dades específiques- és una cosa enorme per a la complexitat general de l'arquitectura, que fa que l'extensió en el futur també sigui més fàcil".   L'accés a totes les dades brutes significava que podien referir-se a elles per a la depuració i rastrejar-les a dispositius concrets, cosa que és molt més fàcil de fer amb les dades brutes que amb les dades preagregades. "La capacitat d'emmagatzemar totes les dades brutes", explica Jose, "és a dir que podem crear noves agregacions que ni tan sols hem considerat -en vol. No podíem fer-ho abans. Amb TigerData, si demà decidim que necessitem aquestes noves dades derivades de les dades brutes, només podem crear una nova agregació, executar tot el procés de recanvi, i això és el que tenim. Això és enorme per a la flexibilitat, on no necessitem predir el que necessitarem un mes o un any d'ara endavant ". Construït sobre el conegut Postgres, Tiger Cloud va tenir un impacte positiu en l'embarcament de l'equip. "Perquè tothom coneix SQL, en algun nivell, i tothom ha treballat amb SQL en algun moment de la seva carrera, va ser senzill per [ens enginyers nou reclutats] simplement saltar al codi d'emmagatzematge i esbrinar el que estava passant." Plans de futur utilitzant TigerData L'elecció de TigerData va ajudar a Evergen a provar el futur de la seva arquitectura a mesura que es van escalfar. "És veritat - vostè pot utilitzar Postgres per a tot en aquests dies. Hi ha una extensió per a absolutament tot. Això va ser un altre factor important per a la decisió - pensar què si necessitem emmagatzemar aquest tipus de dades en el futur? Oh sí, hi ha aquesta extensió ja disponible. Tenir aquesta possibilitat - Crec que va ser una gran cosa per a l'empresa ", diu Jose. Amb TigerData, Evergen va construir una base de dades per a l'escalabilitat per donar suport als seus plans d'arribar a nous mercats i augmentar la quantitat de dispositius que tenen per un ordre de magnitud. "Quan creeu abstraccions en la vostra base de codi, mantingueu tot relacionat amb una tecnologia particular aïllat de la resta del codi, ja que això ens va fer molt més fàcil executar el nostre experiment de doble lectura i doble escriptura, perquè hi havia un sol lloc en la base de codi que vam haver d'anar i canviar perquè això passés.

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

Aquest àudio és produït a l'idioma original de la història!

Massa Llarg; Per llegir

Make resilience your competitive advantage

Com Evergen utilitza TigerData per escalar la seva arquitectura de monitoratge de les energies renovables

About Author

COMENTARIS

Etiquetes penjant

AQUEST ARTICLE VA SER PRESENTAT A

Related Stories

Startups of The Year: Meet the Healthcare Industry

Startups of The Year: Meet the Commerce Industry

Startups of The Year: Meet the Emerging Tech Industry

On Taxes

Startups of The Year: Meet the Healthcare Industry

Startups of The Year: Meet the Commerce Industry

Startups of The Year: Meet the Emerging Tech Industry

On Taxes

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps