Igényfelmérés: Adatbázis integrációs eszköz

Adatbázis: SQL, XML DB

Sziasztok,

Piackutatást végeznék. Adatok migrálásával kapcsolatban a következő dolgok érdekelnek, leginkább Linux alapú rendszereken:
1. Milyen disztribúciót használtok?
2. Milyen adatbáziskezelő rendszert használtok (több is megadható)?
3. Milyen eszközt használtok adatbázisok migrálására?
4. Migrálás közben használtok/használnátok transzformációkat?
5. Mik azok a kritériumok, amelyek teljesülése esetén lecserélnétek meglévő adatmigrációs eszközötöket?
6. Milyen migrálásokat végeztek? (Ad-hoc, időzített betöltés)
7. Adatmigráció milyensége (ETL folyamatok, backup készítés, OLTP adatbázisok szinkronizálása).

RDBMS built-in feature-ök nem játszanak (pl replikáció), illetve a dump alapú mentések sem, jellemzően tábla adatok migrációjáról van szó.

A válaszokat előre is köszönöm. Ha felmerülne még kérdés, akkor azt update-ként veszem fel.

  • 1981 megtekintés

( andrej_ v | 2016. 01. 19., k – 12:34 )

Visszakérdezek. Mit értesz migrálás alatt. Egy mentés vagy visszatöltés nekem annyira nem tűnik migrációnak és remek toolok vannak rá.

+1
Migralas alatt mi azt ertjuk ha pl van egy raklap adatom db2 -ben es azt at kell mondjuk pakolni MSSQL szerverekre.

A kerdes nekem kicsit sekelyes. A migralando adatok/rendszerek alapjan dol el mit hasznalunk hozza de ez mindig egyedi projekt. Maskulonben garantalt az adatvesztes

Konkrét példa:
Van egy webshopod, vásárolsz egy 3rd party vásárlás elemző alkalmazás. Importálnod kell az alkalmazásba az adatokat napi szinten. Az egyszerűség kedvéért mindkét rendszer MySQL-t használ. Minden nap éjfél után ütemezetten töltöd át csak az előző napi adatokat egyik adatbázisból a másikba, majd a túloldalon meghívsz egy tárolt eljárást.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Valszeg közvetlenül SQL-ben, vagy ha mókolni kell, akkor SQL -> alkalmazás -> SQL útvonalon. Ha meg a rendszergazdát találják meg vele, akkor *sqldump | awk | *sql féle rettenet is szóba jöhet :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igy van, kiexportálja a fejlesztő az adatbázist SQL insert scriptekbe, létrehozza a másik adatbázist az új adatbáziskezelőnek megfelelően, aztán
szépen befuttatja az insert scripteket, és ha esetleg hibát talál, akkor javítja. Ha szerencséjük van, akkor nem nagyon volt üzleti logika adatbázis
kódban megvalósítva, hanem a rendszer csak egy buta tárolóként használta. Ha nincs szerencséjük, akkor lehet mindenféle ügyes megoldással találkozni,
beágyazott eljárások, triggerek, írható view-k, JSON manipulációk, és még sorolhatnám. Mi pl. ezeket mind használjuk, PostgreSQL alatt.

És itt van a kutya elásva, mert ugye egy harmadik rendszerre közel sem triviális az átállás, amennyiben sok ilyen feature van használva. De mondok
egy pozitiv példát: egy korábbi adatbázisunknál egy mySQL -> PostgreSQL migrációt hajtottunk végre, ott pl. nagyon egyszerű volt az átállás.

Az OP-ból ítélve ő kevésbé az ilyen egyszeri migrációkban, mint a napi/óránkénti/percenkénti szinkronizációban gondolkodott, amikor már inkább buta tárolóként való használat játszik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Akkor itt lehet a kutya elásva, nem értettem, hogy miért nem értitek, bár a példa szerintem elég szemléletes :)
Itt nem egyszerűen arról van szó, hogy átköltözteted az adatbázist egy MySQL-ből mondjuk Oracle-be, attól sokkal több. Jellemzően nem egyezik a forrás és a cél adatbázis szerkezete, átalakításokat kell csinálni, az adattisztításról nem is beszélve. A logolás is egyszerűbb lenne.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Ilyenkor a világon semmit se kellene ügyfél szinten transzformálni. A kedves másikrendszer elmondja, hogy milyen mezőkre van szüksége vagy mi táblasémába kell betölteni és egy INSERT INTO .... (SELECT.... ) jellegű lekérdezéssel akár meg is oldható adatbázis szerveren belül. Ha több kell, akkor egy ízlés szerinti nyelvet (perl, pyhton, php stb) közéraksz és átmennek az adatok.

