So‘nggi olti oyda BigData va Data Lake loyihalari ko‘paydi. Dasturiy qismga tegmaymiz — u yerda har kim o‘zi xohlagan yechimni tanlaydi. Ammo uskunalar, bosqichlash va o‘lchamlash bo‘yicha bir xil xatolarga qayta-qayta duch kelamiz. Shu sababli buni alohida ko‘rib chiqishga qaror qildik.
Odatdagidek, hammasi aniq so‘rovdan boshlanadi. Buyurtmachi keladi: «bizga tahliliy platforma uchun 150 terabaytlik ma’lumotlarni saqlash tizimi (MST) kerak». 150 raqami qayerdan chiqqan? Fermaning sxemasini ochamiz — u yerda barcha virtual mashinalarning disklari qo‘shib chiqilgan, mana shunday yaxlit raqam paydo bo‘lgan.
Bu raqamning o‘zi hech narsani anglatmaydi. Uning ortida uchta savol yashiringan, va ularga javob topilmaguncha, har qanday spetsifikatsiya — taxmindan boshqa narsa emas. Bunday taxmin esa qimmatga tushadi: xato xaridda emas, olti oydan so‘ng, joy tugab, byudjet allaqachon sarflanganda ma’lum bo‘ladi.
Ma’lumotlar tabiati
Birinchi savol: umuman nima siqiladi
Massiv o‘ziga yetib kelgan narsa bilan ishlaydi. Virtual mashina ichida siqilgan yoki shifrlangan hamma narsa unga tayyor oqim sifatida keladi.
Oxiridan boshlaymiz, chunki bu uchta xatoning eng qimmatlisi.
Mantiq oddiygina: massiv o‘ziga yetib kelgan narsa bilan ishlaydi. Agar ma’lumotlar virtual mashina ichida siqilgan yoki shifrlangan bo‘lsa, massivga tayyor, yuqori entropiyali oqim yetib keladi — uni siqishga hojat qolmaydi. Na kompressiya, na kompaktatsiya yordam bermaydi, chunki ish allaqachon bir qavat yuqorida bajarilgan.
Batafsilroq ko‘rib chiqamiz, chunki bu yerda nozik jihatlar ko‘p.
Umuman siqilmaydigan narsalar. Ilova yoki OS darajasida shifrlangan hamma narsa — ma’lumotlar bazasini boshqarish tizimida (MBBT) TDE, VM ichida LUKS va BitLocker, obyekt xotiralarida SSE. Aniq 1:1, boshqacha bo‘lishi mumkin emas. Yaxshi shifr chiqishda statistik jihatdan tasodifiy oqimdan farq qilmaydigan natija beradi.
Doimo chalkashtiriladigan muhim eslatma: SED-disklar va tomlarni MSTning o‘zi tomonidan shifrlash koeffitsientga umuman ta’sir qilmaydi. Ular kompressiyadan keyin ishlaydi. Muammo faqat massiv darajasidan yuqorida sodir bo‘ladigan shifrlashda.
Keyingisi — allaqachon siqilgan formatlar: arxivlar, media, deduplikatsiya qilingan zaxira nusxalar. Bu yerda koeffitsient 1,0–1,05:1, va o‘lchamlashda ularga tayanib bo‘lmaydi.
Bunday platforma bo‘yicha o‘rtacha og‘irlikdagi koeffitsient 1,1–1,2 ga 1 ni tashkil qiladi. Sig‘im hisobida esa 2 ga 1 qo‘yilgan.
Begunoh ko‘rinsa-da, siqilmaydigan narsalar. Aynan shu yerda asosiy kutilmagan holatlar yashiringan.
ClickHouse. MergeTree ma’lumotlarni o‘z kodeklari bilan siqadi — sukut bo‘yicha LZ4, ko‘pincha ZSTD. Massivga tayyor holat tushadi. Kimdir hisobga 2:1 qo‘yadi, «axir bu ma’lumotlar bazasi-ku» deb — va ikki barobar xato qiladi.
Kafka. Prodyuserlarning compression.type parametriga bog‘liq. Snappy, lz4 yoki zstd bo‘lsa — mijoz tomonida siqilgan, massivga 1,05–1,15:1 to‘g‘ri keladi. None bo‘lsa — log segmentlari a’lo darajada siqiladi, 3–5:1. Bu og‘ir komponentlar orasida javob sizning foydangizga bo‘lishi mumkin bo‘lgan yagona holat. Boring va so‘rang.
Snappy yoki zstd bilan Parquet va ORC. Data lake-ning klassikasi, va shu bilan birga siqilmaslikning ham klassikasi. Agar sizda «obyekt xotira» deganda aynan shu narsa yotgan bo‘lsa — deduplikatsiyani o‘lchamlash omili sifatida unutib qo‘ying.
Sahifalarni ichki siqishga ega ma’lumotlar bazalari — Oracle Advanced Compression, HCC, SQL Server page compression. Alohida ayriq: ba’zan MBBTda kompressiyani o‘chirib, uni massivga topshirish foydaliroq bo‘ladi — bu server protsessoridagi yukni kamaytiradi. Ammo bu qaror majburiy unumdorlik testini talab qiladi, «keling, productionda sinab ko‘ramiz» emas.
A’lo darajada siqiladigan narsalar. Matnli loglar, Airflow va Superset metama’lumotlar bazalari, konfiguratsiyalar, manba kodlar — 3–10:1. Siqilmagan CSV, JSON, XML, dampalar. Jadval kompressiyasiz PostgreSQL. Bir xil turdagi virtual mashinalarning OS obrazlari.
Deduplikatsiya — alohida mexanizm, va u haqida ko‘pincha unutiladi. U siqilish qobiliyatidan mustaqil ishlaydi. Bitta shablondan yaratilgan ikki yuzta bir xil virtual mashina: har bir blok siqilmaydi, lekin bloklar takrorlanadi, va dedup ajoyib natija beradi. Aksincha — noyob, siqilmaydigan ma’lumotlar to‘plamini na kompressiya, na dedup oladi. U yerda halol 1:1, va hech qanday yetkazib beruvchi kafolati buni o‘zgartirmaydi.
Endi hammasi hisoblangan arifmetikaga o‘tamiz. Odatiy stekni oling: ClickHouse tugunlari, obyekt xotira, Kafka brokerlari. Normal loyihada bu ajratilgan hajmning taxminan 90 foizini tashkil qiladi. Va bu uchtasi ham ma’lumotlarni o‘zi siqadi. Yaxshi siqiladigan qism — metama’lumotlar bazalari, loglar, konfiguratsiyalar — bir necha foizni tashkil qiladi va umumiy koeffitsientga deyarli ta’sir qilmaydi.
Bunday platforma bo‘yicha o‘rtacha og‘irlikdagi koeffitsient 1,1–1,2:1 ni tashkil qiladi. Sig‘im hisobida esa 2:1 qo‘yiladi, chunki virtuallashtirish uchun odatiy o‘lchamlash vositasida shunday yozilgan. Bu ikki raqam orasidagi farq — aynan olti oydan so‘ng kimdir topadigan delta. Odatda buni spetsifikatsiyani imzolagan kishi emas, boshqa birov topadi.
Joylashtirish arxitekturasi
Ikkinchi savol: bu ma’lumotlar jismonan qayerda yotishi kerak
O‘z replikatsiyasiga ega dvijoklar lokal disklarda yashaydi. Massiv esa nosozlik yuz berganda tezkor almashish muhim bo‘lgan joyda kerak.
ClickHouse, Kafka, Greenplum, HDFS, Elasticsearch lokal disklar uchun loyihalangan. Ularning o‘z replikatsiyasi, ma’lumotlarni joylashtirish haqidagi o‘z tasavvuri, tugun nosozligidan keyin tiklashning o‘z mexanizmlari bor. Bu shared-nothing arxitekturasi, va u massiv haqida emas.
Agar bunday narsani umumiy MSTga joylashtirsangiz, ikki karra himoya olasiz: massivda RAID va dvijokning replikalari. Sig‘im ikki marta sarflanadi. Tor joy esa fabrikaga ko‘chib o‘tadi, u yerda klasterning barcha tugunlari bir xil portlar uchun raqobatlasha boshlaydi. Taqsimlangan tizim o‘rniga bitta umumiy nosozlik nuqtasi va bitta umumiy navbatga ega taqsimlangan tizim hosil bo‘ladi.
Aksi tez-tez unutiladi, va bu ham xato. Master-tugunlar, kataloglar, sxema reyestrlari, metama’lumotlar bazalari, virtual mashina obrazlari — ularga o‘tkazuvchanlik kerak emas. Ularga host nosozligida tezkor almashish, snapshotlar va bashorat qilinadigan tiklash kerak. Bu aynan massiv sotib olinadigan maqsad. Ularni lokal disklarda saqlash — deyarli bepul olinadigan HA dan o‘z ixtiyoringiz bilan voz kechish demakdir.
Bizning tomonlarda negadir oxirgi navbatda ko‘rib chiqiladigan obyekt qatlami haqida alohida. Bugungi kunda ClickHouse ham, Kafka ham, Greenplum ham, Spark ham sovuq ma’lumotlarni S3ga chiqara oladi. ClickHouse — S3 disk va saqlash siyosatlari orqali. Kafka — tiered storage orqali. Odatda bu hajm o‘sishini yopishning eng arzon usuli, va deyarli har doim u dastlabki muhokamadan chetda qoladi. Keyin esa ma’lumotlarning 60 foizi olti oydan beri tegilmagani, va ular uch baravar arzon QLC sig‘imda tinch yotishi mumkinligi ma’lum bo‘ladi.
Virtuallashtirish
Uchinchi savol: nimani virtuallashtirish kerak
Chegara mahsulot nomi bo‘yicha emas, balki talab qilinadigan o‘tkazuvchanlik va kechikishning ruxsat etilgan tarqalishi bo‘yicha o‘tadi.
Bu yerda halol «ha» yoki «yo‘q» javobi kamdan-kam uchraydi. Chegara mahsulot nomi bo‘yicha emas, balki talab qilinadigan o‘tkazuvchanlik va kechikish tarqalishi qanchalik muhimligiga qarab o‘tadi.
Metama’lumotlar bazalari, konnektorlar, orkestratsiya, reyestrlar, o‘z bandllariga ega Karaf, monitoring — ikkilanmasdan virtuallashtiriladi. Kirish-chiqish yuki past, jonli migratsiya, snapshotlar va tezkor tiklashdan olinadigan foyda esa boshqa hamma narsadan ustun turadi. Bu yerda bahslashadigan narsa yo‘q.
Greenplum segmentlari, DataNode, jiddiy yozish oqimi ostidagi Kafka, Elasticsearch data-tugunlari — odatda jismoniy serverlarda qoladi. «Ishlamaydi» degani uchun emas — ajoyib ishlaydi. Ammo dvijok NVMe-ga to‘g‘ridan-to‘g‘ri kirishga hisoblangan, gipervizor esa unga shartlar bilan bashorat qilinuvchanlikni qaytaradi. Testlarda farq ko‘rinmaydi, yuk ostidagi productionda esa ko‘rinadi.
Monitoring hammasi joyida ekanini ko‘rsatadi, lekin ishlash imkonsiz.
Bu ikki chekka orasida — eng katta va eng qiziqarli zona, unda hamma narsani sozlamalar hal qiladi. Va mana amaliyotdan kuzatuv: o‘rta zonadagi muammolar deyarli hech qachon resurs yetishmovchiligidan bo‘lmaydi. Ular vCPU overcommitidan va virtual mashinaning soketlar orasida taqsimlab yuborilganidan kelib chiqadi.
Alomat achinarli darajada tanish: rejalashtiruvchi kutish vaqti o‘sadi, protsessor yuklanishi esa kamtarona ko‘rinadi, barcha grafiklar yashil, foydalanuvchilar esa sakrashlardan shikoyat qiladi. Monitoring hammasi joyida ekanini ko‘rsatadi, lekin ishlash imkonsiz. Ready time va co-stop — birinchi navbatda qaraladigan narsa, oxirgisi emas.
Ikkinchi klassik manba — umumiy datastore. Tahliliy virtual mashina navbatni yeb qo‘yadi, yonida esa xuddi shu LUNda sezgir biror narsa yashaydi. Buni loyihalash bosqichida ajratish kerak, og‘riq boshlanganda emas.
Ma’lumotlar konveyerlari
Yordamchi qism: u haqida oxirgi navbatda eslashadi
«Palata bo‘yicha o‘rtacha» o‘lchamlash aynan yordamchi qismda buziladi: har bir komponentning o‘z talablar profili bor.
ClickHouse va Kafka haqida hamma eslaydi. Konveyerlar haqida esa deyarli hech kim — bu esa o‘nlab komponent, har birining o‘z xarakteri bilan.
Kafka Connect va Debezium. Tranzaksion bazalardan CDC oqimi. Diskga deyarli hech narsa kerak emas, ammo buferlar uchun xotira va barqaror tarmoq kerak. Agar overcommit qilingan hostga tushib qolsa, kechikishga qattiq zarba beradi.
NiFi. Mana kim tizimli ravishda kam baholanadi. Uning uchta repozitoriyasi bor — flowfile, content, provenance — va uchalasi ham faol yozadi. Oqim ostidagi content repozitoriysi kutilganidan yuqori IOPS yukini beradi. Provenance sezilmasdan o‘sadi va bir kuni diskni butunlay to‘ldiradi. Lokal NVMe, har bir repozitoriy uchun alohida tom, to‘lish darajasini kuzatish — bu dabdaba emas.
Apache Karaf va umuman OSGi-konteynerlar. Resurs jihatidan kamtarona, virtual mashinada ajoyib yashaydi. Haqiqatan kerak bo‘lgan narsa — tezkor qayta ishga tushirish va bandllarni joylashtirishdan oldingi snapshot, chunki tezkor orqaga qaytarish xohlagandan ko‘proq sodir bo‘ladi. Bu esa virtuallashtirishga qarshi emas, uning foydasiga dalil.
Airflow. Metama’lumotlar bazasi, vazifalar logi, DAG-lar. Resursni kam yeydi, ammo rotatsiya sozlanmagan bo‘lsa, loglar chiziqli va cheksiz o‘sadi. 200 gigabaytli Airflow metama’lumotlar bazasi shunchaki hech kim ishga tushirishlar tarixini tozalamagani uchun rejalashtiruvchini yiqitganini ko‘rganmiz.
Schema Registry, ZooKeeper, etcd. Hajmlari tiyin-tiyin, ammo ZooKeeper va etcd fsync kechikishiga juda sezgir. etcd ostida sekin disk — va klaster bekordan-bekorga liderni qayta saylay boshlaydi. Ularni «joy qolgan yerga» qo‘yib bo‘lmaydi.
Trino va Presto. Koordinator xotirjam virtuallashtiriladi. Workerlarga xotira va tarmoq kerak, spill uchun esa — lokal tezkor disk. Agar spill tarmoq tomiga uchib ketsa, og‘ir joinlar qovoqqa aylanadi.
Superset va Metabase. BI qatlami, metama’lumotlar bazalari kichik, ammo so‘rov keshlari o‘sib boradi. Virtual mashinaga qo‘yiladi, massivda yashaydi, savol tug‘dirmaydi.
Bu ro‘yxatning ma’nosi oddiy: «palata bo‘yicha o‘rtacha» o‘lchamlash aynan yordamchi qismda buziladi. Fermaning umumiy hajmini olib, serverlar soniga bo‘lib bo‘lmaydi. Bir komponentga xotira, ikkinchisiga IOPS, uchinchisiga esa mizer hajmda past fsync kechikishi kerak. Profillar bo‘yicha hisoblash kerak.
Uskunalar xaritasi
Endi uskunalar haqida: nima nimaga mos keladi
Platforma deyarli har doim bir necha turdagi uskunadan yig‘iladi. Bittasi bilan chegaralanishga urinish — muammolarning aksariyatining manbai.
Aniqlikka o‘tamiz, chunki mavhumliklar spetsifikatsiya imzolangunga qadar yaxshi.
Darhol aytib qo‘yamiz: platforma deyarli har doim bir necha turdagi uskunadan yig‘iladi. Bittasi bilan chegaralanishga urinish — bu yuqorida tasvirlagan muammolarning aksariyatining manbai.
Lenovo ThinkAgile HX (Nutanix) — yordamchi qism va platforma qatlami uchun.
Bu HCI o‘z kuchini namoyon qiladigan joy. Metama’lumotlar bazalari, Airflow, kichik konveyerlar uchun NiFi, Karaf, CDC-konnektorlar, reyestrlar, BI qatlami, master-tugunlar, dev va test konturlari. Boshqaruvchanlik, snapshotlar va tezkor tiklashda qadr topadigan, so‘nggi mikrosekundlarni siqib chiqarishda emas, hamma narsa.
Nutanix Unified Storage-ga alohida qarash kerak. U yerda S3 bilan mos obyekt qatlami bor, u tahlil uchun sovuq tirni aynan shu klasterda, alohida uskunasiz yopadi. Qo‘shimcha ravishda — umumiy ma’lumotlar to‘plamlari uchun Files va blokli kirish uchun Volumes. O‘rta platformalar uchun bu ko‘pincha alohida MST masalasini butunlay olib tashlaydi.
Dolzarbidan: Intel Xeon 6 asosidagi ThinkAgile HX650 V4 — shu qatlam uchun ishchi ot. HX650a V4 — agar shu klasterda inferens uchun GPU kerak bo‘lsa.
Lenovo ThinkSystem bare metal — dvijoklar ma’lumotlari uchun.
Shared-nothing bo‘lgan va diskka talabchan bo‘lgan hamma narsa: ClickHouse tugunlari, oqim ostidagi Kafka brokerlari, Greenplum segmentlari, DataNode, Spark va Trino workerlari, Elasticsearch data-tugunlari, model o‘qitish tugunlari.
2U shaklidagi SR650 V4 36 tagacha NVMe va 10 tagacha PCIe Gen5 slotini beradi — tahliliy tugun uchun bu zaxirasi bilan yetarli. Xeon 6 P-yadrolari bilan, soketga 86 tagacha yadro, MRDIMM va CXL qo‘llab-quvvatlanadi. Hamma narsa xotira va uning o‘tkazuvchanligiga bog‘liq bo‘lgan ClickHouse va Greenplum uchun bu sezilarli.
Ko‘pincha e’tibordan chetda qoladigan muhim nuqta: tahlil uchun eng tezkor protsessor emas, balki yadrolar, xotira va NVMe kanallarining to‘g‘ri muvozanati kerak. Disk kanallari yetishmasa, eng yaxshi protsessor ham ma’lumotni kutib turadi. Bu — diskda tejash protsessor uchun ortiqcha to‘lovni ma’nosiz qiladigan holat.
Lenovo DG Series (QLC, sig‘im) — sovuq qatlam, arxiv va zaxira nusxalar uchun.
ONTAP’dagi QLC-flesh. Sig‘im arzon, shu bilan birga hali ham flesh. Sovuq tir, NFS orqali umumiy ma’lumotlar to‘plamlari, zaxira nusxalarning maqsadli xotirasi uchun ideal joy. Massivning o‘zida S3 mavjud, bu esa sovuq ma’lumotlar uchun alohida obyekt xotirasi masalasini olib tashlaydi.
Amaliyotdan bitta nozik jihat: bu massivlarda foydali sig‘im xom sig‘imdan taxminan uchdan bir qismga kam — right-sizing, ADP-partitsiyalash, RAID-DP qo‘sh juftlik, WAFL zaxirasi. Bu korporativ darajadagi all-flash uchun normal holat, ammo buni pusk-naladkada emas, hisoblashning boshidanoq hisobga olish kerak. Va talab bilan bir xil birlikda hisoblash kerak: o‘lchamlash vositalari base-2 da hisoblaydi, imzo esa base-10 da qo‘yiladi, farq taxminan 10 foiz.
Lenovo DM Series (NVMe, unumdorlik) — tezlik va HA talab qiladigan narsalar uchun.
Master-tugunlar, kataloglar, metama’lumotlar bazalari, virtuallashtirish uchun datastorelar, kechikish muhim bo‘lgan umumiy ma’lumotlar to‘plamlari. Unified — ya’ni ham blok, ham fayl. O‘qitish uchun umumiy ma’lumotlarga tezkor NFS kerak bo‘lsa, bu — shu yerga.
Lenovo DE va DS Series (blokli SAN) — datastorelar va xizmat ko‘rsatuvchi MBBTlar uchun.
Klassik blokli kirish. DE — gibrid va all-flash bilan o‘rta segment, DS — blokli all-flash. Virtuallashtirish uchun datastorelar, xizmat ko‘rsatuvchi bazalar — fayl kirishi va ONTAP funksiyalari kerak bo‘lmagan joyda.
Nima qilmaslik kerak. Greenplum segmentlari va ClickHouse tugunlarini, qanchalik tez bo‘lmasin, blokli MSTga qo‘ymang. Metama’lumotlar bazalari va master-tugunlarni HA’siz lokal disklarda saqlamang. «Hammasi uchun» bitta massiv sotib olib, keyin nega tahlil sekinlashayotgani va zaxira nusxalash oynasiga sig‘may qolayotganini tushuntirib yurmang.
Xaridlarni bosqichlash
Bosqichlash haqida, boshlagan ekanmiz
Ma’lumotlar platformasi bosqichma-bosqich quriladi, xarid esa negadir uch yilga mo‘ljallangan bitta katta yetkazib berish sifatida rejalashtiriladi.
Alohida muammo — uskuna haqida emas, xuddi shu pul haqida.
Ma’lumotlar platformasi bosqichma-bosqich quriladi. Avval bir necha tugundagi stend va pilot, keyin production, keyin haqiqiy oqim uchun kengaytirish. Muammo shundaki, xarid negadir «uch yilga oldindan» bitta katta yetkazib berish sifatida rejalashtiriladi.
Natija bashorat qilinadigan: quvvatning yarmi birinchi yili bekor turadi va havoni isitadi, uchinchi yilga borib esa yuk profili o‘zgargani va butunlay boshqa narsa kerak bo‘lgani ma’lum bo‘ladi. Bunga qo‘shimcha ravishda uskuna eskiradi, kafolat esa ishga tushirish paytidan emas, yetkazib berish paytidan boshlab hisoblanadi.
Kengaytirilishni hisobga olib, joriy bosqich uchun aniq gorizont bilan olish oqilonaroq. Yaxshiyamki, HX ham, ThinkSystem ham, DG ham xizmatni to‘xtatmasdan tugunlar va disklar bilan bemalol kengayadi.
To‘g‘ri, bu yerda 2026 yilda odatdagidan balandroq yangraydigan qarshi dalil ham bor: sun’iy intellekt tufayli talab o‘sishi yetkazib berish muddatlarini bashorat qilib bo‘lmaydigan qildi. Uzoq o‘ylash qimmatga tusha boshladi. Shunday qilib, «hozir ortiqcha to‘lamaslik» va «keyin olti oy kutmaslik» orasidagi muvozanatni har kim o‘zi izlaydi. Ammo buni ongli ravishda izlash kerak, «zaxirasi bilan oldik, balki kerak bo‘lar» printsipi bilan emas.
Nazorat ro‘yxati
Spetsifikatsiyani hisoblashdan oldin nimani so‘rash kerak
Yaxlit raqamni himoya qilsa bo‘ladigan hisob-kitobga aylantiradigan olti savol.
Haftalab yozishmalarni tejaydigan qisqa ro‘yxat:
- Kodeklar. ClickHouse MergeTreeda nima o‘rnatilgan, Kafka prodyuserlarida qanday compression.type bor, obyekt qatlamidagi parquet nima bilan siqilgan.
- Shifrlash. TDE, LUKS, SSE bormi — massiv darajasidan yuqorida bo‘lgan har qanday narsa.
- Haqiqiy to‘lganlik. Bugun disklarga qancha yozilgan, ajratilgan emas. Farq odatda bir necha barobar bo‘ladi.
- O‘sish prognozi. Rejalashtirish gorizontida, komponentlar bo‘yicha taqsimlangan holda. 7 kunlik retensiyaga ega Kafka va uch yillik tarixga ega ClickHouse butunlay boshqacha o‘sadi.
- Kirish profili. Ma’lumotlarning qaysi qismi bir oy ichida haqiqatan o‘qiladi. Bu sovuq tir kerakmi degan savolga javob.
- Tiklash talablari. Har bir qatlam uchun RPO va RTO. Airflow metama’lumotlar bazasi va Kafkaning xom ma’lumotlari uchun ular boshqacha, ularni bir xilda himoya qilish esa ortiqcha to‘lovdir.
Siqilish bo‘yicha baholarni tekshirish qiyin emas: ko‘pchilik yetkazib beruvchilarda haqiqiy ma’lumotlar katalogi bo‘yicha ishga tushiriladigan va ko‘chirishdan oldin prognoz beradigan utilitalar bor. Bu joy nega tugagani haqidagi oylab davom etadigan tushuntirishlarga qarshi yarim kunlik ish.
Xulosa
Xulosa o‘rniga
So‘rovdagi yaxlit raqam — bu talab emas, bu alomat. U kimdir virtual mashinalar disklarini qo‘shib chiqqani va yuqoridagi olti savoldan birortasini ham bermaganini bildiradi.
Yaxshi xabar: oltitasi ham platforma jamoasi bilan bir necha uchrashuvda yopiladi. Yomon xabar: ularsiz har qanday spetsifikatsiya — hisob emas, garov. Va u qog‘ozda emas, productionda, olti oydan so‘ng, biror narsani o‘zgartirish allaqachon qimmatga tushganda tekshiriladi.
Ma’lumotlar platformasini rejalashtirayotgan bo‘lsangiz — yozing, aniq konfiguratsiyani birga ko‘rib chiqamiz. Bir yo‘la sizda haqiqatan qancha siqilishini ham hisoblab beramiz.