Аналитика және BI серверлері: есептер мен витриналарға бейімдеу

BI және аналитика серверлерімен неше түрде қателеседі

BI инфрақұрылымы кенеттен баяулағанының басты себебі қарапайым: сервер әдемі демо-кестеге сай таңдалды, ал нақты жүктемеге емес. Соның салдарынан есептер минуттап ашылады, фильтрлер ілініп қалады, ал қолданушылар «кеше жылдамырақ еді» деп сенімін жоғалтады.

Көп жағдайда тар шеңбер үш бағытта: жад, дискілер немесе процессор. RAM жетіспейді, деректер кэштен ығыстырылады. Дискілер жүктемелер кезінде оқу/жазуды орындамай қалады, күндік есептер түнгі жаңартуларды күтуге мәжбүр болады. Немесе CPU жетіспей қалады — көп адам бір уақытта ауыр сұраулар мен есептеулерді бастағанда.

Мәселені күшейтетін тағы бір нәрсе — күтулер мен мақсаттардың айырмасы. Бизнеске күндіз жылдам есептер керек, ал IT командасы витриналарды түнде жаңартуды жоспарлайды. Егер бұл мақсаттар алдын ала бөлінбесе, түнгі жүктемелер ресурстарды «жеп» қояды, таңертең дашбордтар баяулайды, ал деректердің жаңалығы күмән тудырады.

Қазiргі квази-госсектор үшін тағы бір практикалық жайт: деректер көбіне жоспардан тез өседі. Қосымша көздер, тарихты сақтау талаптары, аудит үшін жаңа көрсеткіштер пайда болады. Егер сервер «нағыз сыйымдылыққа» ұсақ алынса, бір жылдан кейін ресурстарды қосу қажет болады — бұл жаңа тапсырыстар, келісімдер және үйлесімділік тәуекелімен байланысты.

Сатып алудан бұрын бірнеше сұраққа жауап берген жөн, сонда артық төлемсіз және қателіксіз дұрыс ресурс таңдайсыз:

• Пик сағаттарда қанша қолданушы бір уақытта есеп ашады және ең ауыр есептер қандай.\n- Қандай мақсатты SLA: «есеп 5 секундқа дейін» немесе «30–60 секунд күтуге болады».\n- Витриналар қашан және қалай жаңартылады: тек түнде ме әлде күндізгі жүктемелер бар ма.\n- Қанша жылға жабдықтың қызмет ету мерзімі жоспарланып отыр және деректердің өсуі қандай болады.\n- Не маңыздырақ: есептердің жылдамдығы, жүктемелердің жылдамдығы немесе теңгерім.

Практикалық мысал: егер ведомственная аналитика күндіз 50–100 қызметкерге қызмет көрсетсе, ал түнде бірнеше жүйеден жүктеу жүрсе, бір «универсалды» конфигурация жиі көңіл көншітпейді. Мұндай жағдайда рөлдерді бөлу (сұраулар және жүктеулер) немесе жад пен дискілерге резерв қалдыру жақсырақ.

Сондықтан жиі GSE S200 класты серверлерге қарайды — оларда витриналар мен параллельді сұрауларға масштабталуды алдын ала қарастыру оңайырақ.

Типтік схема: DWH, витриналар, ETL және BI-сервер

Серверлерді таңдау үшін тізбек ролдер жиынтығы ретінде қарастырған дұрыс, бір «үлкен жүйе» ретінде емес. Осының арқасында қай бөлім жылдам болуы тиіс және қай жерде қақтығыс пайда болатыны анық көрінеді.

Типтік схемаға әдетте төрт қабат кіреді:

• ETL/ELT: деректерді көздерден алып, тазалап, кестеге жүктейді.\n- DWH (хранилище): тарих пен «шикі» деректерді өңдеуге ыңғайлы түрде сақтайды.\n- Витрины данных: есептер мен көрсеткіштерге дайын жиындар.\n- BI-сервер: визуализация, дашбордтар, құқықтар, кэш және есептерді жариялау.