Semmit se kellene, de a gyakorlat azt mutatja, hogy kell. Te x-nek hívod a rendszeredben, a 3rd party y-nak, Te az egyik entitást denormalizálva tárolod, a másikat 3NF-ban, a 3rd party fordítva. Erre szoktak dictionary táblákat használni, de oda is transzformáció kell. Korábban itt az egyik hozzászólásban séma transzformációnak becézték, de hívjuk inkább adat transzformációnak.
Proaktívan megválaszolom a következő hozzászólásod is: Van az a pénz.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

FYI: általában a mysqlből mondjuk oracleba baromira nem triviális, mert egy csomó mindent változtatni kell (ha nem kéne, akkor általában nem csinálunk ilyesmit, mert minek. /azon ritka esetekben, meg mikor mégis, akkor meg nagyjából export/import köszöni elég, nem kell tool/), ráadásul általában a kapcsolódó rendszerekkel is van mindenféle okosság.

Ha jól értem, te ehelyett valami importerről / generic adatbázis illesztőről vizionálsz, gondolom azért, hogy valami külső forrásból rendszeresen át lehessen emelni adatokat (gondolom valami tábla mapping ruleok, etc). Nem vagyok benne biztos, hogy lehet olyat csinálni ebből, ami hasznos: ha kóder van, akkor valószínű, hogy megoldja maga is, nem lesz vele előrébb, ha meg nem kóder, akkor akármi, ami eclipseben van túl bonyolult :)

Itt visszacsatolnék a 10 sor kód hozzászólásra. Értem én, hogy kraftos az awk, de egy inkrementális töltést, amit a példámban írtam, nem lehet könnyű megírni (nyilván nem lehetetlen, de erre lenne ez az eszköz, ami megkönnyíti egy DBA/fejlesztő/üzemeltető dolgát), a transzformációkról nem is beszélve. Ehhez lenne egy tool és egy fejlesztői környezet (kezdetben Eclipse alapokon), ami grátiszként Windows Serveren is fut.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

Ha DB adminnak kell csinálnia az adatok periodikus áttöltését (ne hívjuk már migrációnak) akkor ő nyilván a bash/awk/python vonalon fog ügyeskedni,
de az esetek többségében ezt egy fejlesztő fogja megoldani. A magam részéről nagyon nem szeretném, ha egy 3rd party komponens megnyitná a kis adatbázisát
felém, adjon egy jól definiált interface-t, amin kommunikálni fogunk, aztán hogy belül ő hogy és mit tárol, az legyen az ő problémája.

( SzBlackY | 2016. 01. 19., k – 18:26 )

Belepofa: gondolom egy alkalmazást akarsz írni, ami tetszőleges rendszerek közt tud migrálni, akár transzformációkkal együtt is. Gondolkodtál pl. olyanban, hogy eltérő természetű adattárolók között (flat file, LDAP, relációs adatbázis, document store, táblázatkezelő ...) között tudjon migrálni? Egy ilyen (elég általánosra megírt) alkalmazás akár hasznos is lehet, az más kérdés, hogy elég masszív PITA hibamentesre (alaphangon az irányok nagy része veszteséges, nagyon változatos, hogy milyen szinten tudsz tranzakciókat kezelni stb.) és még inkább gyorsra megcsinálni :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Bingo.
Flat file mindenképpen (csv és fix) támogatott lesz első körben. Adatbáziskezelők közül az SQL Server, Postgre és MySQL lesznek kezdetben támogatva, aztán kibővítjük.
A transzformációk közül szintén az egyszerűek lesznek először implementálva.

-----------
"Pontban 0:00-kor nem nagyon szoktak véletlen dolgok történni"

( atomheart v | 2016. 01. 20., sze – 10:41 )

Ha jol ertem, olyansmit szeretnel, mint a Navicat Premium "Data Transfer", "Data synchronization" es "Schedule" ficsorei?

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

( dong0 v | 2016. 01. 20., sze – 13:17 )

Az eddig leirtak alapjan oracle warehouse builder szeruseget keresel szerintem.