MongoDB hadi Postgres

KUMBUKA: Chapisho hili la blogu ni muunganiko wa MongoDB hadi Postgres (2024-03-06) na Sequelize dhidi ya Prisma (2023-05-25). Blogu za awali zimeondolewa, na blogu hii imechukua nafasi yao kwa kuwa zote mbili zilikuwa na kimsingi maudhui/habari zilezile. Uhamiaji ulianza katika mapema Machi 2023, mabadiliko yalitokea katika katikati ya Novemba 2023, na matukio yote ya mfumo wa zamani wa MongoDB yalizimwa kabisa katika mapema Januari 2024.

Utangulizi

Wakati wangu katika eBay, nilikabiliana na kile kilichokuja kuwa tatizo lenye changamoto kubwa zaidi kiufundi katika kazi yangu: kuhama Mfumo wa Usimamizi wa Hifadhi (STMS) kutoka MongoDB hadi Postgres. Huu haukuwa tu ubadilishaji rahisi wa hifadhidata; ulikuwa mabadiliko kamili ya usanifu wa mfumo muhimu unaoingiza zaidi ya vipimo milioni 1.5 kwa dakika katika vituo vya data vya eBay, ukiwa na hitaji la kutokuwa na muda wa kukatizwa na kudumisha karibu utendaji wote uliopo.

STMS ni nini?

Mfumo wa Usimamizi wa Hifadhi (STMS) unatumika kama chombo muhimu cha ndani kwa timu ya Miundombinu ya Huduma na Hifadhi ya eBay (SSI). Unafuatilia na kusimamia vifaa katika vituo vya data vya eBay, ukiwaruhusu wahandisi:

  • Kufuatilia vipimo kutoka kwa safu kadhaa, swichi, wapangishi, makundi ya diski, na makundi
  • Kushughulikia tahadhari za swichi na safu
  • Kukamilisha kazi za hali ya juu kama ugawaji wa wapangishi
  • Kupata data ya wakati halisi kwa huduma nyingine za ndani za eBay

STMS inashughulikia zaidi ya safu 70, swichi 60, wapangishi 1100, makundi ya diski 900, na makundi 200 katika vituo 3 vya data vya eBay. Kwa kuzingatia jukumu lake muhimu katika miundombinu ya eBay, muda wowote wa kukatizwa au upotevu wa utendaji ungeathiri moja kwa moja huduma kuu za kampuni na shughuli za biashara.

Changamoto

Kwa nini Uhamiaji Ulikuwa wa Lazima

Uamuzi wa kuhama kutoka MongoDB hadi Postgres haukufanywa kwa pupa. Ingawa MongoDB ilikuwa imetumika vizuri kwa STMS mwanzoni, ugumu unaoongezeka wa uhusiano wa data zetu na hitaji la uwezo wa utafutaji uliosokotwa zaidi uliifanya Postgres kuwa suluhisho bora la muda mrefu kwa kesi yetu ya matumizi.

Nini Kilichofanya Tatizo Hili Liwe Gumu

Ugumu wa uhamiaji huu ulitokana na changamoto kadhaa za msingi:

1. Tofauti za Msingi za Hifadhidata
MongoDB na Postgres ni hifadhidata tofauti kimsingi. MongoDB ni hifadhidata ya msingi wa hati (NoSQL), ikimaanisha data huhifadhiwa kama JSON katika makusanyo, kama hati kwenye kabati la faili. Postgres ni hifadhidata ya kimahusiano (SQL), ikimaanisha data huhifadhiwa kama safu katika majedwali, kama kwenye lahajedwali.

2. Usanifu wa Kanuni za Msingi
Backend nzima ya STMS ilijengwa kuchakata na kusimamia data kama JSON, ikitumia vifurushi vinavyooana pekee na MongoDB kwa shughuli za hifadhidata. Hii ilimaanisha si tu kubadilisha hifadhidata, bali kupanga upya jinsi programu yetu nzima ilivyoshughulikia data.

3. Hitaji la Kutokuwa na Muda wa Kukatizwa
Kwa sababu STMS ni muhimu kiasi gani kama chombo cha ndani, hakukuwa na nafasi ya muda wa kukatizwa wakati wa uhamiaji. Mfumo ulilazimika kuendelea kuhudumia vipimo zaidi ya milioni 1.5 kwa dakika katika mchakato mzima.

