Սառեցում Linux ֆայլային համակարգերի մեջ: Ինչպես ստեղծել 3 տերաբայթ MySQL SУБД-ի պահուստային պատճենները 20 վայրկյանում

Ես Յուրին եմ, համակարգային վարման խմբի ղեկավար Սիթիմոբիլում: Այսօր կիսվեմ Linux ֆայլային համակարգերի ճզմման վերականգնման (thin provisioning) տեխնոլոգիայի կիրառման փորձով և կպատմեմ, թե ինչպես կարելի է այն օգտագործել ընկերության CI/CD գործընթացների մեջ: Մենք կքննարկենք այն իրավիճակը, երբ ավտոմատ կոդի փորձարկման համար, երբ այն մատակարարվում է արտադրանք, մենք որքան հնարավոր է արագ պետք են MySQL DB քաղվածք, առավելագույնս մոտ «պայմանագրային» տարբերակին, հասանելի ընթերցման և գրելու համար.

Ներածություն. ինչու տալ վնասակար խորհուրդներ?

Լուրեր ունի, սակայն կան հաստատված մեխանիզմներ DB սխեմաների գաղթման համար փորձարկման միջավայրեր: Ինչու առհասարակ հասցնել հիմնական ոչ բաժանված ԴԲ-ն նման ծավալների: Հետաքրքիր է նաև, որ փորձարկման համար անհրաժեշտ չեն բոլոր տվյալները։ Ս تلاشելու եմ բացատրել.

Մոտ մեկ տարի առաջ մեր հինգաց ԻԿԱ-ի ակտիվ աճի ֆոնին (2018 թվականին ավարտված ուղևորությունների ընթացքում 15 անգամ աճել ենք), աճել են տվյալների ծավալները, սերվերների բեռը, սեփականությունը ավելացման հաճախականությունը: Մենք հայտնվեցինք հետևյալ իրավիճակում:

• Հիմնական MySQL DB-ն աճել է մոտ 1000 աղյուսակ սահմանակից ծավալով 2,5 TB, և շարունակում է աճել.
• Ամենափոքր ժամանակահատվածում չենք կարողացել շարդավորվել և տարածել տվյալների բազան: Հին մոտեցումը «գրեմ, հարևանություն ունեմ և ինչպես եմ ուզում»՝ շատ JOIN գրառումներ և աղյուսակների ներքին կախվածություններ.
• Չկան DB схемաներ գնահատման մեխանիզմներ փորձարկման միջավայրերում.
• Չկան ավտոմատ կոդի փորձարկման մեխանիզմներ արտադրանքի ժամանակում.

Ավարտելու խնդիրն ուզեցվում էր հնարավորինս արագ: Այժմ գրելով Postman փորձարկման համար ոչ մի խնդիր չունեցանք, սակայն մինչ օրս արդիական տվյալների բազան չկա: Այս ընթացքում գիշերը մենք չենք կարողացել պատրաստել կրկին, ես նախատեսում եմ կատարել այն և փոխանցել երեքշաբթի, երջանիկ ատելության նման տարեստում: Նաև սահմանափակել ոչ թե աշխատանքային օրերով չի արդյուն արդյունքն է լինելու.

Բայց խնդիրը լուծվեց: Մենք արդեն 2 շաբաթվա ընթացքում առաջին աշխատող հաստատությունը ենք ստացել: Ընդամենը մեկ տարին մնացել է շատ փոփոխություններ, և այն շարունակում է օգտագործվել.

Այժմ ես մանրամասն կբացատրեմ բոլոր քայլերն ու մեր լուծման զարգացման փուլերը: Դուք համոզվեք, որ այս մեթոդը արժանի է գոյություն ունենալու.

