MongoDB-ni Bilməməyin Dəyəri – Giriş

Bu seriyanın əsas məqsədi MongoDB-ni düzgün istifadə etməklə əldə edə biləcəyiniz əhəmiyyətli performans artımlarını və qənaət edə biləcəyiniz xərcləri nümayiş etdirməkdir. Buna ən yaxşı təcrübələrə əməl etmək, tətbiqinizin spesifik ehtiyaclarını öyrənmək və bu məlumatları məlumatlarınızı effektiv modelləşdirmək üçün istifadə etmək daxildir.

Bu potensial qazancları göstərmək üçün nümunə bir tətbiq təqdim edəcəyik. Sonra bu tətbiq üçün müxtəlif MongoDB tətbiqlərini inkişaf etdirəcək və yük testindən keçirəcəyik. Bu tətbiqlər müxtəlif MongoDB təcrübə səviyyələrinə xidmət edəcək: başlanğıc, orta, təcrübəli və heyrətamiz (🤯).

Bu seriyada istifadə olunan bütün kod və əlavə məlumatlar GitHub repozitoriyasında mövcuddur.

Tətbiq: Tranzaksiyalarda Fırıldaqçılıq Davranışının Aşkarlanması

Tətbiqin məqsədi maliyyə tranzaksiya sistemində fırıldaqçılıq davranışını müəyyən etməkdir. Bu, müəyyən bir istifadəçi üçün müəyyən bir zaman dövrü ərzində tranzaksiyaların statusunu təhlil etməklə həyata keçirilir. Mümkün tranzaksiya statusları bunlardır: approved, noFunds, pending və rejected. Hər bir istifadəçi 64 simvollu onaltılıq key dəyəri ilə unikal olaraq müəyyən edilir.

Tətbiq hər bir tranzaksiyanın təfərrüatlarını event sənədi vasitəsilə alır. Hər bir event sənədi bir istifadəçi üçün müəyyən bir gündə bir tranzaksiya haqqında məlumat ehtiva edir. Nəticədə, yalnız mümkün status sahələrindən birini ehtiva edəcək və bu sahənin rəqəmsal dəyəri 1 olacaq. Məsələn, aşağıdakı event sənədi key ...0001 olan istifadəçi üçün date 2022-02-01 tarixində baş vermiş pending tranzaksiyasını təmsil edir:

const event = {
  key: "0000000000000000000000000000000000000000000000000000000000000001",
  date: new Date("2022-02-01"),
  pending: 1,
};

Tranzaksiya statusları bir neçə keçmiş dövr üzrə hər bir statusun ümumi saylarını müqayisə etməklə təhlil edilir: oneYear, threeYears, fiveYears, sevenYears və tenYears. Bu cəmlər istifadəçi key və hesabatın son date tarixini təqdim etməklə tələb oluna bilən reports sənədində təqdim olunur.

Aşağıda key ...0001 olan istifadəçi üçün son date tarixi 2022-06-15 olan reports sənədinin nümunəsi verilmişdir:

export const reports = [
  {
    id: "oneYear",
    end: new Date("2022-06-15T00:00:00.000Z"),
    start: new Date("2021-06-15T00:00:00.000Z"),
    totals: { approved: 4, noFunds: 1, pending: 1, rejected: 1 },
  },
  {
    id: "threeYears",
    end: new Date("2022-06-15T00:00:00.000Z"),
    start: new Date("2019-06-15T00:00:00.000Z"),
    totals: { approved: 8, noFunds: 2, pending: 2, rejected: 2 },
  },
  {
    id: "fiveYears",
    end: new Date("2022-06-15T00:00:00.000Z"),
    start: new Date("2017-06-15T00:00:00.000Z"),
    totals: { approved: 12, noFunds: 3, pending: 3, rejected: 3 },
  },
  {
    id: "sevenYears",
    end: new Date("2022-06-15T00:00:00.000Z"),
    start: new Date("2015-06-15T00:00:00.000Z"),
    totals: { approved: 16, noFunds: 4, pending: 4, rejected: 4 },
  },
  {
    id: "tenYears",
    end: new Date("2022-06-15T00:00:00.000Z"),
    start: new Date("2012-06-15T00:00:00.000Z"),
    totals: { approved: 20, noFunds: 5, pending: 5, rejected: 5 },
  },
];

Yük Testi Metodologiyası

Hər bir tətbiq versiyasının performansını qiymətləndirmək üçün yük altında paralel işləmək üçün iki funksiya hazırlanmışdır:

1. Bulk Upsert: Event sənədlərini daxil edir.
2. Get Reports: Müəyyən bir istifadəçi key və date üçün reports sənədi yaradır.

Bu funksiyaların paralel icrası worker thread-lər istifadə edilərək həyata keçirilmişdir, hər birinə 20 worker ayrılmışdır. Hər bir tətbiq versiyası 200 dəqiqə ərzində test edilmiş və bu müddət ərzində müxtəlif icra parametrləri tətbiq edilmişdir.

