1. Masalaning boshlanishi: saqlash xarajatlari oshishi
Xizmat ko‘rsatish muddati uzaygan sari MongoDB saqlash hajmi ham doimiy ravishda oshdi.
Biznes talablariga ko‘ra allaqachon yaratilgan ma'lumotlarni o‘chirish mumkin emasdi, lekin barcha ma'lumotlarni oddiy saqlashda saqlash xarajatlari jihatidan yuk ko‘paymoqda.
Xususan, Online Archive uchun belgilangan ma'lumotlar to‘plami xizmatning asosiy ma'lumotlarini o‘z ichiga olgan va ma'lumotlar doimiy ravishda to‘plangan holda,taxminan 1.2TB darajasigacha oshdiedi.
Buning natijasida faqatgina saqlash xarajatlari masalasi emas, balki uzoq muddatli ma'lumotlarni boshqarish strategiyasini qayta ko‘rib chiqish kerak bo‘lgan vaziyat paydo bo‘ldi.
Shu sababli, ma'lum bir muddat o‘tgan ma’lumotlarni alohida saqlash joyiga ko‘chirish variantini ko‘rib chiqishga qaror qilindi va MongoDB Online Archive ni joriy etishga qaror qilindi.
- Yaratilgandan keyin 365 kun o‘tgan ma’lumotlar Online Archive ga ko‘chiriladi. -
Bu mezon ko‘rish naqshlarini tahlil qilish asosida nozik qilib ishlab chiqilgan qiymat emasdi, balki saqlash xarajatlarini optimallashtirish uchun operatsion siyosatga yaqin edi.
Shunga qaramay, Online Archive ning saqlash xarajatlarini kamaytirish afzalligi bor bo‘lsa-da, ko‘rish paytida boshqa xarajat strukturasini inobatga olish xususiyati bor edi.
Ya'ni,
nima arxiv qilinadi?
buning ustiga,
Arxiv qilingan ma'lumotlarni qanday ko‘rish kerak?
Bu vaziyat haqida birga o'ylash kerak edi.
2. Online Archive loyihalash
Archive siyosati quyidagicha tuzildi.
Archive mezoni: time maydoni bo'yicha 365 kun o‘tgan ma'lumot
Partitsiya tuzilishi: dataId → time
Haqiqiy xizmatning asosiy so'rov naqshlari quyidagicha bo'ldi.
Aniq bir dataId uchun umumiy ma'lumotlarni so'rov qilish
Shunga ko'ra, bir xil dataId ma'lumotlarini birinchi navbatda guruhlash imkonini berish uchun dataId ni oldingi kalit sifatida belgiladik va Archive mezoni bo'ladigan time ni keyingi kalit sifatida tuzdik.
Bu orqali haqiqiy so'rov naqshlari va Archive siyosatining muvofiqligini ta'minlashga maqsad qildik.
Shuningdek, Online Archive muhitida Partitsiya mezonlarini hisobga olgan holda so'rov qilish Data Scanned ni kamaytirishga yordam berishi mumkinligi sababli, xarajatlarni optimallashtirish nuqtai nazaridan ham muhim loyiha elementi deb hisobladi.
3. Archive boshqaruvi uchun indeks strategiyasi
Archive joriy etish jarayonida faqat Archive siyosatini aniqlab qolmasdan, balki Archive amalga oshirish jarayonini va haqiqiy so'rov naqshlarini hisobga olib indeksni tuzdik.
3-1. Archive maqsadlarini aniqlash uchun indeks
{ time: 1, dataId: 1 }Archive siyosati bo'yicha yaratilgandan so'ng 365 kun o'tgan ma'lumotlarni doimiy ravishda aniqlash zarur edi,
Archive maqsadli ma'lumotlarni samarali aniqlash uchun alohida indeks tuzdik.
3-2. Arxivdan keyin ko'rish uchun indeks
Xizmatning asosiy ko'rish patterlari dataId asosidagi to'liq ko'rish edi,
Online Archive’ning Partitsiyasi ham quyidagicha tashkil etilgan.
{ dataId: 1, time: 1 }Shunga muvofiq, birlashtirilgan Endpoint orqali Archive ma'lumotlarini birgalikda ko'rish holatlarini hisobga olib, Partitsiya tashkiloti bilan bir xil tartibdagi indekslarni yaratdik.
Bu orqali haqiqiy ko'rish patterlari va Archive tuzilmalari o'rtasidagi muvofiqlikni saqlashga harakat qildik.
Xulosa qilib, quyidagilarni aytishimiz mumkin.
|
Maqsad |
Indeks |
|---|---|
|
Archive maqsadni aniqlash |
{ time: 1, dataId: 1 } |
|
Arxivdan keyin birlashtirilgan ko'rish |
{ dataId: 1, time: 1 } |
4. Mavjud katta hajmdagi ko'rish API
Bizning xizmatimizda ma'lum identifikator bo'yicha to'liq ma'lumotlarni qaytaradigan API mavjud edi.
GET /data/{dataId}
Bu API oddiy qidirish API emas edi.
Qidirilgan ma'lumotlarni shunchaki qaytarishdan ko'ra, javob talablari bo'yicha ma'lumotlarni qayta ishlash jarayonini ham o'tkazish kerak edi.
MongoDB qidirish → javob ma'lumotlarini qayta ishlash → mijozga qaytarish
Shuningdek, ma'lumotlarning tarqalishi ham bir xil emas edi.
|
dataId bo'yicha ma'lumot hajmi |
soni |
|---|---|
|
odatiy holat |
o'nlab ~ minglab |
|
katta hajmdagi holat |
eng ko'pi bilan o'nlab minglab |
ya'ni, bir xil API bo'lsa ham, ma'lum dataId uchun katta ma'lumotlar ishlov berish zarur edi.
5. Mavjud qidirish usuli
Avvalgi usul OFFSET asosidagi takroriy qidirish usuli bo'lgan.
Masalan, quyidagi kabi struktura bo'lgan.
LIMIT 1000 OFFSET 0
LIMIT 1000 OFFSET 1000
LIMIT 1000 OFFSET 2000 ...Odatdagi MongoDB muhiti uchun katta muammolar bo'lmagan.
Biroq Online Archive joriy etilgandan soʻng, mavjud soʻrov usulining Archive muhitida ham mos kelishini qayta ko'rib chiqish zarur edi.
6. OFFSET asosidagi soʻrovni qayta ko'rib chiqish sabablari
Online Archive muhitida Data Scanned hajmi xarajatlarga ta'sir ko'rsatishi mumkin.
Ya'ni,
Data Scanned oshishi → soʻrov xarajati oshish ehtimoli
deganda, buni hisobga olish zarur edi.
Mavjud OFFSET asosidagi soʻrov kerakli joyga yetish uchun avvalgi ma'lumotlarga takroran kirishingizni taqozo qiladi.
Misol uchun,
LIMIT 1000 OFFSET 90000kabi soʻrovlar natijalarni qaytarish uchun oldingi 90,000 ta yozuvni o'tkazib ketishni talab qiladi.
Katta ma'lumotlarni bir necha marta bo'lib so'rash tuzilmasida bunday izlash xarajatlari takroran yuzaga keladi.
Archive muhitida bunday takroriy izlash Data Scanned oshishiga olib kelishi mumkin deb hisoblandik.
OFFSET → takroriy soʻrov → takroriy izlash yuzaga kelishi → Data Scanned oshishi → soʻrov xarajatining oshish ehtimoli
Nihoyat, mavjud OFFSET asosidagi soʻrov strategiyasini qayta ko'rib chiqishga to'g'ri keldi.
7. Cursor asosida soʻrovga oʻtish
Yangi soʻrov usuli sifatida Cursor asosidagi soʻrovni tanladik.
Spring Data MongoDBning Stream funksiyasidan foydalanib, ma'lumotlarni ketma-ket iste'mol qilish uchun tashkil etildi.
@Meta(cursorBatchSize = 3000)
Stream<DataDoc> streamByDataId(String dataId);Shuningdek, cursorBatchSizeni ham qo'lladik.
Ushbu misolda batchSizeni ishlatish sababi katta hajmdagi ma'lumotlarni bir vaqtning o'zida xotiraga yuklamaslik va ma'lum hajmdagi birliklar bilan iste'mol qilish edi.
Cursor → batch bo'yicha ko'rish → ketma-ket iste'mol → xotira ishlatish nazorati
Avvalgi tuzilma bilan taqqoslaganda quyidagicha.
OFFSET → takroriy ko'rish → takroriy qidiruv Cursor → ketma-ket ko'rish → yagona ko'rish oqimini saqlash
Archive muhiti uchun bu tuzilma xarajatlarni optimallashtirish nuqtai nazaridan yanada mos keladi deb hisobladik.
8. Mavzuni ko'rib chiqish
Ushbu tajriba orqali Online Archive joriy etish oddiy saqlash xarajatlarini qisqartirish emasligini tasdiqlash imkoniga ega bo'ldim.
Saqlash strategiyasi o'zgarganda, ko'rish strategiyasi ham qaytadan ko'rib chiqilishi kerak.
Xususan, xarajatlar tuzilmasi o'zgaradigan muhitda avvalgi usul doimo eng optimal deb hisoblanmaydi.
Ushbu misolda Archive siyosati, indeks tuzilishi, ko'rish naqshi, ko'rish strategiyasi ham birga hisobga olinishi kerak edi.
Saqlash xarajatlarini optimallashtirish
→ Online Archive joriy etish
→ Partition loyihasi
→ Indeks tuzilishi
→ Soʻrov narxini hisobga olish
→ OFFSET qayta ko'rib chiqish
→ Kursorga asoslangan soʻrovga oʻtish
Natijada, ushbu misol faqatgina kursorni qoʻllash toʻgʻrisida emas edi.
Saqlash xarajatlarini optimallashtirish uchun boshlagan ishlarim soʻrov xarajatlarini o‘ylab koʻrishga olib keldi va shu jarayonda mavjud soʻrov strategiyasini yana bir bor ko'rib chiqishga imkon berdi.
Infratuzilmaning o'zgarishi dasturiy ta'minotning soʻrov strategiyasini o'zgartirdi va bu orqali saqlash strategiyasi va soʻrov strategiyasining yaqin aloqada ekanligini bir bor his qildim.
Muvofiq
https://www.mongodb.com/docs/atlas/online-archive/
https://www.mongodb.com/docs/atlas/data-federation/billing/
https://www.mongodb.com/docs/manual/reference/method/cursor.skip/
yeop