מה זה
Այս ապարատային կամ ծրագրային տեխնոլոգիան (կոչվում է նաև sparse volumes), թույլ է տալիս առանձին ռեսուրսից ավելի մեծ քանակություն հատկացնել, քան առկա է: Այդ դեպքում կտրամադրվող տարածությունը պետք է համապատասխանի just-enough (գնահատական՝ որքան հարկավոր է) և just-in-time (հարկավոր ժամանակահատվածում) չափանիշներին: Ընդհանուր առմամբ, նուրբ պահպանումը օգտագործվում է տարբեր ՍԽՏ-ներում, որպեսզի տրամադրեն հավաքական տարածություն անհրաժեշտ քանակությամբ, գերազանցելու իրական հասանելի մուտքերը: Технологիան աջակցվում է տարբեր ֆայլային համակարգերով, օրինակ, LVM2, ZFS, BTRFS: Այն լայնորեն օգտագործվում է վիրտուալացման հիպերվիզորներում: Մեզ համար նուրբ պահպանումը թույլ տվեց արագ ստեղծել հիմնական բաժնի սnapshots-ներից որքան կարելի է (MySQL տվյալների բանկի data-directory):

Առաջին ստենդ, Thin LVM տեխնոլոգիա

Այս գլխին կարելի է նաև անվանել «Ինչպես ստեղծել առավելագույնս արագ սnapshots մեծ ծավալների տվյալների միջոցով Thin LVM, կրճատելով ֆայլային համակարգի և MySQL տվյալների բանկի կայունությունը՝ անբարեկարգ ցուցանիշների»:

Քանի որ մենք արդեն օգտագործել էինք LVM օպերացիոն համակարգերի հիմնական բաժինների կառուցման համար, որոշեցինք սկսել հենց դրանից: Ուսումնասիրության սկզբում մեզ պետք էր առանձին ֆիզիկական մեքենա՝ մեր MySQL հիմնական տվյալների բանկի կրկնօրինակ, որի վրա կարող էինք պահանջով ստեղծել կրկնօրինակի սnapshot և բարձրացնել նրան կողքի առանձին MySQL օրինակով: Թեստավորման ժամանակ մենք թույլ էինք տվել կիրառել փոփոխական գործողություններ՝ այդ օրինակով, և թեստերի ավարտից հետո հաջողությամբ այն ջնջում էինք: Սերվերի կոնֆիգուրացիան՝

• 2 x Intel Silver 4114 (10×2,2 ԳՀց HT)
• 8 x 32 ԳԲ DDR4
• 8 x 1920 ԳԲ Intel SSD Adaptec RAID-կոնտրոլերում RAID-10

RAID-կոնտրոլերի և ծրագրային RAID MD ընտրության վերաբերյալ կարելի է առանձին հոդված գրել: Ազդեցություն ունեցան մեր ընտրության երկու գործոն:

• Խնդիրը առաջադրելու ժամանակ մենք բոլոր ՍԽՏ-ները տեղադրել ենք RAID-կոնտրոլերներում, այսինքն կարելի է ասել, որ այդպես ձևավորվել է պատմականորեն:
• Ֆայլային համակարգի սինթետիկ թեստերում և տարբեր գործողությունների MySQL թեստերում արդյունավետության տարբերությունը շատ փոքր էր:

Մենք բաժանել ենք ստացված RAID-10-ը: Ստեղծել ենք միասնական Volume Group (VG) ամբողջ ծավալով (մոտ 6,7 Գբ ծախսերով) և ստեղծել տրամաբանային բաժին (Logical Volume, LV) 50 Գբ համակարգի համար: Որովհետև սովորաբար, մնացած տարածքը մենք սահմանում ենք MySQL բաժինը: Բայց մեզ պետք էր նուրբ պահպանում, այդ պատճառով նախ ստեղծել ենք այսպես կոչված pool, որի ներսում ստեղծել բաժին /var/lib/mysql-ի համար 3,5 Թբ (նախատեսված DB ծավալների հիման վրա):

lvcreate -l 100%FREE -T vga/thin
lvcreate -V 3.5T -T vga/thin -n mysql

