Kupanua haraka hifadhi ya mtandaoni kwa watumiaji zaidi ya bilioni 1 wa ChatGPT

Kila bidhaa ya OpenAI hutegemea ufikiaji wa data ulio wa haraka na wa kuaminika, iwe mtu anaingia katika akaunti, anakagua mipangilio yake ya Codex au anaanzisha mazungumzo mapya katika ChatGPT. Kila kitendo kati ya hivyo kinaweza kuhitaji utafutaji mwingi tofauti wa data kabla bidhaa haijajibu. Maombi hayo yakiwa polepole, bidhaa huhisiwa kuwa polepole. Maombi hayo yakishindwa, bidhaa huacha kufanya kazi kabisa.

Habitat ni jukwaa la hifadhi ya mtandaoni tulilojenga ili bidhaa za OpenAI ziweze kufikia taarifa zinazohitajika kwa haraka na kwa kutegemewa. Habitat sasa hushughulikia zaidi ya maombi milioni 70 kila sekunde, ikiwezesha bidhaa zinazotumiwa na zaidi ya watu bilioni 1 kila wiki katika karibu maeneo 40 ya kijiografia. Habitat ilizinduliwa kwanza kusaidia GPT katika DevDay 2023, ikianza kama maktaba rahisi ya Python upande wa mteja iliyounganishwa na hifadhidata moja. Leo, ni mfumo changamano uliosambazwa unaohudumia zaidi ya petabaiti 500 za data.

Kujenga na kuendesha miundombinu kwa kiwango hiki si kazi rahisi, lakini pia si changamoto ya kipekee. Kilichofanya hali yetu iwe ya kipekee ni kasi isiyowahi kutokea ambayo tumelazimika kupanuka ili kukidhi ongezeko kubwa la watumiaji na mahitaji ya bidhaa, huku tukijenga jukwaa lililokomaa kwa wakati mmoja. Mara nyingi, wahandisi wa mifumo hujenga kwa kiwango cha mara 10 na kutumaini kitadumu miaka michache huku wakijiandaa kwa ongezeko jingine la mara 10. Kwa upande wetu, tumekua zaidi ya mara 10 mwaka hadi mwaka katika miaka mitatu iliyopita. Kwa hiyo, kujenga na kuendesha Habitat kumekuwa mfululizo wa maamuzi ya mbinu na upangaji wa hatua: kuelewa kila sehemu hadi kiwango cha chini kabisa ili kupata uwezo wote kutoka kwa teknolojia tulizonazo, huku tukikabiliana na uhaba wa hifadhi na uwezo wa kukokotoa ili kupata muda wa kuwekeza katika misingi.

OpenAI ilipokua, Habitat ililazimika kukua pamoja nayo: kwanza kuwa ya kuaminika vya kutosha kwa trafiki muhimu ya bidhaa, kisha kuwa ya haraka vya kutosha kwa watumiaji duniani kote, na hatimaye kuendesha kwa ustadi kwa kiwango kikubwa sana. Makala haya ni ya kwanza katika mfululizo wa sehemu mbili kuhusu jinsi tulivyopanua hifadhi ya mtandaoni. Katika makala haya, tutaeleza jinsi Habitat ilivyobadilika, kwa nini tuliibadilisha kutoka maktaba kuwa huduma, na jinsi tulivyopanua huduma iliyoandikwa kwa lugha isiyotumiwa sana katika teknolojia za kuhudumia—Python—kuwa safu ya kuaminika ya jukwaa la hifadhi.

Katika makala yajayo, tutaeleza kwa kina jinsi tulivyofanikisha uaminifu wa wapangaji wengi kwa kiwango kikubwa, mkakati wetu wa safu nyingi wa kuboresha utendaji wa usomaji, na jinsi tulivyopanua ushirikiano wetu na Azure Cosmos DB ili kukidhi kwa kutegemewa mahitaji yasiyowahi kutokea.

Habitat ilianza na wazo rahisi: wahandisi wa bidhaa hawapaswi kuhitaji kufikiria kuhusu usimamizi wa hifadhidata. Habitat ilizinduliwa kwanza kusaidia GPT katika DevDay 2023 kama maktaba ndogo ya Python iliyowasiliana na seva kuu ya ChatGPT. Ilitumia seti ndogo ya operesheni ambazo kwa ndani ziliunganishwa na programu ya hifadhidata, Azure Cosmos DB.