Тар жерлер барлық жерде бірдей емес, нақты бөлікте пайда болады. Түнде көбінесе жүктемелер қиындаса: ETL көп жазады және CPU-ды түрлендірулер үшін жүктейді. Күндіз — оқу және параллельдік басты мәселе: қолданушылар есептерді ашып, фильтрлейді, детализация алады және витриналарға көп параллельді сұраулар түседі. BI-сервер кэш үшін жадты «жеп» алып, базадан бөлек себепші бола алады.

Барлық тапсырмаға бір сервер көбінесе түнгі жүктемелер таңертеңгі есептерге кедергі келтіруімен немесе бір бөлімнің ауыр есебі басқаларын баяулатумен бітеді. Квази-госсекторда мұндай жағдай айрықша байқалады: қатал жаңарту терезелері мен бекітілген SLA бар.

Практикада рөлдерді былай бөледі:

• ETL және DWH жазбалар оқуына кедергі жасамас үшін бөлек орналастырылады.\n- Егер есептер көп және «ыстық» болса, витриналарды бөлек шығарады.\n- Қолданушылар көп болса және тұрақты жауап қажет болса, BI-сервисті бөлек узелде ұстайды.

Егер өсу жоспарланса, рөлдерді бөлу мүмкіндігін алдын ала қарастыру ыңғайлы: жүйенің логикасын өзгерте алмай, ғана узелдерді бөлуге болады.

Жүктеме профилдері: қандай болады және неге маңызды

BI сервері бір режимде сирек жұмыс істейді. Күндіз ол ондаған-мыңдаған сұрауларға жауап береді, түнде витриналарды қайта есептейді, кейде аналитиктердің жеке сұрауларын қабылдайды. Осы режимдерді араластырып қойсаңыз, қағазда «мықты» көрінген конфигурация нақтыда баяу болуы мүмкін.

Интерактивті есептер және дашбордтар — көп қысқа сұраулар. Жылдам жауап пен тұрақты кідіріс маңызды: қолданушылар орташа жылдамдықты емес, шыңдағы ілініп қалуды байқайды. Мұнда бір ядроға жақсы өнімділік, жеткілікті RAM кэш үшін және жылдам дискілер көмектеседі.

Пакеттік есептеулер және регламентті витриналар — түнгі терезелердегі ұзақ тапсырмалар. Мұнда параллельдік, дискілердің жоғары өткізу қабілеті және болжамдылық маңызды. Егер терезе орындалмаса, таңертең процеске әсер етеді.

Ад-хок аналитик сұраулары — болжанбас шыңдар. Бір сұрау үлкен кестеге ауыр агрегат жасай алады. Сондықтан CPU/RAM-ға резерв пен шектеулер (кезектер, приоритеттер) қажет, сонда эксперименттер интерактивті есептерді бұзбайды.

Есептеулер қай жерде орындалады: СУБД-де (join, агрегаттар, оконные функции) немесе BI құралында — бұл да маңызды. Көбірек логика СУБД-де болса — сервер базаға жоғары талап қояды. Калькуляциялар BI-де көп болса — BI-сервер жадпен қатты жүктеледі.

Егер ML модельдері немесе болжамдау қосылса, талаптар кеңейеді: көбіне көп RAM, оқыту таңдамалары үшін жылдам дискілер, параллель есептеу үшін ядролар көп және кейде GPU қажет.

Қарапайым тілмен талаптарды қалай жинау

Бастау CPU модельдері мен диск атауларынан емес, адамдар есептерді қалай қолданатынынан бастаған дұрыс. Осылай қайсысы маңыздырақ екенін — жауап жылдамдығы, түнгі жүктеме тұрақтылығы немесе өсуге резерв — тезірек түсінесіз.

Алдымен қолданушылар мен олардың әдеттерін анықтаңыз. «Барлығы қанша қызметкер» емес, «қай уақытта қанша адам бір уақытта жұмыс істейді» маңызды. Егер пик 10:00–12:00-де болса, дәл сол уақытта жүйе максималды жүктемені ұстап тұруы тиіс.

