O'qish uchun optimallashtirilgan ma'lumotlar nusxasini saqlashning eng yaxshi usuli

Bir daqiqa ichida yuzlab mijozlardan turli xil operatsiyalarni bajaradigan tizim bor. Har bir bitim funktsiyaning bir to'plami bilan cheklangan va shuning uchun har bir tranzaksiyani (ulardan 25 tasi) alohida ma'lumotlar bazasi jadvaliga ega bo'laman (bu blok barcha mijozlarni ulash uchun kutadi). Ushbu mijozlar Windows-ning IIS-da ishlaydigan bir nechta C# veb-ilovalariga ulanishmoqda.

Ammo, biz ushbu bitimlarning aksariyat qismi bo'lgan ma'lumotlar yig'indisi uchun faqat o'qishga kirishni talab qilamiz. Hozirgi vaqtda ushbu o'qish jarayoni faqatgina sekinlashtiradigan SOL OUTTER JOIN jadvalining 14 ta jadvali. (Biz MS SQL serveridan foydalanmoqdamiz)

Mavjud fikrlash ma'lumotni saqlash va ma'lumotlarni o'qish uchun ma'lumotlarni yangilab turish uchun alohida jadval yaratish, ya'ni faqat o'qish uchun imkon qadar tez ishlash.

Eng barqaror va keng ko'lamli yondashuv nimani anglatadi?

Uni ko'rganim uch xil variant bo'lib, ulardan hech biri menga yoqmaydi:

  1. JB ishga tushiradi
  2. Ma'lumotlarni yangilash (muntazam yoki tetikli) bilan ishlaydigan fon xizmati (xizmat)
  3. Veb-saytimda ma'lumotlar yangilanadigan fon vazifasi yoqilgan.

EDIT: Ideal sifatida, PO'lar ma'lumotlarning 3 soniyadan ortiq eskirib qolgan bo'lishini xohlaydi. Biz 90 ta ustun bilan o'n minglab satrlar (100K dan kam) haqida gapiramiz.

0
Siz o'ylayotgan kontseptsiya "yig'iladigan jadval" deb ataladi, u odatda BI-da ishlatiladi. Unga borishning yo'li ma'lumotlar to'plamida boshqarish uchun ko'p narsaga bog'liq. Kichkina ma'lumotlar to'plamlari uchun odatdagi jadvallarni yangilash vaqtida umumlashtirilgan jadvalni yangilab borishingiz mumkin. (Tetiatni yoki kodni ishlatish.) Agar bo'lmasa, biron-bir fon xizmatiga o'tishingiz kerak.
qo'shib qo'ydi muallif Florian Margaine, manba

5 javoblar

Yana bir yondashuv, ma'lumotlar bazasini alohida o'qishga kirish uchun butunlay chetlab o'tish bo'lishi mumkin. Buni amalga oshirish uchun ma'lumotlar bazasini suratga olish va natijalarni faylga yozadigan fon jarayoni bo'lishi mumkin.

Faylning formati so'raladigan tomonga xizmat qilish uchun kerak bo'lgan narsaga bog'liq.

Bundan tashqari, agar siz yuqori imkoniyatga muhtoj bo'lsangiz, ikkita fayl bilan ishlashingiz kerak, ulardan bittasi o'qish/xizmat ko'rsatish va fon rejimida yozilgan bo'lishi kerak. Keyinchalik, yangilangan faylni o'rnini olish uchun yangilanish strategiyasidan foydalanishingiz mumkin (o'qish faylini temp faylga qayta nomlash, yangilangan faylni o'qish fayliga qayta nomlash va temp faylni o'chirish).

Shunday qilib, dasturiy ta'minotning qolgan qismiga ham, yozib olish ko'rsatkichiga ham minimal darajada ta'sir etuvchi eng yuqori o'qish tezligiga erishishingiz mumkin.

