Жоғары өнімділік және жергілікті бөлу: TimescaleDB қолдауы бар Zabbix

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

Мәліметтерді қабылдау, өңдеу және жазу кезеңдері уақытты қажет етеді. Көп емес, бірақ үлкен жүйе үшін бұл үлкен кідірістерге әкелуі мүмкін. Сақтау мәселесі деректерге қол жеткізу мәселесі болып табылады. Олар есептер, тексерулер және триггерлер үшін пайдаланылады. Деректерге қол жеткізудегі кешігулер де өнімділікке әсер етеді. Дерекқорлар өскен кезде, маңызды емес деректер жойылуы керек. Жою - бұл кейбір ресурстарды жейтін қиын операция.

Zabbix-те жинау және сақтау кезіндегі кідірістердің мәселелері кэштеу арқылы шешіледі: кэштердің бірнеше түрлері, мәліметтер базасында кэштеу. Үшінші мәселені шешу үшін кэштеу қолайлы емес, сондықтан Zabbix TimescaleDB қолданды. Ол сізге бұл туралы айтып береді Андрей Гущин - техникалық қамтамасыз ету инженері Zabbix SIA. Андрейдің Zabbix-ті 6 жылдан астам қолдап келеді және орындаушылық тәжірибесі бар.

TimescaleDB қалай жұмыс істейді, ол қарапайым PostgreSQL-пен салыстырғанда қандай өнімділік бере алады? Zabbix TimescaleDB дерекқоры үшін қандай рөл атқарады? Нөлден қалай бастау керек және PostgreSQL-тен қалай көшіру керек және қай конфигурацияның өнімділігі жақсы? Мұның бәрі туралы кесу астында.

Өнімділік мәселелері

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

Деректерді жылдам жинау және өңдеу. Жақсы бақылау жүйесі барлық деректерді жылдам қабылдауы және оны триггер өрнектері бойынша - оның критерийлері бойынша өңдеуі керек. Өңдеуден кейін жүйе бұл деректерді кейінірек пайдалану үшін дерекқорда жылдам сақтауы керек.

Тарихты сақтау. Жақсы бақылау жүйесі дерекқорда тарихты сақтауы және метрикаға оңай қол жеткізуді қамтамасыз етуі керек. Тарих есептерде, графиктерде, триггерлерде, шектерде және есептелген ескерту деректерінің элементтерінде пайдалану үшін қажет.

Тарихты тазалау. Кейде көрсеткіштерді сақтаудың қажеті жоқ күн келеді. 5 жыл бұрын, бір немесе екі ай бұрын жиналған деректер не үшін қажет: кейбір түйіндер жойылды, кейбір хосттар немесе көрсеткіштер енді қажет емес, себебі олар ескірген және енді жиналмайды. Жақсы бақылау жүйесі тарихи деректерді сақтауы және деректер базасы өспеуі үшін оларды мезгіл-мезгіл жоюы керек.

Ескірген деректерді тазалау дерекқор өнімділігіне үлкен әсер ететін маңызды мәселе болып табылады.

Zabbix-те кэштеу

Zabbix-те бірінші және екінші қоңыраулар кэштеу көмегімен шешіледі. ЖЖҚ деректерді жинау және өңдеу үшін қолданылады. Сақтау үшін - триггерлердегі, графиктердегі және есептелген деректер элементтеріндегі тарих. Дерекқор жағында негізгі таңдаулар үшін кейбір кэштеу бар, мысалы, графиктер.

Zabbix серверінің жағында кэштеу:

• ConfigurationCache;
• ValueCache;
• HistoryCache;
• TrendsCache.

Оларды толығырақ қарастырайық.

ConfigurationCache

Бұл біз метриканы, хосттарды, деректер элементтерін, триггерлерді сақтайтын негізгі кэш - алдын ала өңдеу және деректерді жинау үшін қажет нәрсенің барлығы.