Келесі қадам — «қай есептер ауырады» анықтау. Қарапайым порогтарды келісіңіз: не 5 секундта ашылуы тиіс, не 30 секундта қабылданады, ал не 5 минуттық пакет тапсырма болуы мүмкін. Бұл конфигурацияға әсер етеді: интерактивті есептер мен ауыр қайта есептеулер әртүрлі бағытты талап етеді.

Қысқа карточкаға талаптарды жинау ыңғайлы:

• Пиктегі қатар жұмыс пен сағаттар (мысалы, 60 қолданушы, 10:00).\n- Критикалық есептер және мақсатты жауап уақыты (5/30/300 секунд).\n- Деректер көлемі қазір және 12–36 айға болжам (мысалы, 12 ТБ -> 25 ТБ).\n- Витриналарды жаңарту терезесі (мысалы, түнде 4 сағат).\n- Қолдау мен регламент шектеулері (24/7, SLA, сатып алу циклы).

Қазiргі квази-госсекторда регламенттер, ұзақ сатып алу циклдары және жергілікті қолдаудың қолжетімділігі маңызды. Сондықтан 2–3 жылға резерв қалдыру және сервис пен жөндеуді қалай ұйымдастыру керектігін алдын ала келісу орынды. Егер жергілікті өндірушілер мен сервисті қарастыратын болсаңыз, мысалы GSE.kz, бұл сұрақтарды ішкі ережелер аясында оңайырақ шешуге болады.

CPU: сұраулар, есептер және параллельдік үшін қалай таңдау

CPU тар шеңберге жиі бір ауыр есептен емес, бәсекелестіктен шығады: бір уақытта қолданушылар сұрау жасайды, витриналар жаңартылады және фондық есептеулер жүреді. Сондықтан қысқаша қандай режим жиі болатынын түсіну маңызды: қысқа интерактивті сұраулар көп пе немесе ұзақ пакет есептер ме.

Егер есептер жылдам ашылуы және фильтрлер «тірі» түрде жұмыс істеуі тиіс болса, әдетте күшті ядро және жоғары жиілік маңыздырақ. Егер түнде күрделі агрегаттар орындалып, күндіз көп параллельді сұраулар болса, көбіне ядро саны көп жүйе пайдалы болады.

Параллельдік және сұраулар бәсекелестігі

Сұраулар бәсекелестігі — бірнеше тапсырма біреуіне ядроларды талап еткенде пайда болады. Таңертең бір бөлім жиындар құрап жатқанда, басқа бөлім детализация тартып, сол уақытта витриналар жаңартылып жатса, орташа жылдамдықтағы көп ядро кейде жақсырақ, бірақ тек RAM пен дискілер иесіз қалмаса.

Сокеттер, NUMA және өсуге резерв

NUMA екісокеттік сервердің «екі жартысы» сияқты: ядролар өз локальды жадымен тез жұмыс істейді, ал басқа сокеттің жадысына кіру баяу жүреді. Сондықтан кідіріске сезімтал сұраулар үшін бір сокет пен жылдамырақ CPU екі сокеттегі баяу конфигурациядан тиімді болуы мүмкін.

Практикалық нұсқаулар:

• Интерактивті есептер үшін жиілік пен төмен кідіріс маңызды.\n- Витриналар мен көп қолданушылар жағдайда ядроларды көбейтіңіз.\n- CPU-ға кемінде 20–30% резерв қалдырыңыз жаңа есептер мен өсім үшін.\n- BI мен СУБД лицензияларын тексеріңіз: ядролар, сокеттер немесе қолданушылар бойынша лицензиялану мүмкін.\n- Екісокеттік платформаларды (соның ішінде GSE S200 деңгейіндегі серверлер) қарастырсаңыз, ПО-ның NUMA-пен қалай әрекет ететінін алдын ала біліңіз.

Жад: витриналар мен жылдам шығару үшін қанша RAM қажет