1
qo'shib qo'ydi
O'zining ma'lumotlar bazasini almashtirish uchun OPni majburlashda muammolarning hech biri yo'q.
qo'shib qo'ydi muallif mınxomaτ, manba
@ dan1111: Men rozi emasman. Savol, ma'lumotlarni tezkor ravishda olish haqida. Ma'lumotlar bazasini almashtirishni taklif qilmayman, lekin fayl tizimi keshini. Katta farq. So'rovlar qismi faqat ushbu javobga javoban keyinroq va taklifning o'zi aniq ko'rsatilmasdan taklif etiladi.
qo'shib qo'ydi muallif Jonathan van de Veen, manba
Ya'ni, asosan, keshni faylga joylashtirishni taklif qilyapsiz. Keyinchalik, ko'plab o'qish va yozish serverlarini birdaniga kirishga erishish bilan shug'ullanishimiz kerak, shundan keyin biz ichki struktura bilan shug'ullanishimiz kerak, va keyinchalik so'rovni bajarish qiyin bo'ladi, chunki agar biz 20K satrda qo'ng'iroq qilishni xohlasak bu faylni SQLda bajarishdan ko'ra ishlash yanada yomonroq yoki ko'proq xotira bo'ladi ...
qo'shib qo'ydi muallif Cyle, manba

yozish va o'qish operatsiyalarini va ularning tegishli do'konlarini ajratib, ushbu muammoni boshqa bir nuqtai nazarni berishga harakat qilaman. Bunga ko'proq chuqurroq kirib borishdan oldin katta qizil ogohlantirish: Siz ishlash uchun optimallashtirsangiz, shuningdek, tushunishingiz kerak ni tushunishingiz, ko'rib chiqishingiz va biznesingiz/operatsion menejerlaringiz bilan muhokama qilishingiz kerak bo'lgan murakkablik.

Yozish amaliyoti

As you mention your "transactions with a subset of functionality," these are your use cases/models for Yozish amaliyotis. This way, you can optimise the write models as your business drives you. Your write models could be still stored in your current RDBMS choice.

Bu erda birinchi muhim farq va qo'shilgan qiymat o'zingizga quyidagi imkoniyatlarni beradi:

  • Yozish mavzusini (va uning doimiy saqlanishini) o'qishlar bilan ajratish
  • Tajriba, jurnal yozish, audit, qulfni boshqarish, avtorizatsiya qilish, o'lchash va h.k. kabi o'zaro bog'liq muammolarni osongina qo'shish.

Sizning yozishmalaringiz asosan buyruqlar bo'lib, u sizning mijoz so'rovlaringizdan kelib chiqadi. Ushbu buyruqlar o'zingizning vaziyatni optimallashtirilgan modelni yozishni saqlab qolish do'koniga saqlash uchun barcha kerakli yuklarni o'z ichiga oladi.

Operatsiyani o'qing

Depending on your data structure and relations, read models are a way to store data in a denormalized way. As you wrote: a current Operatsiyani o'qing consists of 14 SQL joins, which could be a nightmare to deal with. This is where use-case optimised read models can step in.

O'qish modelingiz denormalizatsiyalangan ma'lumotlarga xizmat qiluvchi so'rovlar dir (ehtimol, alohida ma'lumotlar do'konidan). Alohida o'qish modellarini ishlatayotganda ishlash uchun optimallashtiradi, shuningdek, zarur murakkablikni ham qo'shasiz.

  • O'qish mavzusini yozma (va uning qat'iylik do'konidan) ajratish
  • Viktorina, jurnal yozish, audit, keshlash, avtorizatsiya qilish, o'lchash va h.k. kabi o'zaro faoliyatni kesib tashlashni osonlashtirish.

O'qilgan xotira ombori RDMS-dan hujjat DB lar va kalit-qiymatli do'konlar kabi tez NoSQL yechimlariga ega bo'lishi mumkin.

Ma'lumotlar do'konlari o'rtasida sinxronizatsiya

Buni amalga oshirish usullari: buyrug'i amalga oshirilganda, u o'qish do'konini qayta tiklashni boshlash uchun kerakli identifikatorlarning yukini o'z ichiga olgan voqea ni chiqaradi (yozish bilan sinxronlash uchun). tomon).

Fikringizda so'ragan savolga javob berish uchun, sinxronlashtirish, albatta, haqiqiy arxitekturaga bog'liq. Men, agar iloji bo'lsa, kodni tashqi manbalarga (masalan, tetikleyiciler, partiyalar ishi) chiqarishga qarshi emasman. Men teskarisini afzal ko'raman: barcha kodlarni iloji boricha iloji boricha chuqurroq qilib qo'ying (men to'g'ridan-to'g'ri nazorat qilishim kerak). Ma'lum bo'lganidek, ma'lumotlar manipulyatsiyasi uchun komandalar, voqealar va so'rovlarni ishlataman.