Մեր հատվածը ձևափոխեցինք ext4 ձևաչափով, կցեցինք այն, կատարեցինք ռեպլիկացիա և ստացանք սկզբնական կանգառը: Այնուհետև ստեղծեցինք API, որը պետք է ստեղծի ս্নափշոթներ, բարձրացնի MySQL տվյալների բազայի օրինակ` որոշված պորտի վրա և ջնջի ստեղծված օրինակն։ Չնայած օգտագործվում էին միայն համակարգային կանչեր, որպես սցենարի ստեղծման լեզու ընտրեցինք սովորական bash-ը, իսկ API HTTP → bash կապի համար կիրառեցինք բաց աղբյուրի լուծում goexpose, որը գրվել է Go լեզվով։

Մի օր մենք մեր bash-սցենարները կհրապարակենք բաց աղբյուրում, բայց մինչ այդ ես պարզապես կբարձրաձայնեմ հիմնական ալգորիթմը.

Հիմնական սնոփշոթի ստեղծում snapmain՝

1. Սկսում ենք հիմնական ռեպլիկացիան կանգնեցնելով։
2. Դնում ենք արգելք սնոփշոթ snapmain-ի համար։
3. Սթեղծում ենք նոր սնոփշոթ snapmain:
4. Սկանում ենք MySQL-ը և հանում արգելքը։

Դտի տվյալների բազան ստեղծել սնոփշոթից snapmain:

1. Դնում ենք արգելք որոշակի MySQL օրինակին (պորտին):
2. Պատասխանատու ենք հիմնական սնոփշոթի ստեղծման արգելքի առկայության համար։ Եթե այն առկա է, սպասում ենք և նորից ստուգում յուրաքանչյուր 5 վայրկյան։
3. Պատասխանատու ենք արդյոք ծանոթ LV-հետազոտումի առկայությանը։
   3.1 Եթե առկա է, կանգնեցնում ենք MySQL օրինակին kill -9 այրվելու միջոցով և ջնջում LV-հետազոտումը։
4. Սնոփշոթ snapmain-ից ստեղծում ենք նոր օրինակ:
5. Պատրաստում և կցում ենք այդ օրինակին համար մատնանշված դիրքերը:
6. Հանում ենք հլթական նշանները (ֆայլերը) և սկսում ենք MySQL օրինակ:
7. Տեսնում ենք դրա հլթակում։
8. Հանում ենք արգելքը։

Չեզոքացման տվյալների բազան դուրսարգելային պորտից:

1. Դնում ենք արգելք որոշակի MySQL օրինակին (պորտին):
2. Հրաժարում ենք MySQL օրինակին kill -9-ի միջոցով։
3. Չեզոք մշակվում են դիրքերը։
4. Հրաժարում ենք LV-հետազոտումը և հանում արգելքը։

Օրինակ հրամանների նոր օրինակին բաժանելու համար:

lvcreate -n stage_3307 -s vga/snapmain
lvchange -ay -K vga/stage_3307
mount -o noatime,nodiratime,data=writeback /dev/mapper/vga-stage_3307 /mnt/stage_3307

Այժմ կպատմեմ հիմնական խնդիրը, որին մենք բախվեցինք բարակ պահման օգտագործման ժամանակ։ Մենք հանդիպեցինք SSD-Ձորի արտադրողականությանը։ Դա պատահեց Thin LVM-ի հատկություններով: դա իր հիմքում գործում է սարքավորում կարծիքով` լավ դիզայնով ունեցող թիթեղիկներով, որոնք դրված են 4 Մբ։ Ինչպես դա հայեցվում էր:

1. Սնոփշոթ ստեղծվում է հիմնական հատվածից /var/lib/mysql։
2. Սկանում ենք ռեպլիկացիան, որպեսզի դիմացենք նավապետին։
3. Թևի աղյուսակի մեջ ցանկացած փոփոխություն ստիպում է պահպանել մնացած, փոփոխված չճանաչվող թիթեղիկները սնոփշոթի բաժնում։
4. Թեքի բարձրացած փորձառու օրինակին ցանկացած փոփոխություն ստիպում է պահպանել մնացած, փոփոխված չճանաչվող թիթեղիկները այս օրինակին համընկնող բաժնում։
5. Ստանում ենք 100% ենթակառուցվածքի բեռնվածություն, ցանկացած գործողություններ դանդաղեցնում է և աստիճանաբար տարանջատվում է նավապետը։
6. Ավարտական աշխատանքային օրը ստանում ենք մի քանի ժամ ուշացած կանգառ։