Мұның бәрі дерекқорда қажетсіз сұрауларды жасамас үшін ConfigurationCache ішінде сақталады. Сервер іске қосылғаннан кейін біз бұл кэшті жаңартамыз, конфигурацияларды жасаймыз және мерзімді түрде жаңартамыз.

Деректер жинау

Диаграмма өте үлкен, бірақ ондағы ең бастысы тергіштер. Бұл әртүрлі «сауалушылар» - құрастыру процестері. Олар құрастырудың әртүрлі түрлеріне жауапты: олар SNMP, IPMI арқылы деректерді жинайды және оның барлығын PreProcessing жүйесіне жібереді.

Коллекторлар қызғылт сары түспен белгіленген.

Zabbix тексерулерді біріктіру үшін қажет жинақтау элементтерін есептеді. Егер олар бізде болса, біз олар үшін деректерді тікелей ValueCache ішінен аламыз.

Preprocessing HistoryCache

Барлық коллекторлар тапсырмаларды алу үшін ConfigurationCache пайдаланады. Содан кейін оларды PreProcessing жүйесіне ауыстырады.

PreProcessing алдын ала өңдеу қадамдарын алу үшін ConfigurationCache пайдаланады. Ол бұл деректерді әртүрлі жолдармен өңдейді.

Деректерді PreProcessing көмегімен өңдегеннен кейін біз оны өңдеу үшін HistoryCache ішіне сақтаймыз. Бұл деректерді жинауды аяқтайды және біз Zabbix-тегі негізгі процеске көшеміз - тарих синхрері, өйткені бұл монолитті архитектура.

Ескертпе: Алдын ала өңдеу – өте қиын операция. v 4.2 нұсқасымен ол проксиге көшірілді. Егер сізде деректер элементтерінің көп саны және жинау жиілігі бар өте үлкен Zabbix болса, бұл жұмысты айтарлықтай жеңілдетеді.

ValueCache, тарих және трендтер кэші

Тарих синсері - әрбір деректер элементін, яғни әрбір мәнді атомдық түрде өңдейтін негізгі процесс.

Тарих синхрері HistoryCache ішінен мәндерді алады және Конфигурацияны есептеулер үшін триггерлердің бар-жоғын тексереді. Егер олар бар болса, ол есептейді.

Тарих синхраторы оқиғаны, конфигурация талап етсе, ескертулерді жасау үшін эскалацияны және жазбаларды жасайды. Кейінгі өңдеу үшін триггерлер болса, тарих кестесіне қол жеткізбеу үшін бұл мәнді ValueCache ішінде сақтайды. ValueCache триггерлер мен есептелген элементтерді есептеу үшін қажет деректермен осылай толтырылады.

Тарих синхрері барлық деректерді дерекқорға жазады және ол дискіге жазады. Өңдеу процесі осы жерде аяқталады.

Деректер базасында кэштеу

Оқиғалар туралы графиктерді немесе есептерді көргіңіз келсе, дерекқор жағында әртүрлі кэштер бар:

• Innodb_buffer_pool MySQL жағында;
• shared_buffers PostgreSQL жағында;
• effective_cache_size Oracle жағында;
• shared_pool DB2 жағында.

Көптеген басқа кэштер бар, бірақ бұл барлық дерекқорлар үшін негізгі болып табылады. Олар жиі сұраулар үшін қажет деректерді жедел жадта сақтауға мүмкіндік береді. Бұл үшін олардың өз технологиялары бар.

Деректер базасының өнімділігі өте маңызды

Zabbix сервері деректерді үнемі жинап, жазады. Қайта іске қосылғанда, ол ValueCache толтыру үшін тарихтан да оқиды. Сценарийлер мен есептерді пайдаланады Zabbix API, ол веб-интерфейске салынған. Zabbix API дерекқорға қатынасады және графиктер, есептер, оқиғалар тізімдері және соңғы мәселелер үшін қажетті деректерді шығарады.