Аналитикада жиі CPU-дан бұрын RAM жетіспеу байқалады. Есептер мен дашбордтар қайталанатын сұрауларды, фильтрлерді және агрегаттарды жақсы көріп, бұл деректер базасының кэшінде болғанда жылдам жүреді.

Қажетті деректер «ыстық» түрде жадыда ұстау керек пе, жоқ па — қолданушылардың мінез-құлқынан көрінеді. Егер жұмыс уақытында бір витрина мен справочник бірнеше адамдар тарапынан жиі қайталанса — кэш айтарлықтай әсер береді. Егер есептер сирек және әрқилы болса, RAM маңызды, бірақ ғажайып күтпеңіз.

RAM жетіспеушілігін белгілері:

• swap белсенді болады (жад дискке шығарылады);\n- жылдамдық дәл пик сағаттарында құлдырайды;\n- бір есеп кейде жылдам, кейде кенет баяу;\n- ұқсас жүктеме кезінде диск оқу саны өседі.

Жадты «впритык» жоспарламаңыз. ОС пен сервистер орнатылғаннан кейін кэш үшін айтарлықтай резерв қалдырыңыз және деректер өсіміне 12–18 айға есептелген қор қосыңыз. Әйтпесе витриналар өскен сайын кэш сыймай қалады да, жүйе қайтадан дискіге сүйенеді.

BI-платформа белсенді кэш жасаса және база бір уақытта ETL-мен жүктеліп жатса, бөлек кэш немесе семантикалық қабат үшін бөлек сервер орнату орынды. Көбінесе ролдерді узелдерге бөлу жадты бір серверге шексіз қосудан жеңілірек болады.

Дискілер және сақтау жүйесі: жылдам сұраулар және тұрақты жүктемелер

BI-де жиі жылдамдық дискіге тіреледі. Қолданушы дашборд ашады, ал егер сервер деректерді ұзақ оқыса немесе уақытша файлдарда «ойланса», есеп процессор жақсы болғанымен де баяулайды.

Екі негізгі көрсеткіш бар. IOPS — секундқа шаққандағы шағын оқу/жазу операциялары саны. Өткізу қабілеті (throughput) — секундқа қанша дерек өтіп жатқандығы. Интерактивті есептерде кідірістер мен IOPS маңызды, түнгі жүктемелерде — өткізу қабілеті мен тұрақты жазба.

Сондықтан SSD, әсіресе NVMe, әдетте айтарлықтай әсер береді: есептер жылдамырақ ашылады, сұрыптау және агрегаттар үшін паузалар азаяды, жүктемелер тұрақты өтеді. Сыйымдылық маңызды, бірақ "үлкен бірақ баяу" массив көбіне "кіші бірақ жылдам" шешіміне жеңіледі.

Жад сақтау жүктемелерін бөліп орналастыру жақсы тәжірибе:

• кестелер мен витриналар — ең жылдам қабатқа;\n- транзакциялық журналдар — бөлек, тұрақты жазбаны қамтамасыз ететін жерде;\n- уақытша файлдар (temp, sort, spill) — жылдам дискіде;\n- резервтік көшірулар — бөлек, экономды және үлкен көлемде.

RAID таңдау тәуекел мен жазба сипатына қарай жүзеге асады. Деректер базалары үшін жиі RAID10 алады — жылдамдық пен тұрақтылық маңызды болған кезде. RAID5/6 сыйымдылықты арттыра алады, бірақ ауыр жазба мен қалпына келтіруге сезімтал.

Деректер өссе, көпқабатты сақтау көмектеседі: "ыстық" — ағымдағы витриналар үшін, "жылы" — сирек сұралатын периодтар үшін, "архив" — нормативтік сақтау үшін. Квази-госсекторда жиі соңғы 12–18 ай жылдам қабатта сақталады, ал ескі кезеңдер үшін жауап беру уақыты анық белгілі бір деңгейде ұсталады.

Желі, сенімділік және қалпына келтіру: алдын ала не тексеру керек