Ինչպես մենք պայքարեցինք դրա հետ, որպեսզի ավելի խոստումնալից արդյունքներ ստանանք (հիմնական մտքեր).

RAID-կառավարում՝

• Բացառում ենք բոլոր տիպի քրեակարկևները ըստ նախադրվածքների։
• Մենք հաստատեցինք writeback (այսինքն՝ տվյալները բֆերացման ժամանակ համալրվում են անմիջապես, նախքան փաստացի պահպանելը սկավառակում):

Ֆայլային համակարգը:

• Մոնտաժման կետում /var/lib/mysql նշեցինք noatime,nodiratime,data=writeback
• Մենք անջատեցինք ext4-ի գրանցումը tune2fs-ով:

MySQL:

• Անշուշտ, մենք նշեցինք innodb_flush_method = O_DSYNC (արագությունը բարձրացնելով, մենք նվազեցրել ենք կայունությունը):
• Մենք անջատեցինք գրանցումը, լոգերը մեզ պետք չեն:
• Անշուշտ, մենք նշեցինք innodb_buffer_pool_size = 4G (Ինչքան փոքր լինի InnoDB-ի պարը, այնքան ավելի արագ MySQL-ը կդադարեցվի, և այնքան ավելի արագ մենք կհրապարակենք սենապշոտ):

Այս ցանկը շատ չի ընդգրկում, հատկապես MySQL-ի համար: Սակայն, մյուս փոփոխությունները փոքր են ու հաճախակի չէ, որ կիրառական լինեն: Օրինակ, դիսկերը հեշտացնելու համար մենք հասցրեցինք innodb_parallel_doublewrite_path в /dev/shm, ինչը որոշ դեպքերում սկսելիս սխալ ավարտվելու դեպքում խնայել է մեզ մինչև 5 վարկյան:

Ինչու ենք մենք կանգնում MySQL-ը, երբ ուզում ենք անել սենապշոտ? Ведь мы можем снять его с работающей реплики. Все верно, вот только новый экземпляр БД на этом снапшоте будет по умолчанию считаться поврежденным и потребует полного сканирования при запуске. Останавливать реплику определенно быстрее, хоть это в итоге и является самой длительной операцией во всем процессе.

Արդյունքում մենք ստացանք ավելի առանձին ժամացույցներ և աշխատելու պատրաստ բյուրեղ: Սակայն, ինչպես ցույց է տալիս հիմնական արձագանքների մարքեթինգի ամենահայտնի գրաֆիկը, իրավիճակը դեռև հեռու է իդեալից:

Այլ թերություններից պետք է նշել, որ քիչ հավանական է Thin LVM-ի պարի վերահսկողությունը: Besides the standard system commands like iostat, it is impossible to determine which element of the pool is currently putting the most load on the file system.

Իզուր ուզում եմ նշել մի մեծ թերություն, որը կապված է վերոնշյալ օպտիմալացման հետ: Մենք ստացանք YOLO-հասարակական: Երկու ամիսը մեկ այնպիսի սարսափներով, ext4-ը չի դիմանում նմանատիպ ճնշմանը և անհետանում է, պահանջելով վերֆորմատավորում և կրկին բեռնման: Արագության վերապատրաստելով, մենք խեղդեցինք կայունությունը:

Ինչպիսի մետրիքի հետևելը պետք է Thin LVM-ի շահագործման ընթացքում:

• Thin pool data %
• Thin pool metadata %