4. Ratiba Fupi na Uzoefu Mdogo
Uhamiaji ulilazimika kukamilishwa ndani ya miezi michache, bila mpango dhahiri wa utekelezaji mwanzoni. Wala mimi wala wafanyakazi wenzangu hatukuwa na uzoefu wa kuhama kanuni kubwa ya urithi kutoka hifadhidata za NoSQL kwenda SQL, na nilikuwa na uzoefu mdogo wa awali na Postgres.

5. Kiwango na Ugumu
Uhamiaji ulihusisha kubadilisha makusanyo 36 ya MongoDB kuwa majedwali 74 ya Postgres, ukihitaji kuzingatia kwa makini uhusiano, uwekaji wa faharasa, na uboreshaji wa hoja.

Kuchagua ORM Inayofaa: Sequelize dhidi ya Prisma

Mojawapo ya maamuzi ya kwanza makubwa yalikuwa kuchagua zana ya ORM (Object-Relational Mapping). Kwa kuwa kanuni yetu tayari ilikuwa imeundwa kutumia Mongoose kwa MongoDB, kutumia ORM kungeleta njia laini zaidi ya mabadiliko.

Uchambuzi wa Mahitaji

Baada ya uchambuzi wa kina wa mahitaji ya mradi, niliweka vigezo muhimu kwa suluhisho lolote la ORM:

  • Lazima iwe kifurushi cha JavaScript (sehemu kubwa ya kanuni yetu iliandikwa kwa JavaScript)
  • Lazima iunge mkono Postgres na vipengele vingi vyake
  • Utendaji lazima uwe angalau sawa au bora kuliko Mongoose
  • Lazima iwe chanzo huria na itunzwe

Wagombea

Baada ya utafiti wa kina, nilipunguza hadi washindani wakuu wawili: Sequelize na Prisma. Niliunda mazingira ya majaribio ya kina kwa kutumia Docker kwa Postgres na kubadilisha seti yetu kubwa zaidi, ngumu zaidi ya data kutoka muundo wa hati kwenda muundo wa jedwali.

Mbinu ya Majaribio

Kwa kila ORM, nilipima utendaji katika shughuli muhimu:

  • Muda wa kuunda ingizo
  • Muda wa kusasisha ingizo
  • Muda wa kusasisha ingizo zilizo ndani (uhusiano na thamani-za-ufunguo za JSON)
  • Muda wa kufuta ingizo
  • Muda wa kuuliza/kupata ingizo

Uamuzi: Sequelize

Karibu tarehe 15 Mei 2023, niliamua kuwa Sequelize ndiyo ORM bora kwa kesi yetu ya matumizi. Hapa kuna sababu:

Faida za Sequelize:

  • Ni chanzo huria cha kweli na hakitunzwii na kampuni changa yenye ufadhili
  • Iliunga mkono vipengele vingi vya Postgres
  • Utendaji bora, hasa ikilinganishwa na Prisma
  • Mfumo uliokomaa wenye zaidi ya miaka 10 ya maendeleo
  • Uwiano wa modeli/skemani unaonyumbulika ukitumia madarasa ya JavaScript
  • Msaada kwa joins changamani na chaguzi za kuchuja ikijumuisha Regex

Matokeo ya Utendaji:

Katika majaribio yangu, Sequelize ilizidi Prisma kwa kiasi kikubwa. Kwa ingizo zetu kubwa za seti ya data:

  • Sequelize: ~sekunde 2.26 kwa ingizo
  • Prisma: ~sekunde 11.21 kwa ingizo

Prisma ilikuwa polepole takriban mara 5 kuliko Sequelize kwa kesi yetu ya matumizi. Zaidi ya hayo, kufuta ingizo moja kutoka kwenye seti yetu kubwa zaidi ya data kulichukua Prisma karibu dakika 4, jambo ambalo halikubalika kwa mahitaji yetu.