Kazi ya maktaba ilikuwa kuzipa timu za bidhaa njia rahisi ya kuhifadhi na kurejesha data bila kulazimika kuelewa kwa kina maelezo ya mfumo wa ndani. Habitat ilishughulikia kazi muhimu: kutambua aina ya data iliyohusika, ilikotakiwa kutoka au kwenda, ikiwa ombi liliruhusiwa, na kadhalika.

Wahandisi wa bidhaa hawakuhitaji kushughulikia utafutaji wa kielezo, uelekezaji, uidhinishaji, usimbaji fiche, ubadilishaji kuwa mfululizo, uundaji wa maombi na ukusanyaji wa miunganisho. Hawakuhitaji hata kufikiria data ilikotoka: Azure Cosmos DB, akiba au aina nyingine za hifadhi.

Maktaba hii ya Python ilifanya kazi vizuri na Habitat ikakubaliwa haraka na wahandisi wa bidhaa katika OpenAI, licha ya kutokuwepo kwa msukumo wa pamoja wa kuacha kutumia Postgres na Azure Cosmos DB za kujihudumia.

Mahitaji ya bidhaa yalipobadilika, ilikuwa rahisi pia kwa wasanidi wa bidhaa kuongeza kwenye maktaba ya pamoja uwezo kama kuweka akiba upande wa mteja, ubanaji au usimbaji fiche.

Kufikia katikati ya 2025, Habitat ilikuwa imefikia kikomo chake kama utekelezaji wa upande wa mteja. Kadiri safu ya Habitat ilivyozidi kuwa changamano na idadi ya huduma za OpenAI kuongezeka, mabadiliko ya itifaki yanayooana na matoleo ya awali yalikuwa hayawezekani.

Katika tukio moja, tulitaka kupunguza athari za kukatika kwa huduma katika eneo moja kwa seti zetu muhimu zaidi za data kwa kuzihamisha hadi kwenye seti ya akaunti za Azure Cosmos DB zilizosambazwa kikanda. Mabadiliko haya yalihitaji kuongeza mantiki ya uelekezaji kwenye mteja, ikiwa imezimwa nyuma ya swichi ya kipengele, kuhakikisha imesambazwa kwa wateja wote, kisha kuwasha kibendera hicho.

Kuratibu usambazaji katika huduma kadhaa na kushirikiana na kila timu kuutekeleza kulichukua siku kadhaa. Kabla ya kuwasha kipengele hiki, tuligundua kwamba tulitaka kuongeza unakili wa maombi kwa majaribio ili kuhakikisha mantiki ya ugawaji ilikuwa sahihi. Hilo lilichukua siku nyingine kadhaa kusambazwa. Kurekebisha hitilafu katika jambo tulilogundua kuwa si sahihi? Siku nyingine kadhaa. Hatimaye tulikuwa tayari kuwasha swichi, lakini mojawapo ya timu ikarudisha huduma yake kwa sababu zisizohusiana hadi kwa mteja wa awali mwenye hitilafu, na kusababisha kukatika kwa huduma tulikojitahidi sana kuepuka.

Mabadiliko ya maktaba ya mteja yalihitaji uratibu changamano katika huduma kadhaa, mchakato uliozidi kuwa dhaifu, usio na ufanisi na rahisi kuathiriwa na hitilafu za uendeshaji. Ili kupunguza mtawanyiko huu wa kiutendaji katika usambazaji wa baadaye, tuliamua kuifanya Habitat kuwa huduma yake yenyewe.

Kwa kutenganisha mantiki ya hifadhi na kuiweka katika huduma inayojitegemea, tuliunda kituo kimoja cha kudhibiti usambazaji, uangalizi na maboresho ya jukwaa. Badala ya kudhibiti masasisho yaliyogawanyika, tungeweza kutekeleza maboresho katika kituo kimoja na kutoa manufaa ya haraka kwa kila bidhaa ya OpenAI.

Huduma ya kati pia hutupa sehemu moja ya udhibiti ya kuweka misingi imara zaidi ya usalama na faragha ya data. Huduma ya Habitat ndiyo sehemu tunapoweza kutekeleza kwa pamoja sera za udhibiti wa ufikiaji, kuweka kumbukumbu za ukaguzi na kuzuia ufikiaji wa rasilimali za msingi za hifadhi kama Azure Cosmos DB. Habitat ina jukumu muhimu la kulinda data ya watumiaji na kuzuia ufikiaji usioidhinishwa kutoka kwa wahusika wa nje, wa ndani na wakala.