Aniq engil misol:

  1. A request is caught by an IIS-hosted WebApi or MVC controller.
  2. The Controller populates the respective command object with values from the request.
  3. A CommandHandler gets fired up from the Controller.
    • The command handler does its job storing the given write model
    • The command handler raises an event to notify the subscribers about the change
  4. An EventHandler, responsible for handling the event raised by the previous command handler, fires up a new command that's responsible for reconstituting the read store side.

Yuqoridagi fikrlarni umumlashtirish uchun: qo'lingizda sinxronlash oqimi bor va tetikler, NT xizmatlari kabi uchinchi tomon echimlariga bog'liq emas.

Qayd qilish kerak bo'lgan ba'zi narsalar:

  • Qo'mondon so'rovi ajratish xizmatiga rioya qilganimiz sababli, tekshiruv yoki kodni boshqaruvchi kodini o'zgartirmasdan, buyruqni tasdiqlash, tasdiqlash, jurnalga yozish va boshqalar bilan 2-bandni osonlik bilan bezashimiz mumkin.
  • Ehtimol, siz ushbu kichik tizimning qismlarini imkon qadar ajratish va sinovdan o'tkazish uchun kurashamiz. Bundan tashqari, tashvishlar ham qorishmasdan ajratiladi.

Sizning savolingiz "agar hodisani bajaruvchi o'lib qolsa nima bo'ladi?" qilish uchun gong bu biroz murakkab, "Vaqtinchalik mustahkamlik" va "xabar/voqea kuyruk" deb nomlangan yangi kontseptsiyalarni joriy qilish orqali. Greg Young:

Ko'p tizimda siz faqat o'qish sistemasi yozish tizimidan har qanday voqeani istagan darajada xohlashini bilishingiz mumkin.

Ushbu kontseptsiya ushbu javobni quyidagicha kengaytiradi:

  • Yozish tomonida sodir bo'lgan barcha voqealarni saqlash uchun joy.
  • Bu saqlangan hodisalardan o'tib, ularni o'qilgan tomonga qo'llaydigan navbat.

Xulosa

All this above is nothing new. I like to call this CQRS Lite - a term I have borrowed from Dino Esposito. He has a very comprehensive tutorial course on this at PluralSight. I wholeheartedly recommend that you watch it there, as there is a lot to learn from him. [1]

[1] Bu yerda, albatta, bu kurs pulli devorning ortida, ya'ni siz uni tomosha qilish uchun pul to'lashingiz kerakligini ta'kidlab o'tishni istardim va men PluralSight bilan biron-bir tarzda bog'lanmaganligimni tushuntirmoqchiman.

Bu borada boshqa yaxshi ma'lumot manbai quyidagicha: "https://lostechies.com/derickbailey/2010/03/08/cqrs-performance-engineering-read-vs-read-write-models/" rel = " Derik Baileydan "nofollow"> CQRS ishlash muhandislik: o'qish va boshqalarga o'qish/Yozish Modeli .

1
qo'shib qo'ydi
Kerakli ma'lumotlarning yangiligiga qarab, xuddi shu (yoki boshqa) ma'lumotlar bazasida denormalizatsiyalangan jadvallarda tungi ETL jarayonidan foydalanish mumkin. Kechasi ETL jarayoni keyinchalik kerakli vaqtda bajarilishi uchun optimallashtirilishi mumkin.
qo'shib qo'ydi muallif zzr, manba
@WindRaven Ma'lumot har bir soniyada mavjud bo'lishi uchun talab qilinadi, kecha har doim biz istagan joyda yaqin :)
qo'shib qo'ydi muallif Cyle, manba
@kayess Shunday qilib, bu ajoyib, lekin u allaqachon tushungan narsalarni qayta aytadi. Men uchun kalit o'rta bo'limi - sinxronizatsiya. Qanday qilaman buni ishonchli, tezkor va xatolarga chidamli qilib qo'yaman? Amaliy kod tarafidan - tetik, nt xizmati, ommaviy ish, nima? Klaviatura-do'konlarni ishlatish hazil bo'lib, men bu fayllar bilan ishlaydigan ob'ektlarni SET-ni taqdim etmoqchiman.
qo'shib qo'ydi muallif Cyle, manba
@kayess EventHandler o'qilgan do'kon yangilanishi (masalan, kompyuterni qayta ishga tushirish, iisreset, powerloss va h.k.) orqali o'lib qolganda nima qilasiz?
qo'shib qo'ydi muallif Cyle, manba