BI серверлері тек CPU себепті ғана баяулауы мүмкін емес. Желі және әлсіз қалпына келтіру схемалары да жиі мәселе тудырады, әсіресе таңертеңгі есептер қашықтағы көздер арқылы өтіп, түнгі жүктемелер жұмыс уақытынан кеш аяқталған кезде.

Желінің жылдам бағдары

10GbE әдетте жеткілікті, егер BI мен DWH бір-біріне жақын болса, жүктемелер орташа және резервтік көшіру түнде өтсе. 25/40GbE көші ортасына өту әдетте витриналар өсіп, параллельді қолданушылар көп болғанда, белсенді репликация немесе ауыр бэкаптар жиі болғанда қажет.

Желідегі типтік тар жерлер: көздерден шығатын шығарулар (файл реестрлері), узелдер арасындағы репликация, бэкаптарды сақтау жүйесіне тасымалдау, аналитиктердің үлкен жиындарға қатынасы. Мәселенің бір белгісі: диск пен CPU толық емес, ал сұраулар уақыты тұрақсыз.

Қалпына келтіру тосын сыйсыз болуы үшін

Сенімділік негізінен залалдың алдын алу: екі блок питания, желі дубликациясы, дисктің қорғанысы және ауыстыру схемасының анықтығы. Бұл тек "лукс" емес, есептерді бір компоненттің істен шығуынан қорғаудың жолы.

RPO және RTO-ны былай түсінуге болады: RPO — қанша деректі жоғалтуды қабылдайсыз; RTO — жүйені қай уақытта қалпына келтіру керек. Бұл көрсеткіштер репликация, резерв узел және бэкап жиілігін анықтайды.

Есте сақтаңыз: бэкап пен тоқтап қалмайтындық — әрқилы нәрсе. Бэкап деректерді "кеше" қалпына келтіруге көмектеседі, бірақ қызметтің дәл қазір жұмысын қалпына келтірмейді. Төңкеріссіздік (fault tolerance) қызметтің істен шыққанда қолжетімді болуын қамтамасыз етеді, бірақ бэкапты алмастырмайды.

Сатып алудан бұрын тексеріңіз:

• бэкаптар мен репликация үшін бөлек канал немесе терезе бар ма;\n- желі таңертеңгі есептер мен параллельді жүктемелерді көтере ме;\n- қуат, желі және диск дубликациясы ойластырылған ба;\n- RPO/RTO есептер иелерімен келісілген бе;\n- нақты қалпына келтіру тестіленген бе, тек "бэкап бар" емес.

Қадаммен: есептер мен витриналар үшін конфигурацияны қалай таңдау

Серверді таңдау адамдардың күнделікті сценарийлерінен басталғанда оңайырақ: күндіз олар қалай жұмыс істейді және түнде не болады. Квази-госсектор үшін бұл әсіресе маңызды: таңертең есептер тез ашылуы тиіс, ал регламентті тапсырмалар терезеге сай орындалуы керек.

Нәтижеге әкелетін 5 қадам

1. 3–5 ең маңызды есеп пен витринаны таңдаңыз. Әрбірі үшін мақсатты жауап уақытын белгілеңіз (мысалы, типтік фильтрлер үшін 3–5 секунд) және ең ауыр операцияларды анықтаңыз (детализация, экспорт, қайта есептеу).

2. Қатар жұмыс жүктемесін бағалаңыз: пикте қанша қолданушы және серверде параллель қанша тапсырма (жаңартулар, есептеулер, жариялаулар) жүреді. Түнгі терезені бөлек фиксациялаңыз: қанша сағат жүктеме және қайта құруға бар.

3. Рөлдерді қалай бөлуге шешім қабылдаңыз. Егер витриналар мен жүктемелер қақтығысса, бөлу жиі тиімді: DWH/ETL-ге бөлек узел, BI-сервиске бөлек узел. Бір қуатты узел жарамды, егер қолданушылар аз және түнгі жүктемелер қысқа болса.