Tulijua tulihitaji huduma, lakini hatukutaka kuondoka Python bado, licha ya gharama zake za ziada kama huduma. Kutumia Python kwa huduma yenye utendaji wa juu kuliongeza ukawivu wa mtandao na gharama kubwa za kupanua CPU na kumbukumbu ikilinganishwa na utekelezaji wa maktaba ya ndani. Zaidi ya hayo, tulitambua kuwa udhaifu wa ufanisi wa Python haungekubalika kwa kiwango cha mara 100, hivyo kuifanya kazi ya kuiandika upya baadaye kuwa karibu na hakika.

Hata hivyo, tuliona hili kuwa deni la kiufundi tulilochukua kimkakati. Lengo letu kuu wakati huo halikuwa kuboresha gharama au rasilimali, bali kuwawezesha wasanidi wa bidhaa kuendelea na kazi na kuleta uthabiti wa jukwaa. Kwa kukubali kwa muda mfupi hasara za utendaji za huduma ya Python, tuliweza kutanguliza changamoto za haraka zaidi, kuanzisha API zetu za msingi na kujenga miundombinu thabiti.

Pia tuliweka dau lililokokotolewa kwamba maendeleo ya haraka ya miundo yetu ya uandishi wa msimbo yangerahisisha njia ya kiufundi baadaye. Tuliamini kwamba kufikia wakati uhamishaji kamili kutoka Python ungehitajika, Codex na GPT zingefanya uhamishaji huo uwezekane. Hatimaye, dau hilo lilithibitika kuwa sahihi.

Kuendesha Habitat kama huduma ya Python hakungekuwa bora kiutendaji, lakini lilikuwa chaguo la lazima. Python hutuwezesha kusonga haraka, lakini hilo halikumaanisha tungepuuza tahadhari na kukubali ukawivu mbaya zaidi kwa kiwango kikubwa. Ombi la wastani la mtumiaji linaposababisha mamia ya miito ya hifadhidata, mtumiaji huhisi mwito ulio wa polepole zaidi. Tumegundua kuwa changamoto kuu ya kuendesha huduma ya Python kwa kiwango hiki ni kudhibiti ukawivu wa mwisho wa usambazaji.

Asyncio husaidia Python kutekeleza kwa wakati mmoja kazi zinazotegemea I/O, lakini haisaidii kukwepa Python GIL wala kutoa uchakataji sambamba wa CPU. Mbali na kuwakilisha maombi yenye I/O nyingi, Habitat hushughulikia majukumu na kazi nyingi za chinichini zinazotumia CPU sana: uelekezaji, ubanaji, usimbaji fiche, ukokotoaji wa checksum, ukaguzi wa afya ya huduma za chini, kunakili maombi kwa majaribio na kutuma maombi mbadala.

Kwa kuwa huduma yetu ina kazi nyingi zinazotumia CPU sana na kazi za chinichini, ucheleweshaji wa upangaji wa asyncio unaweza kutawala kwa urahisi ukawivu wa maombi ya mwisho wa usambazaji. Kabla ya kuboresha uzinduzi wa kwanza wa huduma, tuliona katika ufuatiliaji wa maombi yenye ukawivu wa p99 na zaidi kwamba, ingawa hifadhi ya chini ilijibu haraka, maombi yalikwama mara kwa mara yakisubiri coroutine husika ipangiwe tena ili kuchanganua jibu.

Kwa huduma za Python katika OpenAI, tumeona kuwa pamoja na kupima vipimo vya kawaida vya matumizi na kujaa kwa kumbukumbu, CPU, mtandao na diski, ni muhimu pia kufuatilia kitanzi cha asyncio na jinsi kinavyoshughulika, kisha kufanya marekebisho yanayofaa.

Kwa kuratibu kazi za chinichini mara kwa mara na kurekodi tofauti kati ya muda uliotarajiwa na muda halisi wa utekelezaji, tunaweza kupima kwa majaribio ucheleweshaji wa upangaji wa kitanzi cha matukio kwa wakati halisi. Matumizi yakiwa juu na kukiwa na kazi nyingi ghali, hata idadi ndogo ya maombi yanayotekelezwa kwa wakati mmoja kwa kila mchakato inatosha kusababisha mtikisiko mkubwa wa upangaji—hadi mamia ya milisekunde na, katika baadhi ya hali za kipekee, sekunde kadhaa.