Changamoto za Sequelize:

  • Uwakilishaji wa modeli/skemani mgumu zaidi na wenye kupita kiasi (mistari 564 dhidi ya mistari 262 kwa Mongoose)
  • Sintaksia ya kutatanisha katika hali fulani
  • Ugumu wa uhamiaji wa hifadhidata
  • Nyaraka zisizojitosheleza ukilinganisha na Prisma

Ulinganisho wa Faida na Hasara za Sequelize na Prisma

Ili kutoa picha kamili zaidi ya kwa nini nilichagua Sequelize, ninataka kushiriki faida na hasara za kina nilizokusanya kwa ORM zote mbili wakati wa tathmini yangu. Pia niliangalia jinsi zilivyolingana kwa upande wa uwakilishi wa skema na msaada wa jamii kufikia tarehe 15 Mei 2023. Uchanganuzi huu wa kina ulinisaidia kuimarisha chaguo langu, na natumaini unaweza kuwa wa manufaa kwa mtu mwingine yeyote anayekabili uamuzi kama huo.

Faida za Sequelize:

  • Ina kazi ya sync() ambayo huunda na kushughulikia majedwali kiotomatiki kwa ajili yako, ikiokoa juhudi nyingi za mikono.
  • Inaweza kushughulikia joins changamani kwa data iliyowekwa ndani, ambayo ilikuwa muhimu kwa muundo wa STMS.
  • Inasaidia anuwai kubwa ya chaguzi za kuchuja, ikijumuisha Regex, ikitoa unyumbufu katika hoja.
  • Uwakilishi wa modeli/skemani hufanywa kwa JavaScript ghafi kwa kutumia madarasa, ambayo yanaweza kubinafsishwa sana ili kufaa mahitaji maalum.
  • Inashughulikia miunganisho ya hifadhidata bila mshono, ikijumuisha msaada kwa miunganisho mingi ya kusoma.
  • Inasaidia hoja za SQL ghafi wakati unahitaji kuangalia ndani ya mfumo.
  • Takwimu za jamii kufikia tarehe 15 Mei 2023: Kwenye NPM, ilisasaishwa mara ya mwisho siku 14 zilizopita ikiwa na vipakuliwa vya kila wiki 1,505,835; kwenye GitHub, ilisasaishwa mara ya mwisho jana ikiwa na Forks 4.2k na Stars 27.9k. Imekuwa chanzo huria chini ya leseni ya MIT kwa zaidi ya miaka 10, hivyo nina imani itabaki hivyo.

Hasara za Sequelize:

  • Uwakilishi wa modeli/skemani unaweza kuwa mgumu sana na wenye kupita kiasi. Kwa mfano, wakati uwakilishi wa Mongoose wa seti yetu kubwa ya data ulikuwa karibu mistari 262 (ikijumuisha nafasi), seti hiyo hiyo ya data katika Sequelize iliongezeka hadi mistari 564.
  • Sintaksia inaweza kuwa ya kutatanisha na changamano katika baadhi ya hali, jambo lililonipunguza kasi wakati mwingine.
  • Kuhama au kuhariri hifadhidata ni usumbufu. Hata na sequelize-cli ikizalisha hati za uhamiaji, bado ni nzito, ingawa nimegundua hili ni sehemu ya maumivu ya kawaida kwa ORM nyingi.
  • Nyaraka si nzuri sana, ingawa zinaboreshwa. Kwa bahati nzuri, zana kama ChatGPT zina uelewa thabiti wa Sequelize kutokana na historia yake ndefu, jambo lililosaidia kuziba mapengo.
  • Sio nyeti kwa aina za data kama Prisma, jambo ambalo linaweza kusababisha matatizo katika miradi fulani.
  • Msaada mdogo wa TypeScript, ingawa hili halikuwa jambo la wasiwasi kwa STMS, kwa wengine linaweza kuwa sababu ya kuamua.