Көрнекілік үшін - Графана. Бұл біздің пайдаланушылар арасында танымал шешім. Ол Zabbix API және дерекқор арқылы сұрауларды тікелей жібере алады және деректерді алу үшін белгілі бір бәсекелестік жасайды. Сондықтан, нәтижелерді және тестілеуді жылдам жеткізу үшін мәліметтер базасын жақсырақ және жақсырақ баптау қажет.

Үй қызметшісі

Zabbix-тің үшінші өнімділігі - бұл Housekeeper көмегімен тарихты тазарту. Ол барлық параметрлерді бақылайды - деректер элементтері күндердегі өзгерістер динамикасын (трендтерді) қанша уақыт сақтау керектігін көрсетеді.

Біз TrendsCache-ті жылдам есептейміз. Деректер келгенде, біз оны бір сағатқа біріктіреміз және тренд өзгерістерінің динамикасы үшін кестелерге жазамыз.

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

Қызыл график Тарих синсерінің үнемі бос емес екенін көрсетеді. Үстіңгі жағындағы қызғылт сары график - тұрақты жұмыс істейтін үй қызметкері. Ол дерекқордың өзі көрсеткен барлық жолдарды жоюын күтеді.

Үй қызметкерін қашан өшіру керек? Мысалы, «Элемент идентификаторы» бар және сіз белгілі бір уақыт ішінде соңғы 5 мың жолды жоюыңыз керек. Әрине, бұл индекс бойынша болады. Бірақ әдетте деректер жинағы өте үлкен және дерекқор әлі де дискіден оқиды және оны кэшке қояды. Бұл әрқашан дерекқор үшін өте қымбат операция және деректер қорының өлшеміне байланысты өнімділік мәселелеріне әкелуі мүмкін.

Үй қызметкерін өшіру оңай. Веб-интерфейсте үй қызметкеріне арналған «Жалпы әкімшілік» параметрі бар. Біз ішкі тренд тарихы үшін ішкі үй шаруашылығын өшіреміз және ол енді оны басқармайды.

Үй қызметкері өшірілді, графиктер тегістелді - бұл жағдайда қандай мәселелер болуы мүмкін және үшінші өнімділік мәселесін шешуге не көмектесе алады?

Бөлу - бөлу немесе бөлу

Әдетте, бөлу мен тізімдеген әрбір реляциялық дерекқорда басқа жолмен конфигурацияланады. Әрқайсысының өз технологиясы бар, бірақ олар жалпы алғанда ұқсас. Жаңа бөлім жасау көбінесе белгілі бір мәселелерге әкеледі.

Әдетте, бөлімдер «орнатуға» байланысты конфигурацияланады - бір күнде жасалған деректер көлемі. Әдетте, бөлу бір күнде шығарылады, бұл ең аз. Жаңа топтаманың трендтері үшін – 1 ай.

«Орнату» өте үлкен болса, мәндер өзгеруі мүмкін. Егер шағын «орнату» 5 000 нв/с дейін болса (секундына жаңа мәндер), орташасы 5 000-нан 25 000-ға дейін болса, үлкені 25 000 нв/с жоғары. Бұл дерекқорды мұқият конфигурациялауды қажет ететін үлкен және өте үлкен қондырғылар.

Өте үлкен қондырғыларда бір күндік кезең оңтайлы болмауы мүмкін. Мен күніне 40 ГБ немесе одан көп MySQL бөлімдерін көрдім. Бұл проблемаларды тудыруы мүмкін және азайтуды қажет ететін деректердің өте үлкен көлемі.

Бөлу не береді?

Бөлу кестелері. Көбінесе бұл дискідегі бөлек файлдар. Сұрау жоспары бір бөлімді оңтайлырақ таңдайды. Әдетте бөлу диапазон бойынша қолданылады - бұл Zabbix үшін де қолданылады. Біз бұл жерде «уақыт белгісін» қолданамыз - дәуір басынан бері. Бұл біз үшін қарапайым сандар. Сіз күннің басы мен соңын орнатасыз - бұл бөлім.

