Посматрајући развој корпоративног софтвера из првог реда током две деценије, јасан је неоспоран тренд последњих неколико година – премештање база података у облак.
Већ сам био укључен у неколико пројеката миграције, где је циљ био да се постојећа локална база података доведе у Амазон Веб Сервицес (АВС) Цлоуд базу података. Док ћете из АВС документационих материјала сазнати колико то може бити лако, овде сам да вам кажем да извршење таквог плана није увек лако и да постоје случајеви у којима може да пропадне.
У овом посту ћу покрити искуство из стварног света за следећи случај:
- Извор: Иако у теорији није битно који је ваш извор (можете користити веома сличан приступ за већину најпопуларнијих ДБ-ова), Орацле је био систем базе података који је био избор у великим корпоративним компанијама дуги низ година, и ту ће бити мој фокус.
- Циљ: Нема разлога да будете конкретни са ове стране. Можете одабрати било коју циљну базу података у АВС-у, а приступ ће и даље одговарати.
- Режим: Можете имати потпуно или постепено освежавање. Скупно учитавање података (изворно и циљно стање су одложено) или (скоро) учитавање података у реалном времену. И једно и друго ће се овде дотакнути.
- Учесталост: Можда ћете желети једнократну миграцију праћену потпуним преласком на облак или захтевати неки прелазни период и ажурирање података са обе стране истовремено, што подразумева развој дневне синхронизације између локалног и АВС-а. Први је једноставнији и има много више смисла, али други је чешће тражен и има далеко више тачака прекида. Овде ћу покрити оба.
Преглед садржаја
Опис проблема
Захтев је често једноставан:
Желимо да почнемо да развијамо услуге унутар АВС-а, па вас молимо да копирате све наше податке у „АБЦ“ базу података. Брзо и једноставно. Сада морамо да користимо податке унутар АВС-а. Касније ћемо схватити које делове дизајна ДБ да променимо да би одговарали нашим активностима.
Пре него што кренете даље, постоји нешто што треба размотрити:
- Немојте пребрзо ускочити у идеју „само копирајте оно што имамо и позабавите се тиме касније“. Мислим, да, ово је најлакше што можете да урадите, и биће урађено брзо, али ово има потенцијал да створи тако фундаментални архитектонски проблем који ће касније бити немогуће решити без озбиљног рефакторисања већине нове платформе у облаку . Замислите само да је екосистем у облаку потпуно другачији од локалног. Временом ће бити уведено неколико нових услуга. Наравно, људи ће почети да користе исте веома различито. Готово никада није добра идеја реплицирати локално стање у облаку на начин 1:1. Можда је у вашем конкретном случају, али обавезно ово још једном проверите.
- Доведите у питање захтев уз неке значајне сумње као што су:
- Ко ће бити типични корисник који користи нову платформу? Док је он-премисе, може бити трансакцијски пословни корисник; у облаку, то може бити научник података или аналитичар складишта података, или главни корисник података може бити услуга (нпр. Датабрицкс, Глуе, модели машинског учења итд.).
- Да ли се очекује да ће редовни свакодневни послови остати чак и након преласка на облак? Ако не, како се очекује да се промене?
- Да ли планирате значајан раст података током времена? Највероватније је одговор да, јер је то често једини најважнији разлог за миграцију у облак. За то ће бити спреман нови модел података.
- Очекујте да крајњи корисник размисли о неким општим, очекиваним упитима које ће нова база података добити од корисника. Ово ће дефинисати колико ће се постојећи модел података променити да би остао релевантан за перформансе.
Подешавање миграције
Када је циљна база података изабрана и модел података је на задовољавајући начин размотрен, следећи корак је упознавање са алатом за конверзију АВС шеме. Постоји неколико области у којима овај алат може послужити:
Референца: АВС документација
Сада постоји неколико савета за коришћење алата за конверзију шеме.
Прво, скоро никада не би требало да буде случај да се излаз користи директно. Ја бих то више сматрао референтним резултатима, одакле ћете вршити своја прилагођавања на основу вашег разумевања и сврхе података и начина на који ће се подаци користити у облаку.
Друго, раније су табеле вероватно бирали корисници који су очекивали брзе кратке резултате о неком конкретном ентитету домена података. Али сада би подаци могли бити одабрани у аналитичке сврхе. На пример, индекси базе података који су раније радили у локалној бази података сада ће бити бескорисни и дефинитивно неће побољшати перформансе ДБ система у вези са овом новом употребом. Слично томе, можда ћете желети да другачије партиционирате податке на циљном систему, као што је то било раније на изворном систему.
Такође, можда би било добро размислити о обављању неких трансформација података током процеса миграције, што у основи значи промену циљног модела података за неке табеле (тако да више не буду копије 1:1). Касније ће се правила трансформације морати имплементирати у алат за миграцију.
Ако су изворна и циљна база података истог типа (нпр. Орацле он-премисе вс. Орацле у АВС-у, ПостгреСКЛ вс. Аурора Постгрескл, итд.), онда је најбоље користити наменски алат за миграцију који конкретна база података подржава изворно ( нпр. извоз и увоз пумпе података, Орацле Голденгате, итд.).
Међутим, у већини случајева, изворна и циљна база података неће бити компатибилне, и тада ће очигледан алат за избор бити АВС Датабасе Мигратион Сервице.
Референца: АВС документација
АВС ДМС у основи омогућава конфигурисање листе задатака на нивоу табеле, која ће дефинисати:
- Који је тачан изворни ДБ и табела за повезивање?
- Спецификације исказа које ће се користити за добијање података за циљну табелу.
- Алати за трансформацију (ако их има), који дефинишу како ће изворни подаци бити мапирани у податке циљне табеле (ако није 1:1).
- Која је тачна циљна база података и табела за учитавање података?
Конфигурација ДМС задатака се врши у неком формату прилагођеном кориснику као што је ЈСОН.
Сада у најједноставнијем сценарију, све што треба да урадите је да покренете скрипте за примену на циљној бази података и покренете ДМС задатак. Али има много више од тога.
Једнократна пуна миграција података
Најлакши случај за извршење је када је захтев да се цела база података једном премести у циљну базу података у облаку. Тада ће у суштини све што је потребно да урадите изгледати овако:
Ако је конфигурација ДМС-а урађена добро, ништа лоше се неће догодити у овом сценарију. Свака појединачна изворна табела ће бити покупљена и копирана у АВС циљну базу података. Једина брига ће бити извођење активности и уверавање да је величина исправна у сваком кораку како не би пропала због недовољног простора за складиштење.
Инкрементална дневна синхронизација
Овде ствари почињу да се компликују. Мислим, ако би свет био идеалан, онда би вероватно добро функционисао све време. Али свет никада није идеалан.
ДМС се може конфигурисати да ради у два режима:
- Пуно оптерећење – подразумевани режим описан и коришћен горе. ДМС задаци се покрећу или када их покренете или када је планирано да почну. Када се заврши, ДМС задаци су готови.
- Цханге Дата Цаптуре (ЦДЦ) – у овом режиму, ДМС задатак се извршава непрекидно. ДМС скенира изворну базу података за промену на нивоу табеле. Ако се промена догоди, она одмах покушава да реплицира промену у циљној бази података на основу конфигурације унутар ДМС задатка који се односи на промењену табелу.
Када идете на ЦДЦ, морате направити још један избор – наиме, како ће ЦДЦ издвојити делта промене из изворног ДБ-а.
#1. Орацле Редо Логс Реадер
Једна опција је да изаберете изворни читач редо дневника базе података из Орацле-а, који ЦДЦ може да користи за добијање измењених података и, на основу најновијих промена, реплицира исте промене у циљној бази података.
Иако ово може изгледати као очигледан избор ако се ради о Орацле-у као извору, постоји квака: Орацле редо логс читач користи изворни Орацле кластер и тако директно утиче на све друге активности које се извршавају у бази података (заправо директно креира активне сесије у база података).
Што више ДМС задатака конфигуришете (или више ДМС кластера паралелно), вероватно ћете више морати да повећате Орацле кластер – у суштини, прилагодите вертикално скалирање вашег примарног Орацле кластера базе података. Ово ће сигурно утицати на укупне трошкове решења, још више ако ће дневна синхронизација остати са пројектом током дужег временског периода.
#2. АВС ДМС Лог Минер
За разлику од горње опције, ово је изворно АВС решење за исти проблем. У овом случају, ДМС не утиче на изворни Орацле ДБ. Уместо тога, копира Орацле редо логс у ДМС кластер и тамо обавља сву обраду. Иако штеди Орацле ресурсе, то је спорије решење, јер је укључено више операција. Такође, као што се лако може претпоставити, прилагођени читач за Орацле редо логс је вероватно спорији у свом послу као изворни читач из Орацле-а.
У зависности од величине изворне базе података и броја дневних промена у њој, у најбољем случају, можда ћете завршити са инкременталном синхронизацијом података из локалне Орацле базе података у АВС цлоуд базу података у скоро реалном времену.
У било ком другом сценарију, и даље неће бити синхронизација у реалном времену, али можете покушати да се приближите што је могуће ближе прихваћеном кашњењу (између извора и циља) подешавањем конфигурације перформанси изворног и циљног кластера и паралелизма или експериментисањем са количину ДМС задатака и њихову дистрибуцију између ЦДЦ инстанци.
Можда бисте желели да сазнате које промене изворне табеле подржава ЦДЦ (као што је додавање колоне, на пример) јер нису подржане све могуће промене. У неким случајевима, једини начин је да ручно промените циљну табелу и поново покренете ЦДЦ задатак од нуле (успут губећи све постојеће податке у циљној бази података).
Када ствари крену наопако, без обзира на све
Научио сам ово на тежи начин, али постоји један специфичан сценарио повезан са ДМС-ом где је обећање о свакодневној репликацији тешко постићи.
ДМС може обрадити редо дневнике само одређеном брзином. Није важно да ли постоји више инстанци ДМС-а који извршава ваше задатке. Ипак, свака ДМС инстанца чита редо дневнике само једном дефинисаном брзином и свака од њих мора да их прочита у целини. Чак није ни важно да ли користите Орацле редо логс или АВС лог минер. Обојица имају ову границу.
Ако изворна база података укључује велики број измена у току дана да Орацле редо логи постају заиста лудо велики (као 500 ГБ+ велики) сваког дана, ЦДЦ једноставно неће функционисати. Репликација неће бити завршена пре краја дана. То ће донети неке необрађене радове до следећег дана, где већ чека нови сет промена које ће се реплицирати. Количина необрађених података ће само расти из дана у дан.
У овом конкретном случају, ЦДЦ није био опција (после многих тестова перформанси и покушаја које смо извршили). Једини начин да се осигура да ће се бар све делта промене из текућег дана реплицирати истог дана био је приступ на следећи начин:
- Одвојите заиста велике столове који се не користе тако често и поновите их само једном недељно (нпр. током викенда).
- Конфигуришите репликацију не тако великих, али још увек великих табела да буду подељене између неколико ДМС задатака; једна табела је на крају мигрирана са 10 или више одвојених ДМС задатака паралелно, обезбеђујући да је подела података између ДМС задатака различита (овде је укључено прилагођено кодирање) и да се они извршавају свакодневно.
- Додајте још (у овом случају до 4) инстанце ДМС-а и равномерно поделите ДМС задатке између њих, што значи не само по броју табела већ и по величини.
У основи, користили смо режим пуног учитавања ДМС-а за реплицирање дневних података јер је то био једини начин да се постигне барем завршетак репликације података истог дана.
Није савршено решење, али још увек постоји, и чак и након много година, и даље функционише на исти начин. Дакле, можда ипак није тако лоше решење. 😃