Bulk Upsert Funksiyası

Bulk Upsert funksiyası qeydiyyat üçün 250 event sənədindən ibarət partiyalar alır. Adından göründüyü kimi, bu qeydiyyatlar MongoDB-nin upsert funksionallığından istifadə edilərək həyata keçirilir ki, bu da sənədi yeniləməyə cəhd edir və ya yeniləmə əməliyyatından alınan məlumatlardan istifadə edərək mövcud deyilsə yenisini yaradır. Hər bir Bulk Upsert iterasiyası vaxtlanır və müddəti ikinci dərəcəli verilənlər bazasında qeyd edilir.

Partiya emal sürəti cəmi 200 dəqiqə olmaq üzrə dörd 50 dəqiqəlik fazaya bölünür. Sürət saniyədə bir partiya daxil etməklə başlayır və hər 50 dəqiqədə saniyədə bir partiya daxil etmə artırılır, son nəticədə saniyədə dörd partiya daxil etməyə (saniyədə 1000 event sənədinə ekvivalent) çatır.

Get Reports Funksiyası

Get Reports funksiyası hər icrada bir reports sənədi yaradır. Hər icranın müddəti vaxtlanır və ikinci dərəcəli verilənlər bazasında qeyd edilir.

reports yaratma sürəti dörd Bulk Upsert fazasının hər birində 10 alt-faza olaraq paylanmış 40 fazaya bölünür. Hər Bulk Upsert fazası daxilində Get Reports sürəti saniyədə 25 hesabat sorğusu ilə başlayır və hər beş dəqiqədə saniyədə 25 sorğu artır. Bu, həmin Bulk Upsert fazasının sonunda saniyədə 250 hesabat sorğusuna çatır.

Aşağıdakı qrafik test ssenarisi boyu Bulk Upsert və Get Reports üçün hədəf sürətlərini göstərir:

İlkin Ssenari və Məlumat Yaradılması

Tətbiq versiyaları arasında ədalətli müqayisə üçün testlər üçün ilkin məlumat dəsti (işçi dəst) MongoDB serverindəki mövcud yaddaşdan böyük olacaq şəkildə dizayn edilmişdir. Bu yanaşma əhəmiyyətli keş fəaliyyətini təmin edir və bütün işçi dəstinin yaddaşda yerləşməsinin qarşısını alır.

İlkin məlumat dəsti üçün aşağıdakı parametrlər müəyyən edilmişdir:

• 10 il əhatə edən məlumatlar: 2010-01-01-dən 2020-01-01-ə qədər.
• İldə 50 milyon event, cəmi 500 milyon event işçi dəsti.
• İstifadəçi (key) başına ildə orta hesabla 60 event.

İldə 50 milyon event və istifadəçi başına ildə 60 event nəzərə alınanda, unikal istifadəçilərin ümumi sayı təqribən 833,333-dür (50,000,000 / 60). İstifadəçi key generatoru təqribən normal (Gauss) paylanmasına əməl edən açarlar yaratmaq üçün konfiqurasiya edilmişdir. Bu, bəzi istifadəçilərin digərlərindən daha çox event yaratdığı real dünya ssenarisi simulyasiya edir. Aşağıdakı qrafik yaradılmış 50 milyon açarın paylanmasını göstərir:

Real dünya ssenarisi daha da simulyasiya etmək üçün event statuslarının paylanması aşağıdakı kimi müəyyən edilmişdir:

• 80% approved
• 10% noFunds
• 7.5% pending
• 2.5% rejected

İlkin Ssenari Kolleksiya Statistikası

İnfrastruktur Konfiqurasiyası

MongoDB Server İnstansiyası

MongoDB serveri 2 vCPU və 4GB yaddaşla təchiz edilmiş AWS EC2 c7a.large instansiyasında işləyirdi. İki disk qoşulmuşdu:

• Əməliyyat sistemi üçün 15GB GP3 disk.
• MongoDB məlumat saxlaması üçün 10,000 IOPS ilə 300GB IO2 disk.

İnstansiya test zamanı tam yenilənmiş Ubuntu 22.04 işlədirdi. Mövcud avadanlıqda MongoDB performansını optimallaşdırmaq üçün bütün tövsiyə olunan istehsal parametrləri tətbiq edilmişdi.

Tətbiq Server İnstansiyası

Tətbiq serveri 4 vCPU və 8GB yaddaşla təchiz edilmiş AWS EC2 c6a.xlarge instansiyasında işləyirdi. İki disk qoşulmuşdu:

• Əməliyyat sistemi üçün 10GB GP3 disk.
• Yük testi metriklərinin saxlanması üçün istifadə olunan ikinci dərəcəli MongoDB serveri üçün 10GB GP3 disk.

Bu instansiya da tam yenilənmiş Ubuntu 22.04 işlədirdi. Performansını optimallaşdırmaq üçün tövsiyə olunan istehsal parametrləri tətbiq edilmişdi.