Жылдам жою - DELETE. Жоюға арналған жолдар таңдауының орнына бір файл/ішкі кесте таңдалады.

Деректерді іздеуді айтарлықтай жылдамдатады SELECT - бүкіл кестені емес, бір немесе бірнеше бөлімдерді пайдаланады. Екі күндік деректерге қол жеткізіп жатсаңыз, ол дерекқордан жылдамырақ шығарылады, себебі үлкен кестені емес, тек бір файлды кэшке жүктеп, оны қайтару керек.

Көбінесе көптеген деректер базалары да жеделдетіледі INSERT — еншілес кестеге кірістірулер.

Уақыт шкаласыDB

v 4.2 үшін назарымызды TimescaleDB-ге аудардық. Бұл түпнұсқа интерфейсі бар PostgreSQL кеңейтімі. Кеңейтім реляциялық дерекқорлардың артықшылықтарын жоғалтпай, уақыт қатарларының деректерімен тиімді жұмыс істейді. TimescaleDB да автоматты түрде бөледі.

TimescaleDB тұжырымдамасы бар гиперкесте (гиперативті) сіз жасаған. Құрамында кесектер - бөлімдер. Бөліктер басқа фрагменттерге әсер етпейтін автоматты түрде басқарылатын гипертаблица фрагменттері болып табылады. Әрбір бөліктің өз уақыт диапазоны бар.

TimescaleDB және PostgreSQL

TimescaleDB шынымен тиімді жұмыс істейді. Кеңейтім өндірушілері сұранысты өңдеудің дұрыс алгоритмін, атап айтқанда inserts қолданатынын мәлімдейді. Деректер жиынының кірістіру өлшемі ұлғайған сайын, алгоритм тұрақты өнімділікті сақтайды.

200 миллион жолдан кейін PostgreSQL әдетте айтарлықтай төмендей бастайды және өнімділікті 0-ге дейін жоғалтады. TimescaleDB деректердің кез келген көлеміне «енгізулерді» тиімді енгізуге мүмкіндік береді.

параметр

TimescaleDB орнату кез келген пакет үшін өте оңай. IN құжаттама бәрі егжей-тегжейлі сипатталған - бұл ресми PostgreSQL пакеттеріне байланысты. TimescaleDB қолмен де құрастырылуы және құрастырылуы мүмкін.

Zabbix дерекқоры үшін біз жай ғана кеңейтімді белсендіреміз:

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

Сіз іске қосасыз extension және оны Zabbix дерекқоры үшін жасаңыз. Соңғы қадам гиперкесте жасау болып табылады.

Тарих кестелерін TimescaleDB ішіне тасымалдау

Бұл үшін арнайы функция бар create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

Функцияның үш параметрі бар. Бірінші - деректер қорындағы кесте, ол үшін гиперкесте жасау керек. Екінші - өріс, соған сәйкес жасау керек chunk_time_interval — пайдаланылатын бөлім бөліктерінің аралығы. Менің жағдайда интервал бір күн - 86 400.

Үшінші параметр - migrate_data. Егер сіз орнатсаңыз true, содан кейін барлық ағымдағы деректер алдын ала жасалған бөліктерге тасымалданады. Мен өзім қолдандым migrate_data. Менде шамамен 1 ТБ болды, бұл бір сағаттан астам уақытты алды. Тіпті кейбір жағдайларда тестілеу кезінде сақтау үшін қажет емес таңба түрлерінің тарихи деректерін оларды тасымалдамау үшін жойдым.

Соңғы қадам - UPDATE: ішінде db_extension қою timescaledbосылайша дерекқор бұл кеңейтімнің бар екенін түсінеді. Zabbix оны белсендіреді және дерекқорға синтаксис пен сұрауларды - TimescaleDB үшін қажетті мүмкіндіктерді дұрыс пайдаланады.