Faida za Prisma:

  • Hutumia lugha yake ya skema, ikifanya uundaji wa modeli kuwa safi zaidi na mfupi zaidi. Kwa kulinganisha, wakati Mongoose ilichukua mistari 262 kwa seti yetu kubwa ya data, Prisma iliisimamia kwa mistari 221 pekee.
  • Inakuja na zana ya CLI inayorahisisha uundaji na uhamiaji wa hifadhidata, ambayo ndiyo bora zaidi niliyoona kutoka kwa ORM hadi sasa, hata ikiwa si kamilifu.
  • Inasaidia hoja za SQL ghafi, ikitoa unyumbufu inapohitajika.
  • Sintaksia ya kanuni ni safi na rahisi kueleweka ikilinganishwa na Sequelize, ikifanya iwe rahisi kujifunza.
  • Hutengeneza kiotomatiki wajenzi wa hoja kwa Node.js na TypeScript kupitia mteja wake, ambayo ni mguso mzuri.
  • Ina nyaraka bora, safi. ChatGPT haijasasishwa sana kuhusu Prisma, lakini nyaraka rasmi mara nyingi zilifidia hilo.
  • Takwimu za jamii kufikia tarehe 15 Mei 2023: Kwenye NPM, ilisasaishwa mara ya mwisho siku 6 zilizopita ikiwa na vipakuliwa vya kila wiki 1,344,705; kwenye GitHub, ilisasaishwa mara ya mwisho saa 3 zilizopita ikiwa na Forks 1.1k na Stars 31.3k.

Hasara za Prisma:

  • Haiungi mkono kuchuja kwa Regex kwa Postgres, ingawa inatoa njia mbadala kama “contains,” “includes,” na “startsWith.”
  • Utendaji ulikuwa tatizo kubwa katika majaribio yangu. Kuunda ingizo kwa seti yetu kubwa ya data kulichukua Prisma takriban sekunde 11.21 kwa ingizo ikilinganishwa na sekunde 2.26 za Sequelize, ikiwa polepole takriban mara 5.
  • Kufuta ingizo moja kutoka kwenye seti kubwa ya data kulichukua karibu dakika 4, jambo ambalo lilikuwa sababu ya kukatisha maamuzi kwa mahitaji yetu.
  • Hata kwa ulinganisho wa haki kwenye seti changamani ya data yenye uhusiano wa tabaka tatu, Sequelize ilikuwa haraka sana zaidi katika ufutaji.
  • Prisma inaungwa mkono na kampuni changa yenye ufadhili wa dola milioni 56.5. Ingawa kanuni yake kuu ya ORM ni chanzo huria chini ya Apache-2.0, nina wasiwasi kuhusu mabadiliko yanayoweza kutokea ya leseni baadaye, sawa na kilichotokea kwa MongoDB.

Ulinganisho huu wa kina ulifanya iwe wazi kuwa Sequelize ilifaa zaidi mahitaji ya STMS, hasa kwa utendaji na kutegemeka kwa muda mrefu. Lakini nilifikiri kuvunja suala hili kwa njia hii kunaweza kuwasaidia wengine wanaopambana na chaguo lile lile kwa miradi yao.

Mchakato wa Uhamiaji

Ubadilishaji wa Muundo wa Data

Kubadilisha kutoka muundo wa nyaraka wa MongoDB kwenda muundo wa uhusiano wa Postgres kulihitaji mipango makini. Ilinibidi:

  1. Kuchambua Mahusiano: Kutambua jinsi nyaraka za MongoDB zilivyohusiana zenyewe na kubuni mahusiano yanayofaa ya funguo za kigeni
  2. Kurekebisha Data: Kugawanya nyaraka zilizopachikwa ndani ya meza tofauti pale panapofaa
  3. Kuhifadhi Vipengele vya JSON: Kutumia safu wima za JSONB kwa data isiyo na muundo halisi iliyohitaji kubaki rahisi kubadilika
  4. Kubuni Faharasa: Kuunda faharasa zinazofaa kwa utendaji wa hoja

Suluhisho Maalum

Uhamiaji ulilazimu kuendeleza suluhisho kadhaa maalum:

1. Hati za Uhamiaji wa Data Niliunda hati za kina ili:

  • Kutoa data kutoka katika makusanyo ya MongoDB
  • Kubadilisha miundo ya nyaraka kuwa muundo wa uhusiano
  • Kuingiza data kwenye meza za Postgres zenye mahusiano sahihi

2. Safu ya Ulinganifu wa API Ili kudumisha kutokuwepo kwa muda wa kukatika huduma, nilijenga safu ya ulinganifu iliyoweza:

  • Kuelekeza maombi kwenda MongoDB au Postgres kulingana na hali ya uhamiaji
  • Kuhakikisha uthabiti wa data wakati wa kipindi cha mpito
  • Kutoa mifumo ya mbadala