4. Профильге сай конфигурация жасаңыз. Жылдам жауаптар әдетте көбірек RAM пен жылдам дискілерді талап етеді. Жаппай жүктемелер мен есептер — көбірек CPU мен тұрақты жазба. Желінің маңызы өседі, егер деректер әртүрлі жүйелерден келсе немесе бөлек СХД қолданылса.

5. 1–3 жылға резерв қалдырыңыз: деректер өсімі, жаңа витриналар, қолданушылар саны. Алдын ала масштабтауды қалай жасайтыныңызды анықтаңыз: RAM/дискілер қосу, екінші сервер орнату немесе кластерге өту.

Сосын ПО (СУБД, BI-платформа, драйверлер) үйлесімділігін, қолдау мен қайшы бөлшектерді тексеріңіз.

Соңғы спецификация алдында мини-тексеру

• Не «ауыр»: таңертеңгі пик есептер ме әлде түнгі жүктеме ме.\n- Өсу кезінде регламент терезеге сыйады ма.\n- Резерв бар ма: дискілер, қуат блоктары, қалпына келтіру жоспары.\n- Сервер масштабталатын ба, түгелімен ауыстыруды талап етпей ме.

Егер Қазақстан ұйымына инфрақұрылым таңдап жатсаңыз, жергілікті шығу тегі мен сервис талаптарын алдын ала тексеріңіз. GSE S200 сияқты серверлерді көбіне қолдаудың қолжетімділігі мен аймақтық жеткізілімділігі үшін қарайды.

Квази-госсекторға мысал сценарий: есептернен витриналарға дейін

Мысал: Қазақстандағы бір квази-госсектор ұйымы — таңертең 200–500 қолданушы есеп ашады (9:00–11:00), түнде витриналар қайта есептеледі және деректер көздерінен жүктеледі. Деректер типтік: қаржы (төлемдер, бюджет, проводкалар), кадрлар (штат, есептеу), сатып алулар (жоспарлар, келісімшарттар, жеткізілімдер). Көздер бірнеше, жаңарту жиілігі әртүрлі.

Аналитика серверлері пикте «құламас» үшін рөлдерді бөлу пайдалы, тіпті бастапқыда физикалық түрде бір сервер болғанмен де.

Қай жерде RAM маңызды, қай жерде дискілер

Тапсырмалар үш түрге бөлініп, әрқайсысының тар жері бар:

• BI-шығару және интерактивті есептер: RAM және CPU маңызды — ыстық жиындарды жадыда ұстау және көп параллельді сұрауларды өңдеу үшін.\n- Түнгі ETL және витриналарды қайта есептеу: жылдам дискілер және тұрақты жазба маңызды — жаппай енгізулер мен сұрыптаулар өтуде.\n- Тарих хранилищесі (бірнеше жыл): сыйымдылық және болжамды жылдамдық маңызды — деректер өсімі орынды түрде сақталсын.

Практикада витриналар мен BI қабатына RAM-ға басымдық беріледі, ал дискілер түнгі жүктемелер мен тарих өсіміне сәйкес таңдалады. Сыйымдылықты «нағыз шегіне дейін» есептемей, 12–18 ай үшін +30–50% резерв қалдыру әдетте дұрыс.

Пилот жоспары: не өлшеу керек

Сатып алудан бұрын пилот өткізіп, санмен растау пайдалы. Әдетте өлшейтіндер:

• таңертеңгі пикте 10–20 негізгі есептің ашылу уақыты;\n- витриналарды түнгі қайта есептеудің ұзақтығы;\n- деградациясыз максимал параллельді жүктеме;\n- RAM, CPU және диск қолданылуы (жазба кезектері, IOPS);\n- витриналар көлемінің айлық өсуі және бір жылға болжам.

Егер пилот есептердің бос тұрған дискілермен «ойланғанын» көрсетсе, RAM/CPU-ға басымдық қажет. Егер түнгі терезеге сыймай жатсаңыз — жиі дисктік подсистема немесе ETL пен BI арасындағы қақтығыс себепші.