Եթե ավարտված տարածքը տվյալների համար մեզ թողնի սենապատը, (պահանջվում է մաքրելու սկավառակը), ապա ավարտված տարածքը մետադրման համար կհանգեցնի ամբողջ պարի կործանման և անհրաժեշտության այն նորից ստեղծելու։

Պարունակում գտնվող ֆայլային համակարգը ժամանակի ընթացքում շատ է ֆրագմենտացվում: Առաջարկել եմ առօրյա ղեկավարել cron-ի միջոցով fstrim -v /var/lib/mysql.

Միջանկյալ արդյունքներ:

• Տեխնոլոգիան հեշտ է կիրառել, ինչպես նաև ինքն ԼՎՄ-ն, և չի պահանջում հատուկ ինժեների որակավորում:
• Այն լավ կգործի փոքր չափերի և շատ ծանրաբեռնված չեղարկված տվյալների բազաների համար: Ո kol քան փոքր է տվյալների բազան, այնքան քիչ փոփուլներ կտեղափոխվեն ֆայլային համակարգի ներսում և այնքան ցածր է դիսկերի բեռը:
• Մեր խնդրի համար մենք սկսեցինք փնտրել այլ լուծումներ, որի մասին խոսելու ենք հաջորդ բաժնում:

Երկրորդ հնարավորություն, ZFS տեխնոլոգիա

Շատ ժամանակ առաջ ես զբաղվել էի ZFS ֆայլային համակարգով, սակայն այն ժամանակ ZFS-ն լավ էր աշխատում իր բուն օպերացիոն համակարգերի ընտանիքում՝ Solaris-ում: Պոտերֆված տարբերակ կար FreeBSD-ի համար, որը բավականին լավ էր իրականացված: Կար նաև Linux-ի չավարտած պորտ, որն շատ քիչ էր կիրառվում: Բիթ-թերնոն պահելու կառուցվածքի պատճառով (այմպես, որ նաև InnoDB MySQL-ում), ZFS-ն վատ էր ներկայանում շատ ֆայլերով ինստալացիաներում: Ավելին, գիտելիքները, որոնք պետք էին ունենալ ZFS-ի օգտագործման ժամանակ, երկար ժամանակ բաց թողեցին այս ֆայլային համակարգը իմ պրակտիկայից: Մեր կարիքների համար ext4 և xfs ֆայլային համակարգերն արդեն ստանդարտ էին դարձել: Բայց նկատելով, որ մեր խնդրին ZFS-ն ավելի լավ է մոտս գալիս, և ուսումնասիրելով, որ Linux-ի տարբերակը վերածվել է նորմալ արտադրանքի (միայն թե ոչ ամբողջական աջակցությամբ, իսկ այդ պատճառով ZFS-ին լրապես վերափոխվելը պահանջում է տարատեսակ կուռեղեններ), մենք որոշեցինք փորձել այն:

Այն պարզ պատճառներով, մեր ընտրությունը նմանատիպ կոնֆիգուրացիայի էր (դրա մեջ բացառությամբ RAID-կոնտրոլլեր): Մենք տեղադրեցինք ութ SSD-դիսկով՝ 1920 Գբ: Չαγացնելը խավարային կաղապար գրելիս իրանցի ZFS-ին, մենք կտրեցինք ամեն դիսկից 50 Գբ և դրանք համատեղեցինք MD RAID-10-ի ներքո: Ունենք մնացած 1950 Գբ յուրաքանչյուր դիսկի վրա, որոնց վրա հետագայում ստեղծեցինք ZFS-անսպասահար RAID-10:

zpool create zpool mirror /dev/sda2 /dev/sdb2 mirror /dev/sdc2 /dev/sdd2 mirror /dev/sde2 /dev/sdf2 mirror /dev/sdg2 /dev/sdh2

Մենք ստեղծեցինք բաժիններ MySQL-ի համար:

zfs create zpool/mysql
zfs set compression=gzip zpool/mysql
zfs set recordsize=128k zpool/mysql
zfs set atime=off zpool/mysql
zfs create zpool/mysql/data
zfs set recordsize=16k zpool/mysql/data
zfs set primarycache=metadata zpool/mysql/data
zfs set mountpoint=/var/lib/mysql zpool/mysql/data

Ուշադրություն դարձեք, որ մենք միացրեցինք գերարագ gzip տվյալների սեղմումը: Մենք ունենք շատ պրոցեսորային ռեսուրսներ սերվերում և դրանք չեն օգտագործվում ամբողջովին: Արդյունքում 3 Թբ մեր տվյալների բազան վերածվեց 1,6 Թբ, և քանի որ թույլ օղակը, ինչպես նախորդ դեպքում, դիսկերի առավելագույն արտադրողականությունն է, առանձին պարագայում, որքան քիչ տվյալ, այնքան լավ, մենք սկզբից ստանում ենք լավագույն բոնուս ZFS-ից: Փիկ ժամերին gzip-ի աջակցման աշխատանքի վարձում անցնելու ընթացքում մինչև 4 միջուկ է պահանջվում, սակայն մեզ համար դա ոչ մի կարևորություն չունի:

Հետագայում իրականացումը արագացվեց: LVM-կառուցվածքի վրա MySQL-ի պատճենիր ձևը կեսը: Կային որոշ ժամանակ ծախսելու ծախսած ռեժիսորների փոփոխությունների վրա, սակայն ընդհանուր տարիները Հեռանկարներ մնացին նույնը: Տեսակի ստեղծման օրինակ:

zfs set snapdir=visible zpool/mysql/data
zfs create zpool/stage_3307
zfs clone zpool/mysql/data@snapmain zpool/stage_3307/data
zfs set mountpoint=/mnt/stage_3307 zpool/stage_3307/data

Լրացուցիչ տյունինգից. ZFS-պատուհաններն ու l2arc և zil մետա-պետնեները փոխանցվել են հիշողության: մեր խնդիրների համար սա շատ ավելորդ էր, բայց अभी भी թողել ենք այս օպտիմացումը, փոխելն հեշտ է: Դրական ազդեցություններից մեկը - սերվերի վերագործարկումից հետո պետք է վերակենտրվեն համապատասխան հիշողության լույսերը: Դրանք այս ընթացքում չեն կորում: zpool անվանվելու հատված:

logs
      /dev/shm/zil_slog.img  ՕՐԻՏՈՒՆ       0     0     0
cache
      /dev/shm/l2arc.img     ՕՐԻՏՈՒՆ       0     0     0

Այս конфигурацией մենք սկսեցինք փորձարկել стенդը և ստացանք հրաշալի արդյունքներ: երկուսի համագործակցող DB օրինակների (և ակտիվ հիմնական ռեպլիկի) վրա սևերությունում ընկնումը 50-60 % էր:

Մենք ազատվեցինք մեր հիմնական խնդրից, որը կարելի է տեսնել ռեպլիկացիայի հետամնացության գծապատկերում (համեմատեք նախորդ գծապատկերի հետ Thin LVM բաժնում):

Այս և շնորհիվ մենք շատ արագացրեցինք բոլոր գործողությունները: լիարժեք սևերություն ստեղծելը, մոռացնելու և ռեպլիկը սկսելուն, տևում է 40 վայրկյան: նոր MySQL օրինակ տեղափոխելու սևերությունից տևում է 20 վայրկյան: Սա մեզ և մեր ծրագրերի փորձարկումն ավելի քան բավարարում է:

Միջանկյալ արդյունքներ:

• Արդյունքները լիովին բավարարեց մեր անհրաժեշտությունը ստանալ գործող DB-ի արտաքին պատճենը ծրագրի փորձարկման համար:
• Տեխնոլոգիան պահանջում է ուսումնասիրություն: պետք է հասկանալ, թե ինչ է ZFS-ը և ինչպես աշխատել դրա հետ:
• Մենք չհսկեցինք ZFS-ի ներկայումս շատ փոքր ֆայլերով (1 միլիոնից ավել) վիճակը: Սակայն ենթադրվում է, որ խնդիրները պահպանվում են, ուստի ես չեմ խորհուրդ տալիս այդ փաստաթղթերը որպես ֆայլերի պահեստ:

Ի՞նչ կլինի հաջորդը:

Ստենդի շրջանակներում ոչինչ անել չենք ծրագրում, արդյունքը մեզ բավարար է: Հնարավոր է, հետագայում կավելացնենք ռեպլիկացիայի կարգավորումների ցուցակներ, որոնք չեն անհրաժեշտ փորձարկման համար, սա կկրճատի DB-ի ծավալը: Մենք չենք փորձարկել BTRFS համակարգը և դրա իրականացման տեխնոլոգիաները: Այնուամենայնիվ, այդ խնդիրը արդեն չկա, որովհետև հիմնական նպատակն իրականացվել է: Ընդհանուր առմամբ, հաճույքով կուզենայինք մագլցել վերևում նշված մոտեցումից՝ իրականացնել աշխատանքային DB-ի միգրացիաները փորձարկման միջավայրում ստեղծել առանձին փորձարկման DB կոնտուր, զբաղվել հիմնական բազայի շարդինգՈւ: Եւ շատ բաներից արդեն կյանքի ենք բերել, ինչի մասին անպայման խոսելու ենք ապագա հոդվածներում:

Եզրակացություններ

Առաջին խնդիրը լուծվեց, նույնիսկ եթե տարօրինակ ճանապարհով: Փոխհրապարակային արտացոլումներում նկարագրվեցին կիրառված տեխնոլոգիաների առավելություններն ու թերությունները, ուստի եկեք որոշենք, թե որ տեխնոլոգիան և երբ կարելի է օգտագործել:

• Thin LVM — փոքր DB-ների համար և երբ չես ուզում կամ չունես ժամանակ ուսումնասիրելու ZFS-ը:
• ZFS — եթե ունակ եք աշխատել դրա հետ կամ ունեք ժամանակ նայելու համար ցանկացած իրավիճակում:

Բարձր մակարդակի ներկայացման վրա այս հոդվածը ընդամենը երկու ֆայլային համակարգերի տեխնոլոկիայի համեմատություն չէ: Գլխավոր գաղափարը, որը ցանկանում եմ փոխանցել և ամրապնդել, այն է, որ հարկավոր չէ վախենալ մտածել ոչ ստանդարտ կերպով բիզնեսի համար կարևոր իրավիճակներում և վերցնել միայն պատրաստի բաղադրատոմսեր: Մի ժամանակ կարող էինք բոլոր տեխնիկական բաժնում կողքի նայել և ասել, որ երեք տերաբայթանոց տվյալների բազաների բարի ստեղծման առաջադրանքն ավարտել րոպեների ընթացքում անիրագործելի է, և մեզ պետք չեն ռիսկային տեխնոլոգիաներ, եկեք անենք ամեն ինչ ճիշտ: Սա հնարավոր էր, բայց կկորցնեինք մոտ մեկ տարի և շատ հաճախումներ (հաճախումներ՝ մեր հիմնական բիզնեսի ցուցանիշը) առանց փորձերի և իրավունք վերականգնման ժամանակ: Անլայն մտածելակերպն ընդունելով, մենք կորցրեցինք այնքան ժամանակ, որքան պետք էր, փորձ ձեռք բերեցինք նոր և մոռացված հնի տեխնոլոգիաներում, և տրամադրեցինք փորձություն հենց այն պահին, երբ մ իսկապես դրա կարիքը ունեինք: Անկասկած, սա դրական ազդեցություն ստացել է բոլոր մեր ցուցանիշների վրա: Ընտրությունը միշտ ձերն է, իսկ մենք մեր կարգից շարունակելու ենք պատմել մեր բլոգում հետաքրքիր ընթացիկ և ապագայի ձեռքբերումների մասին.

Ընտանիք: habr.com