3. Middleware Maalum Niliendeleza middleware kushughulikia tofauti katika jinsi MongoDB na Postgres zinavyoshughulikia baadhi ya operesheni, kuhakikisha mifumo iliyopo ya mwisho ya API iliendelea kufanya kazi bila marekebisho.

Kushinda Changamoto za Kiufundi

Kushughulikia Mahusiano Changamani

Mojawapo ya changamoto kubwa zaidi ilikuwa kubadilisha nyaraka zilizopachikwa za MongoDB kuwa mahusiano ya Postgres. Kwa mfano, nyaraka moja ya MongoDB inaweza kuwa na:

  • Sifa za msingi
  • Vitu vilivyopachikwa vinavyowakilisha huluki zinazohusiana
  • Safu za nyaraka zilizopachikwa

Hii ilibidi ivunjwavunjwe kwa uangalifu kuwa:

  • Meza za msingi kwa huluki kuu
  • Meza za kiunganishi kwa mahusiano ya wengi-kwa-wengi
  • Mahusiano ya funguo za kigeni kwa uhusiano wa mmoja-kwa-wengi

Uboreshaji wa Hoja

Mitindo ya hoja ya MongoDB haihamishwi moja kwa moja kuwa SQL. Ilinibidi:

  • Kuandika upya mnyororo changamani wa ujumuishaji kama viungio vya SQL
  • Kuboresha faharasa kwa mitindo mipya ya hoja
  • Kuhakikisha utendaji wa hoja ulifikia au kuzidi utendaji wa MongoDB

Uadilifu wa Data

Kuhakikisha uadilifu wa data wakati wa uhamiaji kulihitaji:

  • Hati za uthibitishaji za kina
  • Taratibu za kurejea nyuma
  • Ulandanishaji wa data wa wakati halisi wakati wa vipindi vya mpito

Matokeo na Athari

Uhamiaji wa STMS kutoka MongoDB kwenda Postgres ulikamilika kwa mafanikio bila muda wa kukatika huduma huku ukiendelea kudumisha karibu vipengele na utendaji wote. Matokeo yalizidi matarajio:

Maboresho ya Utendaji:

  • Utendaji wa hoja uliboreshwa kwa hoja changamani za uhusiano
  • Uthabiti na uadilifu bora wa data
  • Matumizi bora zaidi ya hifadhi

Manufaa ya Kiutendaji:

  • Uwezo ulioboreshwa wa ufuatiliaji na utatuzi wa hitilafu
  • Uunganishaji bora na zana zilizopo za eBay zinazotumia SQL
  • Taratibu bora za nakala rudufu na urejeshaji

Athari kwa Timu:

  • Uboreshaji wa maarifa ya timu kuhusu hifadhidata za uhusiano
  • Kuanzishwa kwa mifumo ya uhamiaji wa hifadhidata za baadaye
  • Uundaji wa zana na michakato inayoweza kutumika tena

Ujuzi wa Kiufundi Uliopatikana

Mradi huu ulipanua kwa kiasi kikubwa utaalamu wangu wa kiufundi:

Teknolojia za Hifadhidata:

  • Uelewa wa kina wa vipengele vya Postgres na uboreshaji
  • Uboreshaji wa hoja za SQL na urekebishaji wa utendaji
  • Mifumo ya usanifu wa hifadhidata na urekebishaji
  • Mipangilio ya hifadhidata ya msingi-kusubiri

Zana za Uendelezaji:

  • Sequelize ORM na ujenzi wa hoja
  • Mikakati ya uhamiaji wa hifadhidata
  • Mbinu za upimaji wa utendaji
  • Uthibitishaji wa data na ukaguzi wa uadilifu

Mifumo ya Usanifu:

  • Mikakati ya uhamiaji bila kukatika kwa huduma
  • Safu za ulinganifu wa API
  • Mifumo ya kuficha hifadhidata
  • Mifumo ya ufuatiliaji na tahadhari

Ukuaji wa Kibinafsi na Kitaaluma