BI серверін таңдауда кездесетін жиі қателер

Мәселе көп жағдайда BI-бағдарламадан емес, сервер параметрін бір ғана өлшем бойынша таңдауынан басталады. Мысалы, барынша көп ядро алып, есептердің жылдам боларын күту — жиі нәтиже бермейді.

Типтік қателер:

• Көп CPU, аз RAM. Витриналар мен интерактивті сұраулар үшін жад жиі маңыздырақ.\n- Дискті тек сыйымдылыққа қарай таңдау. DWH-те кідірістер мен IOPS маңызды.\n- Түнгі ETL мен күндізгі интерактивті сұрауларды араластырмай қою.\n- Уақытша кестелер, сұрыптаулар және логтар үшін резерв қалдырмау.\n- Кіші таңдамаларда тестілеу. Нағыз деректерде блокировкалар, жад үшін бәсекелестік және баяу қосылыстар пайда болуы мүмкін.

Қателерді сатып алудан бұрын анықтаудың қарапайым тәсілі:

• 2–3 ең ауыр есепті типтік витрина жүктемесімен параллель жүргізіңіз.\n- Не бірінші шектелетінін өлшеңіз: RAM, диск, CPU немесе желі.\n- Temp пен логтар үшін 6–12 айлық өсімге орын барына көз жеткізіңіз.\n- Егер есептер күндіз маңызды болса, жүктемелерді уақыт бойынша немесе узелдер бойынша бөліңіз.

Теңгерімді конфигурация "ең қуатты" бір компоненттен маңыздырақ, болсын ол GSE S200 немесе басқа жабдық кітапшасы болсын.

Сатып алу алдында чек-лист және келесі қадамдар

Сервер сатып алудан бұрын бір бетке бірнеше фактілерді жинау пайдалы. Бұл ақша үнемдейді және іске қосқаннан кейінгі тосын сыйлардың санын азайтады.

Фиксациялау керек нәрселер:

• BI-де қанша қолданушы бір уақытта және пиктер қашан (таңертең, күн соңы, ай аяқталуы).\n- Қандай есептер критикалық және қабылданатын жауап уақыты.\n- Деректер көлемі қазір және 12–24 айға болжам.\n- Витриналар қаншалықты жиі жаңартылады және жүктеу үшін терезе бар ма.\n- Қолжетімділік талаптары: түнде тоқтау мүмкін бе, қалпына келтіру жоспары қажет пе.

Сосын негізгі заттарды тексеріңіз:

• CPU: параллель сұраулар мен фондық жүктемелерге ядролар жеткілікті ме.\n- RAM: жұмыс жиындар мен кэш сыйып жатыр ма.\n- Дискілер: белсенді кестелерге жылдам қабат және ETL/staging үшін бөлек орын бар ма.\n- Желі: BI, DWH және сақтау арасындағы өткізу қабілеті жеткілікті ме.\n- Резерві: RAID, қуат блоктары, ресурстардың қосымша қоры.

Сандарды нақтылау үшін командадан «система сипаттамасы» емес, өлшенетін мысалдар сұраңыз: 5–10 ең ауыр сұраудың орындалу уақыты, түнгі жүктемелердің ұзақтығы, қатар қолданушылық статистикасы және нақты таймингтер.

Үлкен сатып алудан бұрын нақты деректермен қысқа пилот өткізу пайдалы. Құтқарушы критерийлер қарапайым: критикалық есептердің жауап уақыты, витриналарды жаңарту ұзақтығы, пик кезінде тұрақтылық және сирек ауыр құлдыраулардың жоқтығы.

Келесі қадамдар — мақсатты архитектураны бекіту (қайда DWH, қайда витриналар, қайда BI) және қызмет көрсету мен мониторинг жауапкершілігін анықтау. Егер BI мен витриналарға "темір" базис қажет болса, бөлек қарастыруға болады: GSE S200 серверлері және қажет болса жүйелік интеграция мен 24/7 қолдау қызметтері GSE.kz арқылы.