Kwa hiyo, kila mchakato tunauwekea idadi ndogo tu ya maombi ya wakati mmoja, huku tukiongeza sana idadi ya michakato ya wafanyakazi wa Python.

Katika uzinduzi wetu wa kwanza, uchanganuzi wa CPU wa huduma halisi ulitusaidia kugundua chanzo kimoja cha ucheleweshaji mkubwa wa asyncio—na hivyo ukawivu mkubwa wa mwisho: uchanganuzi wa mara kwa mara wa JSON wa mipangilio yetu ya swichi ya vipengele kupitia Statsig (zana ya kudhibiti swichi za vipengele, kuendesha majaribio ya A/B na mengineyo).

Kwa chaguo-msingi, Statsig iliwekwa kuomba mipangilio iliyosasishwa kila dakika bila mtikisiko wa muda, na mipangilio hiyo ilijumuisha kila kanuni ya uzalishaji katika kila huduma. Kwingineko, uamuzi wa usanifu ulifanywa wa kuendesha hadi michakato 8 ya Python kwa kila pod ili kuongeza matumizi ya CPU na kupunguza ukawivu. Kwa pamoja, hii ilimaanisha kuwa kila dakika, kila pod ingefikia wakati ambapo wafanyakazi wake wote wangesimamisha uchakataji wa maombi yaliyokuwa yakiendelea na kutumia mizunguko ya CPU kuchanganua faili kubwa ya mipangilio.

Suluhisho lilikuwa rahisi baada ya uchanganuzi wa CPU kutusaidia kubaini chanzo: kusambaza mipangilio midogo iliyolengwa, kuongeza muda kati ya masasisho na kuongeza mtikisiko fulani wa muda kwa kazi kama hizi za chinichini.

Ili kudumisha ucheleweshaji mdogo wa asyncio, ni muhimu pia kusawazisha vizuri mzigo wa maombi katika michakato ya seva; bila marekebisho, ukusanyaji wa miunganisho unaweza kufanya kinyume chake.

Kwa ukusanyaji wa miunganisho upande wa mteja, mchakato mmoja wa mteja unaotuma maombi mengi kwa wakati mmoja unaweza kuanzisha miunganisho michache tu ya seva na hivyo kuelekeza mzigo wake wote kwa michakato michache tu. Kabla ya kurekebisha usawazishaji wa mzigo, matumizi ya huduma yetu yalitofautiana sana, huku baadhi ya michakato ya mwisho ikihudumia maombi ya wakati mmoja mara 5–10 ya wastani.

Tuligundua hili katika tukio la bahati, ambapo licha ya kusimamisha mteja aliyekuwa akilemea sehemu ya huduma yetu, baadhi ya michakato iliendelea kudhoofika kwa muda mrefu baada ya ongezeko la ghafla la trafiki. Kwa kweli, tuliona michakato hiyo ikiendelea kudhoofika bila kudhibitika, ikipokea maombi mengi zaidi hadi tulipoianzisha upya. Pod ilipolemewa, tabia fulani ilielekeza trafiki zaidi kwenye pod hiyo iliyolemewa. Hii ilikuwa aina ya hitilafu ambayo baadhi ya wenzetu waliifahamu vizuri kutokana na kazi ya awali: hitilafu ya metastable⁠(fungua katika dirisha jipya).

Tulishuku mkusanyiko wa miunganisho, na tukajaribu dhana hiyo kwa kuweka kikomo cha juu cha muda wa kutumia tena muunganisho; hatua hiyo ilipunguza udhaifu na kuthibitisha mwelekeo wa uchunguzi wetu. Uchunguzi zaidi ulibaini kuwa TCPConnector ya aiohttp ya Python hutumia LIFO kwa chaguo-msingi kutumia tena miunganisho: muunganisho uliorudi hivi karibuni huchaguliwa kwa ombi linalofuata. Kwa kawaida hili ni chaguo-msingi linalofaa: kutumia tena miunganisho ya karibuni huruhusu miunganisho ya ziada iliyoundwa kushughulikia ongezeko la ghafla la trafiki kufungwa baada ya kutotumika, na kupunguza gharama ya kuidumisha. Katika hali hii, ilitusababishia hitilafu ya metastable. Wakati wa ongezeko la ghafla la maombi, maombi kwa seva polepole zilizolemewa yalirudisha miunganisho kwenye mkusanyiko baadaye, hivyo ikachaguliwa mara nyingi zaidi na maombi yaliyofuata na kuelekeza trafiki zaidi hatua kwa hatua kwenye pod zilizokuwa tayari zinatatizika. Kurekebisha mkusanyiko wa miunganisho utumie FIFO kulivunja mzunguko huu wa mrejesho na hata kupunguza tofauti ya maombi katika hali yetu thabiti.