Аппараттық құрал конфигурациясы

Мен екі серверді қолдандым. Бірінші - VMware машинасы. Бұл өте кішкентай: 20 Intel® Xeon® CPU E5-2630 v 4 @ 2.20 ГГц процессорлары, 16 ГБ жедел жады және 200 ГБ SSD.

Мен оған PostgreSQL 10.8 нұсқасын Debian 10.8-1.pgdg90+1 ОЖ және xfs файлдық жүйесімен орнаттым. Мен осы нақты дерекқорды пайдалану үшін бәрін минималды түрде конфигурацияладым, минус Zabbix өзі пайдаланатын.

Сол машинада Zabbix сервері, PostgreSQL және жүк агенттері. Менде қолданатын 50 белсенді агент болды LoadableModuleәртүрлі нәтижелерді өте жылдам жасау үшін: сандар, жолдар. Мен дерекқорды көптеген деректермен толтырдым.

Бастапқыда конфигурация қамтылды 5 000 элемент әрбір хост үшін деректер. Әрбір дерлік элементте оны нақты қондырғыларға ұқсас ету үшін триггер бар. Кейбір жағдайларда бірден көп триггер болды. Бір желі түйіні үшін болды 3-000 триггерлер.

Деректер элементін жаңарту аралығы − 4-7 секунд. Мен 50 агентті ғана емес, сонымен қатар көбірек қосу арқылы жүктеменің өзін реттедім. Сондай-ақ, деректер элементтерін пайдалана отырып, мен жүктемені динамикалық түрде реттедім және жаңарту аралығын 4 секундқа дейін қысқарттым.

PostgreSQL. 35 000 нв/сек

Менің бұл аппараттық құралдағы алғашқы жұмысым таза PostgreSQL-де болды - секундына 35 мың мән. Көріп отырғаныңыздай, деректерді енгізу секундтың бөліктерін алады - бәрі жақсы және жылдам. Жалғыз нәрсе - 200 ГБ SSD дискісі тез толтырылады.

Бұл стандартты Zabbix серверінің өнімділік бақылау тақтасы.

Бірінші көк график секундына мәндер саны болып табылады. Оң жақтағы екінші график - құрастыру процестерінің жүктелуі. Үшіншісі - ішкі құрастыру процестерін жүктеу: тарих синхрондары және осында біраз уақыттан бері жұмыс істеп тұрған Housekeeper.

Төртінші график HistoryCache пайдалануын көрсетеді. Бұл дерекқорға кірістірер алдында буфердің бір түрі. Жасыл бесінші график ValueCache пайдаланылуын көрсетеді, яғни триггерлер үшін қанша ValueCache соққысы бар - бұл секундына бірнеше мың мән.

PostgreSQL. 50 000 нв/сек

Содан кейін мен сол жабдықтағы жүктемені секундына 50 мың мәнге дейін арттырдым.

Үй қызметкерінен жүктеген кезде 10 мың мәнді енгізу 2-3 секундқа созылды.

Үй қызметкері қазірдің өзінде жұмысқа араласа бастады.

Үшінші график, жалпы алғанда, траперлер мен тарих синхерлеріне жүктеме әлі де 60% деңгейінде екенін көрсетеді. Төртінші графикте HistoryCache қазірдің өзінде Housekeeper жұмысы кезінде белсенді түрде толтырыла бастады. Ол 20% толы, бұл шамамен 0,5 ГБ.

PostgreSQL. 80 000 нв/сек

Содан кейін мен жүктемені секундына 80 мың мәнге дейін арттырдым. Бұл шамамен 400 мың деректер элементтері және 280 мың триггерлер.

Отыз тарих синхерінің жүктелу құны қазірдің өзінде өте жоғары.

Мен сондай-ақ әртүрлі параметрлерді арттырдым: тарих синсерлері, кэштер.