Mradi huu wa uhamiaji ulikuwa wa kubadilisha sana maendeleo yangu ya kazi. Ulinitoa kwenye eneo nisilolijua, ukihitaji:

Ujuzi wa Uongozi:

  • Kuongoza mradi changamani wa kiufundi bila uzoefu wa awali
  • Kufanya maamuzi muhimu ya usanifu chini ya shinikizo
  • Kuratibu na timu na wadau mbalimbali

Uwezo wa Kutatua Matatizo:

  • Kugawanya matatizo changamani kuwa vipengele vinavyoweza kudhibitika
  • Kuendeleza suluhisho za ubunifu kwa changamoto zisizowahi kutokea
  • Kusawazisha mahitaji na vikwazo vingi vinavyoshindana

Mawasiliano na Ushirikiano wa Timu:

  • Kueleza dhana za kiufundi kwa wadau wasio wa kiufundi
  • Kurekodi michakato na maamuzi kwa rejeleo la baadaye
  • Kuwashauri wanatimu kuhusu teknolojia na mifumo mipya

Masomo Yaliyopatikana

Masomo ya Kiufundi

  1. Uteuzi wa Hifadhidata Una Umuhimu: Uamuzi kati ya NoSQL na SQL unapaswa kutegemea visa mahususi vya matumizi na mahitaji ya muda mrefu
  2. Upimaji wa Utendaji ni Muhimu Sana: Faida za kinadharia hazitafsiriwi kila mara kuwa ongezeko la utendaji wa ulimwengu halisi
  3. Mipango ya Uhamiaji: Mipango na upimaji wa kina ni muhimu kwa uhamiaji changamani
  4. Uwekezaji katika Zana: Kujenga zana sahihi mapema huokoa muda mwingi na hupunguza makosa

Masomo ya Usimamizi wa Mradi

  1. Mawasiliano na Wadau: Taarifa za mara kwa mara na mawasiliano wazi huzuia kutokuelewana
  2. Usimamizi wa Hatari: Kuwa na mipango ya mbadala na taratibu za kurejea nyuma ni muhimu
  3. Usimamizi wa Muda wa Ratiba: Weka muda wa ziada kwa changamoto zisizotarajiwa na mikondo ya kujifunza
  4. Nyaraka: Nyaraka za kina huwezesha uhamishaji wa maarifa na matengenezo ya baadaye

Hitimisho

Uhamiaji wa STMS kutoka MongoDB kwenda Postgres unasimama kama tatizo la kiufundi lenye changamoto kubwa zaidi na lenye kuridhisha zaidi ambalo nimetatua katika kazi yangu. Ulihisi si tu utaalamu wa kiufundi, bali pia uongozi, mipango, na uwezo wa kuzoea. Mafanikio ya mradi yalionyesha kwamba kwa mipango sahihi, upimaji wa kina, na kujitolea kwa ubora, hata changamoto changamani zaidi za kiufundi zinaweza kushindwa.

Uzoefu huu ulibadili kwa msingi jinsi ninavyoshughulikia uhandisi wa programu, ukisisitiza umuhimu wa:

  • Kuelewa muktadha kamili na mahitaji kabla ya kufanya maamuzi ya kiufundi
  • Kuwekeza muda katika zana na upimaji sahihi
  • Kudumisha mawasiliano wazi katika miradi changamani
  • Kuwa tayari kujifunza teknolojia na mbinu mpya inapohitajika

Mafanikio ya uhamiaji hayakuboreshi tu uwezo wa STMS bali pia yaliweka mifumo na michakato inayoendelea kunufaisha miradi ya miundombinu ya eBay. Yaliimarisha imani yangu kwamba kukumbatia changamoto zisizojulikana na kufanikiwa kupitia hizo ni ufunguo wa maendeleo ya kibinafsi na ya kitaaluma.

Nikirejea nyuma, mradi huu unawakilisha hatua ya mabadiliko katika kazi yangu, ukinibadilisha kutoka msanidi programu anayetekeleza suluhisho kuwa mhandisi anayeweza kubuni na kuongoza mipango changamani ya kiufundi. Kujiamini na ujuzi uliopatikana kutokana na uzoefu huu unaendelea kuniongoza katika mbinu yangu kwa changamoto na fursa mpya katika uhandisi wa programu.