Leo, kwa kiasi kikubwa tunategemea Istio na Envoy kutoa ukusanyaji wa miunganisho na mikakati bora ya kusawazisha inayozingatia mzigo wa seva katika miundombinu yote ya OpenAI, hivyo kuepuka tatizo hili kabisa.

Athari moja ya kuboresha ucheleweshaji wa asyncio uwe mdogo na kuwa na michakato mingi sana ya Python ni kwamba inakuwa rahisi kulemea vitegemezi vya chini kwa idadi kubwa ya miunganisho, hali inayojulikana kama “kundi linalovamia kwa pamoja”.

Usambazaji wa kawaida wa kila siku—usiporekebishwa uwe wa polepole—unaweza kusababisha mabadiliko makubwa ya matumizi ya CPU kutokana na miunganisho kufungwa na kufunguliwa upya. Au uvujaji wa miunganisho unaweza kuangusha mtandao kwa kuijaza lango la NAT. Matatizo haya hutokea pia katika huduma nyingine, lakini kiwango cha kuyaanzisha hupungua sana unapokuwa na michakato mingi zaidi kwa kiwango cha mara kumi, ambayo mara nyingi hujaza rasilimali za mtandao ambazo wateja hawatarajii kuhitaji kushughulikia katika hali thabiti kwa kuzingatia utendaji pekee.

Pia tunategemea Envoy kuongeza ujumuishaji wa miunganisho yetu. Tunaitumia kusasisha miunganisho ya HTTP/1 ya Python kuwa HTTP/2 ili kufaidika na kugawa mitiririko mingi kwenye muunganisho mmoja, kisha kukusanya miunganisho hiyo na kuongeza muda wake wa kudumu. Envoy pia hutupa sehemu moja ya kutekeleza vikomo vya kiwango na vivunja mzunguko ambavyo vingekuwa na ufanisi mdogo katika kila mchakato wa Python unaojitegemea.

Sababu moja iliyotuwezesha kupanua Python kufikia kiwango hiki ni API ya Habitat yenye mipaka, ambayo huweka gharama ya ombi iwe ya kutabirika. Badala ya kuruhusu wateja kuunda hoja zozote za SQL zinazoweza kuchanganua majedwali makubwa au kuunganisha majedwali mengi, Habitat hutoa API rahisi ya NoSQL. Kutokuwa na API yenye nguvu ni uamuzi wa wazi wa uwiano katika muundo wa Habitat.

Tunalenga kuboresha maombi rahisi, yanayotabirika na yenye kiasi kisichobadilika cha kazi. Kwa uzoefu wetu, mifumo hii ni rahisi zaidi kupanua na ni vigumu kuikosea au kuitumia vibaya. Maombi yenye mtawanyiko usiotabirika ni hatari kiutendaji: hutatiza utengaji na usawazishaji wa mzigo, na huleta ongezeko la ghafla la ukawivu ambalo ni vigumu kulidhibiti kwa kupanua huduma na wateja wake.

Kabla ya kuhamia Habitat na Azure Cosmos DB, data nyingi za mtandaoni za OpenAI zilihifadhiwa katika Postgres. Wakati huo ilikuwa rahisi kukagua mabadiliko yote ya hoja na kielezo ili kuhakikisha yalifanya kazi vizuri na yalitumia data yenye faharasa kabla ya kutumwa uzalishaji. Timu na bidhaa zilipokua, hili lilishindikana kudhibiti haraka na likawa chanzo cha mara kwa mara cha kukatika kwa huduma, ambapo hoja moja mpya na ghali kwenye njia inayotumiwa sana iliangusha hifadhidata.

Tatizo ni kutolingana kwa gharama: ni rahisi na nafuu kuandika hoja za SQL ambazo ni ghali na ngumu kuendesha. Katika Habitat, tunaepuka hili na kufanya hoja ghali zionekane wazi kabisa upande wa mteja. Hakuna hoja zisizo na kikomo zinazoweza kuilemea Habitat, na miunganisho tata pamoja na upitiaji wa grafu huhitaji timu za bidhaa kufanya baadhi ya kazi nzito, jambo linalosaidia kuboresha miundo iwe bora zaidi kwa ujumla.

