A legjobb módszer az adatok szinkronizálására két különböző adatbázis között
On január 1, 2021 by adminKét nagy, teljesen eltérő struktúrájú adatbázis között kell szinkronizálnom az adatokat. Alapvetően meg kell ragadnom néhány adatot az első adatbázis különböző tábláinak termékeiről, és újrarendeznem őket a második adatbázis többi táblájához.
A termékeim első létrehozása nem túl bonyolult. De arra törekszem, hogy frissíthessem az egyes termékek egyes adatait – nem minden adatot -.
Nyilvánvalóan van néhány probléma, ami ezt trükkössé teszi.
- Nem tehetek semmit a forrás adatbázison, kivéve a kiválasztott lekérdezéseket.
- A cél adatbázisban szokásos lekérdezéseket tudok végrehajtani (kijelölni, frissíteni, beilleszteni, létrehozni), de a meglévő struktúra / táblák.
- A cél és a forrás db felépítése teljesen eltér, a táblák egyáltalán nem azonosak, ezért az adatokat valóban át kell rendezni – a táblák összehasonlítása nem fog működni.
- A cél adatbázis MySQL szervert használ – a forrás lehet DB2.
- Sehol nincsenek „frissített idő” mezők.
Tehát az egész folyamatot a egyetlen Python (ideális esetben) szkript.
Gondolkodom azon, hogy hozzon létre egy kivonatot minden termékhez, a cél adatbázis frissítendő mezői alapján: md5 (kód + leírás + szállító + körülbelül 10 másik mező). Ugyanazon adatokon alapuló új hash jön létre naponta a forrás adatbázisból. Az összes kivonatot egyetlen táblázatban tárolom (tételkód, current_hash, old_hash), előadás céljából. Ezután hasonlítsa össze és frissítse a terméket, ha az új kivonat eltér a régitől.
Körülbelül 500 000 termék található, ezért “kicsit aggódom a teljesítmények miatt.
Ez jó hogyan tovább?
Megjegyzések
- Azt akarják, hogy te is bekötött szemmel tedd? Ez ‘ s most a problémám …
- @Now, hogyan ment? Van valami tanácsod, amit most tudsz ajánlani?
- @EdwinEvans alapvetően az első ötletemnél maradtam, de főleg a megszorításokhoz. A szkriptem md5 kivonatokat hoz létre az összes elem kulcsadatai alapján. Ezután összehasonlítom a korábbi hashokkal. Ha a hashek eltérnek, akkor az elem összes adatait betölti és mindent frissít. Nem biztos benne, hogy ez a legjobb módon, de éjszaka fut, és az előadások rendesek.
Válasz
Nagyjából ez van nekem az elmúlt néhány évben vagy élt, és az én benső ösztönöm az, hogy ideje 500 000 tételt elolvasni a forrás adatbázisokból Az e és a szinkronizálás a célállomáson nem fog annyi időt igénybe venni, mint gondolnánk, és a “kulcs” mezők elolvasásához, az MD5 kivonat kiszámításához és az asztalhoz történő keresztellenőrzéshez szükséges idő, hogy elkerülhetők legyenek azok az elemek, amelyek még nem változtak ” Túl sok időt takarít meg, és még tovább is futhat. Egyszerűen elolvasnám az összeset és frissítenék az összeset. Ha ez túl hosszú futási időt eredményez, akkor tömörítem a futási időt azáltal, hogy az ETL-t menetes szálúvá teszem, és mindegyik szál csak a táblázat egy szegmensében működik, de párhuzamos.
Fontos biztosítani, hogy a céladatbázis elsődleges kulcsindexsel vagy egyedi indexsel rendelkezzen. Ellenkező esetben minden egyes frissítése / beillesztése lezárhatja az egész táblázatot. Ez rossz lenne, ha többszálú megközelítést alkalmazna, de akkor is fontos, ha továbbra is egyszálú marad, mert a munkája lezárhatja a cél DB táblázatot, és zavarhatja az adott adatbázis tetején közlekedő alkalmazást.
Azt mondod, hogy a forrás DB “lehet DB2”. Amikor azt mondod, hogy “lehet”, az azt jelenti, hogy a DB-t még mindig tervezik / tervezik? A DB2 9 vagy újabb verzió beépített nyomon követi az utolsó frissítés idejét, és csak azokat az elemeket tudja lekérdezni és visszakeresni, amelyek megváltoztak egy adott időpont óta. Talán ezért tervezték a DB-t, hogy ne legyen oszlopa az utolsó frissítés idejéről, például:
SELECT * FROM T1 WHERE ROW CHANGE TIMESTAMP FOR TAB t1 > current timestamp - 1 hours;
A fenti lekérdezés időbélyeg-levágása a szinkronizálás utolsó időbélyege.
Ha ez a helyzet, akkor ez megoldja a problémát. De a megoldás végül nagyon szorosan kötődik a DB2-hez, és a jövőben esetleg át akarnak költözni egy másik DB platformra, és elvárják, hogy a szinkronizálási munkádat ne kelljen újra felkeresni. Fontos tehát megbizonyosodni arról, hogy minden megfelelő ember tudja-e, hogy a terméke függ a DB2-től való megmaradástól, vagy ha át kívánják állítani, akkor az átállítás magában foglalná a DB szerkezetátalakítását, hogy egy “utoljára módosított időbélyeg” oszlop legyen, és készítsen bármit A mező feltöltéséhez az alkalmazás szintjén szükséges változtatások.
Megjegyzések
- létezik hasonló megoldás a mysql-re is?
Válasz
Az adatok szinkronizálása sokkal jobb és gyorsabb lenne, ha valamilyen delta azonosító vagy zászló alapján meg lehet valósítani. Alapvetően csak akkor kell frissítenie a megcélzott db adatsorokat, ha azok nincsenek szinkronban a forrás db-vel.
Az SQL szerver db-ban a delta alapú azonosító elkészítéséhez igénybe veheti a Checksum fn segítségét is.
Fejlesztenie kell egy SQL alapú feladatot hogy a nap vagy éjszaka egy bizonyos szakaszában meghívják, hogy elinduljon ez az sql logika. Jobb éjszakai SQL-munkaként futtatni, amikor a db-használat nagyon alacsony. Ha a forrás és a megcélzott db rekordok delta nem egyezik, akkor csak ezeket a rekordokat húzza. De hátránya az lenne, ha minden alkalommal kiszámítanánk a forrásadatsorok ellenőrző összegét, majd összehasonlítanánk a céladatokkal.
Ha van egy olyan oszlop, mint a “LastModifiedDate” a forrás db táblákban, akkor kihagyhatja az ellenőrző összeg megközelítést. Így az értékelés a dátum alapú oszlopban fog végrehajtódni, és kevesebb időt vesz igénybe az ellenőrző összeg megközelítéséhez képest.
Megjegyzések
- Köszönöm, de én ‘ nem vagyok biztos benne, hogy a megoldás működhet-e – lásd a szerkesztéseimet a ” kérdésekben ” rész.
- Mivel a forrásadatbázisban nincsenek frissített időmezők, ezért az ellenőrző összeg vagy a kivonat alapján a minősített adatsorokat kell meghúzni. db2. Hogyan szándékozik levonni belőle az adatokat? valamilyen webszolgáltatáson vagy API-n keresztül.
- Egy dsn-t egy odbc illesztőprogram segítségével állítottak be. Csatlakozhatok és lekérdezéseket tehetek a Pyodbc for Python használatával.
- Rendben van ez jó, mivel a lekérdezéseket a PyODBC nevű eszköz segítségével hajthatja végre a távoli DB-ben. Még egyet tehet. A termékadatokat egyenesen, ugyanabban a formátumban húzhatja be az új ” szakaszoló táblába ” a cél DB-ben minden ellenőrzés nélkül. vagy validációk. Így az élő adatokat egyetlen lövésként megkapja a céldobozban a színpadi táblák alatt. Ezután a második lépésben elvégezheti az ellenőrző összegű műveleteket, és frissítheti a tranzakciós céladatok céladatait. Ez megakadályozná a hash vagy az ellenőrző összeg valós idejű kiértékelését a forrás db adatokkal.
Válasz
A kivonat használata jó ötlet. Mivel ebben az esetben nem a biztonság a cél, válasszon gyors hash függvényt (az md5 rendben van).
Hacsak nem tervezi a hash kiszámítását több szálra / folyamatra bontani, akkor nem igazán kell Ha a folyamat egyetlen szkript, akkor az aktuális kivonat csak a memóriában lesz, és azt írja be az adatbázisba, mint a régi kivonatot, miután frissítette az adatokat az új adatbázisban.
Válasz
létre kellett hoznia egy Windows szolgáltatást, amely bármikor futni fog a spiffif időpontokban, és megtalálja a változásokat a forrásadatbázisba, és illessze be a változásokat a céladatbázisba.
Megjegyzések
- -1 (didn ‘ t igazán visszavonja, de;) csak a windowsos javaslathoz. A ‘ s ne támaszkodjanak semmilyen konkrét architektúrára a szoftver fejlesztésekor, ez csak azt jelenti, hogy csak kevesen használhatják a cuccait. az egyetlen consta Az nt a változás, ezért ‘ jobb, ha nem támaszkodunk egyetlen olyan platformra sem, amely megkönnyíti a dolgok fenntartását magának és a felhasználóknak
- @manish kumar a ” rész meg fogja találni a változásokat a forrásadatbázisában ” a legnehezebb!
Vélemény, hozzászólás?