Javob quyidagicha bo'ladi:

  • If you have many updated datarows (i.e. > 100 000 rows per hour)
  • and if it is ok that the aggregated data is one days old

datawarehouses yoki "BI" tizimi tranzaksiyaviy ma'lumotlar bazasi (yozma operatsiyalar amalga oshirilganda) kuniga bir marta yangilangan ikkinchi tahlil bazasi dan foydalanadi.

Ushbu tahlil qilish jarayonida tranzaksiya bazasi bloklanmaganligi afzalliklarga ega.

0
qo'shib qo'ydi

Another option is to alter the code which updates the database to populate both tables.

Agar kod bazasi jadval populyatsiyasi atrofida mos darajadagi abstractionga ega bo'lsa, bu oddiy. yangilash amallari xatti-harakatlar sinfining, kutubxonaning yoki API ning bir nechtasida joylashgan. Siz ushbu plitani faqat tegishli joylarda emas, balki ikkita qo'shimcha/yangilanishni bajarish uchun o'zgartirasiz.

Agar sizda kodingiz bu ajralmaslikka ega bo'lmasa va ko'plab joylar to'g'ridan-to'g'ri ma'lumotlar bazasiga kiritilsa yoki yangilansa, unda bu oson bo'lmaydi. Biroq, bunday sariyog 'qatlamini kiritish mumkin bo'lgan echim bo'lishi mumkin. Siz bunga loyiqmi yoki yo'qligini bilish uchun yaxshi narx/foyda nazorat qilishingiz kerak.

0
qo'shib qo'ydi
@sitsman qulfni yengish mumkin bo'lgan muammo. Masalan, jadvalga oid yangilanishlar uchun navbat bo'lishi mumkin.
qo'shib qo'ydi muallif mınxomaτ, manba
@zaitsman Men buni tushunmayman. Joriy yangilanish operatsiyalari faqat kechiktirilmaydi, keyin quyidagi yangilanishlar o'qish jarayoni bilan kechiktiriladi?
qo'shib qo'ydi muallif mınxomaτ, manba
Kechirasiz, bu yaxshi emas. Bu holatda men bitta jadvalni ishlatish uchun barcha kodimni qayta yozishim mumkin, chunki bu erda bu muammo faqat o'qish uchun jadvalda qulflash bo'ladi.
qo'shib qo'ydi muallif Cyle, manba
Agar men buni qilsam, o'qish jarayoni ushbu navbatni bajarish uchun zarur bo'lgan umumiy vaqt bilan kechiktirilishi mumkin.
qo'shib qo'ydi muallif Cyle, manba
2 daqiqa ichida 10 k kelgan so'rovlarim bor. Jadvalni qulflashni oldini olish uchun yangilanishlar ketma-ketligini tuzadigan bo'lsam, unda men uchun 10K talabidan ma'lumotlarni olish mening barcha navbatim tugamaguncha kutish kerak. Bu mening talablarimga to'g'ri kelmaydi.
qo'shib qo'ydi muallif Cyle, manba

Materialized view may work for you here.

Samarali so'rovni qo'llab-quvvatlash uchun umumiy yechim ishlab chiqarishni tashkil qiladi   oldinga, ma'lumotlarga mos bo'lgan formatda ko'rinadigan ko'rinish   kerakli natijalar o'rnatildi. Materialized View modelida tasvirlangan   manba manbai bo'lgan joylarda ma'lumotlarning oldindan ko'rilgan ko'rinishini yaratish   ma'lumotlar so'rov uchun mos bo'lgan formatda emas, qaerda   muvofiq so'rov yaratish qiyin yoki so'rovlar bajarilishi   

</body>

0
qo'shib qo'ydi
@zaitsman So bu sahifasida amaliy yechim yo'q edi.
qo'shib qo'ydi muallif Flamewires, manba
Kechirasiz, bu ta'riflashga harakat qiladigan narsa - bu ma'lumotlarni saqlaydigan jadval. Biroq, ushbu MSDN sahifasida amaliy yechim yoki kod mavjud emas.
qo'shib qo'ydi muallif Cyle, manba
Iltimos, faqat tashqi manbalarga aloqador javoblarni joylashtirmang.
qo'shib qo'ydi muallif Andy, manba