Habitat hutoa API ya NoSQL iliyoundwa kwa kuzingatia aina za vitu na viungo vinavyofafanuliwa na mteja, ikiongozwa na TAO⁠(fungua katika dirisha jipya). Wateja hufafanua mapema vitu, viungo na jinsi vinavyohusiana, lakini si maudhui ya kila aina. Mahusiano yanayotokea hufanana na grafu, lakini Habitat yenyewe haitumii hoja za kawaida za upitiaji wa grafu isipokuwa kuuliza viungo vya moja kwa moja vya kitu fulani.

Tunagawa grafu hii ili kila kitu na viungo vyake viwekwe pamoja katika sehemu ya kiwango cha hifadhi, lakini hatufanyi juhudi maalumu katika kiwango cha hifadhidata kuweka pamoja vitu na vitu vya mbali vinavyoelekezwa na viungo vyake. Matokeo yake ni kwamba muundo hugawanyika kwa urahisi ili kupanuka kwa mlalo, lakini upitiaji wa grafu hauna ufanisi kwa sababu hatua yoyote kati ya vitu inaweza kuhitaji kuchota data kutoka akaunti mbili tofauti kabisa za Azure Cosmos DB zilizo katika maeneo tofauti.

Kwa wateja wenye mahitaji tata zaidi ya kuuliza data, tunatoa mwonekano wa pili wa Habitat wa nje ya mtandao kupitia Rockset. Tunatumia kunasa mabadiliko ya data (CDC) kutiririsha mabadiliko kutoka hifadhi ya mtandaoni kwenda katika mifano ya Rockset iliyotengwa, karibu na wakati halisi. Kila timu ya mteja inawajibika kupanua mfano wake wa Rockset kulingana na mahitaji yake tata ya kuuliza data.

Utoaji huu wa Rockset huongeza usumbufu kwa wateja wetu, lakini tunaamini ni uwiano unaofaa kwa sasa: kufanya hoja rahisi kuwa chaguo-msingi huku tukitoa njia mbadala kwa wanaohitaji hoja tata. Muundo huu hutenga hifadhi yetu ya mtandaoni na mizigo ya uchanganuzi na utafutaji yenye usomaji mwingi.

Kuahirisha kwa mwaka kuandika upya Python kulitupa nafasi ya kuzingatia changamoto za haraka na zenye athari kubwa zaidi wakati wa ukuaji wetu wa kasi sana. Jukwaa lilipokomaa na ukuaji wetu kuendelea kuongezeka kwa kasi—huku huduma hii ikiwa ya pili kwa idadi ya core katika OpenAI na ya nne kwa matumizi yetu ya Envoy—hatimaye ulikuwa wakati wa kuachana na Python. Katika kilele chake, Python ilitusaidia kuhudumia zaidi ya maombi milioni 20 kila sekunde.

Katika robo ya pili ya 2026, kwa wahandisi 2 tu, Codex na GPT‑5.5, tuliweza kuandika upya huduma nzima kwa Rust. Huduma hii mpya ya Rust sasa hushughulikia asilimia 95 ya maombi yetu ya uzalishaji; tutaondoa Python kabisa katika wiki zijazo. Data yetu inaonyesha huduma ya Rust hutumia CPU kwa ufanisi mara 6 zaidi na kumbukumbu kwa ufanisi mara 15 zaidi kuliko toleo la Python, huku ikiwa na ukawivu wa wastani na wa mwisho ulio chini sana. Tunapanga kushiriki mafunzo zaidi katika blogu ijayo.

Huduma ya Python—na sasa Rust—ni kipengele kimoja tu cha Habitat. Katika sehemu ya pili ya mfululizo huu unaoeleza jinsi tulivyopanua kwa haraka hifadhi yetu ya mtandaoni ili kuhudumia zaidi ya watumiaji bilioni 1 wa ChatGPT, tutazungumzia safu ya hifadhi na jinsi Habitat inavyohudumia zaidi ya petabaiti 500 na maombi zaidi ya milioni 70 kila sekunde.

Ikiwa ungependa kufanya kazi kwenye mifumo ya OLTP kwa kiwango cha juu kabisa na unapenda aina hii ya uhandisi, tazama nafasi hii iliyo wazi katika timu yetu⁠.