Менің аппараттық құралымда тарих синсерлерінің жүктелуі максималды деңгейге дейін өсті. HistoryCache деректермен тез толтырылды - өңдеуге арналған деректер буферде жинақталған.

Осы уақыттың бәрінде мен процессордың, жедел жадтың және басқа жүйе параметрлерінің қалай пайдаланылғанын бақылап, дискіні пайдаланудың максималды деңгейіне жеттім.

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

Екінші сервер

Мен басқа серверді қабылдадым, онда 48 процессор және 128 ГБ жедел жады бар. Мен оны баптадым - оны 60 тарих синсеріне орнатып, қолайлы өнімділікке қол жеткіздім.

Шын мәнінде, бұл бірдеңе істеу керек өнімділіктің шегі.

Уақыт шкаласыDB. 80 000 nvps

Менің негізгі міндетім - TimescaleDB мүмкіндіктерін Zabbix жүктемесіне қарсы тексеру. Секундына 80 мың мән - бұл өте көп, көрсеткіштерді жинау жиілігі (әрине, Яндекстен басқа) және жеткілікті үлкен «қондырма».

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

TimescaleDB деректерді 3 есе жылдам енгізуге және HistoryCache-ті азырақ пайдалануға мүмкіндік береді.

Тиісінше, сіз дер кезінде деректерді аласыз.

Уақыт шкаласыDB. 120 000 nvps

Содан кейін мен деректер элементтерінің санын 500 мыңға дейін арттырдым.Негізгі тапсырма TimescaleDB мүмкіндіктерін тексеру болды - мен секундына 125 мың мәннің есептелген мәнін алдым.

Бұл ұзақ уақыт жұмыс істей алатын жұмыс істейтін «орнату». Бірақ менің дискім небәрі 1,5 ТБ болғандықтан, мен оны бір-екі күнде толтырдым.

Ең бастысы, бір уақытта жаңа TimescaleDB бөлімдері жасалды.

Бұл өнімділік үшін мүлдем байқалмайды. Мысалы, MySQL-де бөлімдер жасалғанда, бәрі басқаша болады. Бұл әдетте түнде болады, себебі ол жалпы кірістіруді, кестелермен жұмыс істеуді блоктайды және қызметтің нашарлауын тудыруы мүмкін. Бұл TimescaleDB-де емес.

Мысал ретінде мен қауымдастықтағы көптеген адамдардан бір графикті көрсетемін. Суретте TimescaleDB қосылған, соның арқасында процессорда io.weight пайдалану жүктемесі төмендеді. Ішкі процесс элементтерін пайдалану да азайды. Оның үстіне, бұл SSD емес, кәдімгі құймақ дискілеріндегі кәдімгі виртуалды машина.

қорытындылар

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

TimescaleDB конфигурациялау оңай, өнімділікті арттырады, Zabbix және PostgreSQL-тен артықшылығы бар.

Егер сіз PostgreSQL-ді қолдансаңыз және оны өзгертуді жоспарламасаңыз, мен ұсынамын PostgreSQL-ті TimescaleDB кеңейтімімен Zabbix-пен бірге пайдаланыңыз. Бұл шешім орташа «қондыруға» дейін тиімді жұмыс істейді.

«Жоғары өнімділік» дегенде біз айтқымыз келеді Жоғары жүктеме++. Миллиондаған пайдаланушыларға қызмет көрсетуге мүмкіндік беретін технологиялар мен тәжірибелер туралы білу үшін сізге көп күтудің қажеті жоқ. Тізім есеп береді 7 және 8 қараша үшін біз қазірдің өзінде құрастырдық, бірақ мұнда кездесулер көбірек ұсынуға болады.

Біздің арнаға жазылыңыз ақпараттық бюллетень и жеделхат, онда біз алдағы конференцияның ерекшеліктерін ашамыз және одан қалай барынша пайда алу керектігін білеміз.

Ақпарат көзі: www.habr.com