Adatbázis: SQL, XML DB

Sziasztok,
egy olyan problémával szembesültem, hogy van egy néhány millió rekordos DB, amiből visszamenőleg törölni kellene (6 évnyi adatot) lehetőleg az integritás megtartásával. Mivel a DB maga idegen kulcsokkal és megfelelő kapcsolatokkal lett felépítve, így ezekre tudnék támaszkodni.

Nincs beállítva sehol sem cascade delete (szándékosan, az eredeti DB-ből kézlevágás mellett lehetne törölgetni csak), így a törlés az integritás megőrzésével maximum táblánként lehetséges, ami egy elég hosszadalmas folyamat lenne.

Egy táblában van a főadat, ott megfelelően vannak mentve a timestamp-ek, és az ezekhez kapcsolódó rekordokat (amit ez fog) kellene eldobni, illetve azokat amit már nem fog semmi (ugyan a DB így lett felépítve, de előfordulhatnak benne esetlegesen korai inkonzisztens adatok).

Gondoltam olyan joinos megoldásokra, ahol a másik oldal null azokat a sorokat eldobom, de ez enyhén szólva is macerás első nekifutásra (de ez marad, ha nincs más, mert ez is relatíve kevés melóval megoldható).
Kb. 10-15 egymáshoz kapcsolódó táblából törölni kellene a hozzá tartozó dolgokat, így ez egy jópár órás feladat lenne.

A kérdésem: Van-e olyan módszer amivel csak az "árva" adatokat dobjuk el, amit nem fog semmilyen idegen kulcs?

Előre is köszi az ötleteket!

Sziasztok!

Van egy X csomopontbol allo Vertica furtunk Red Hat-on. Nehany napja erdekes esemenyt figyeltunk meg: az egyik csomoponton (x1) a os "load average" erosen megno: felmegy olyan 15-re ( a tobbi csomopontnal ez kb 2) de a CPU hasznalat normalis marad. 32 core van mindegyik box-ban, szoval ez load average nem tunik annyira veszenek, de a DB exceution time egekbe szokik.
Ugye ez disk I/O problemanak tunik.

A megoldast keseve merult fel a kerdes, hogy lehetseges-e Verticaban, hogy egy csomoponton megtiltsuk uj session-ok nyitasat, de hagyuk a mar megnyitottakat rendben befejezni. Ahogy en tudom, ha leallitjuk a DB a box-on akkor az azonal elvagja a sessionokat (1. kerdes: Ez igaz?):
1. idea: valami Vertica parancs ami ezt megoldja. 2. kerdes: Van valami ilyen parancs?
2. idea: az alkalmazasok egy virtualis IP cimen erik el az egesz furtot. Hogy mukodik ez pontosan? 3. kerdes: Az alkalmazasok folyamatosan ezzel a VIP-vel komonikalnak, vagy point-to-point kapocsalat epul ki a box es az alkalmazas kozott (Erre tipelek, de nem vagyok bizots benne)? 4. kerdes: Szoval ha letiltom a VIP a box tuzfalan mi tortenik?

Szertenem tisztan latni mi tortenik pontosan egy session megnyitasatol a bezarasaig, szoval ha valaki az elmeletet is el tudna magyarazni (vagy linkelni egy angol | magyar cikket ami ezt megteszi.).

Üdv mindenkinek ezen a meleg szombaton!

Ahogy a címben is írtam, olyan Workbench alternatívát keresek amely képességeiben vele összemérhető, csak ezzel a használhatatlan vacakkal ellentétben működik is. Már átfutottam ezt a szálat, de gondoltam inkább nyitok egy frissebbet.

DB tervezéshez és lekérdezések szerkesztéséhez kellene az új eszköz. Nem baj, ha nem FOSS, az sem baj ha fizetni kell érte, amíg hajlandó működni, és értelmes az ár (néhány 10 euró).

Előre is köszönök minden tippet!

Egyébként ez volt az a bug, ami után eldöntöttem, hogy képtelen vagyok tovább együtt élni ezzel a vacakkal.

Sziasztok!
Csináltam egy ilyen lekérdezést egy könyvelési program adatbázisára Postgresql alatt:
SELECT
tszem.mutato,
tszem.szemszam,
tszem.nev,
tszem.ir_szam,
thely.helyseg,
tszem.ut,
konyv.kk,
konyv.tetjel_k,
konyv.adonem_k,
konyv.szla_tip,
konyv.marad
FROM
public.tszem,
public.thely,
public.konyv
WHERE
tszem.mutato = konyv.k_kulcsn AND
thely.ir_szam = tszem.ir_szam AND
konyv.m_datum <= '2009-12-31';
tszem: személyes adatok
thely: település
konyv: könyvelési adatok
A konyv.marad numerikus, azt kellene sum függvénnyel összesíteni, a tszem.mutato alapján kéne group by. Ha viszont a select alatt a sum(konyv.marad)-ot adok meg, akkor a GROUP BY klausa alatt kéri az összes nem sum-os mezőt, a konyv.m_datum mivel egyedi, így majdnem ugyanazt adja vissza, mint GROUP BY nélkül. Biztos, valami subselect kéne, csak nem vágom, hogy mire. konyv.m_datum amúgy DATE. Valakinek volna valamilyen ötlete?
A tszem.mutato egyedi, konyv.k_kulcshoz kapcsolódik, az a konyv táblában többször is megjelenik.

Van egy mysql (innodb) adatbazisom, amiben csomo tabla van. De ezek kozott van 2 (nem nagy, max. par MB meretu) tablam, amit at kene vinni tobb gepre (szinten mysql szerverek futnak rajta). A replikalast azert tettem idezojelbe, mert nem csak mysql szinten tortento replikacio johet szoba, a lenyeg az, hogy az A gepen levo table1 es table2 tablak tartalma menjen at a B, C, D, ... gepek table1, table2 tablaiba (de az A gepen levo table3, table4, ... mar ne). Az egesz ugy lenne szep, hogy ha az adott slave gepen (pl. B) megtortenik a frissites, akkor rogton / nem sokkal utana le tudok futtatni egy shell scriptet.

Hogy lehet ezt szepen megoldani?

Udv!

Van egy nagy adatbazis (meretileg talan 500GB lehet, de ami fontosabb, hogy 396 model(django) van benne, ami 428 tablat hasznal), amit szeretnek rendszeresen klonozni. No de nincs szuksegem az osszes adatra, hanem csak egy kis reszere. Akar 20 adat minden tablabol eleg lenne.

A problemat az okozza, hogy rengeteg constraint talalhato benne, igy ha veszem minden tablabol az utolso 20 adatot, alig lesz valami, amit tenyleg importalni tudok, es nem hibas adat lesz. Nyilvan itt a sorrendet kellene felderiteni, de ez igen nagy munka lenne ennyi adatnal.

Valami olyan megoldast keresek vegso soron, amivel az adatbazist eles rendszerbol at tudom masolni teszt rendszerbe egy minimalis adatmennyiseggel. A rendszer maga django alapu, es az osszes tabla is django alapon lett letrehozva.

Amiket probaltam: valamilyen modon exportalni a szukseges adatokat (serializer, pickle, cPickle), fileba kiirni, beolvasni a tuloldalon, es importalni (deserializer, pickle, cPickle), de ezek mind hibasak lettek a contrainek miatt.

Barmilyen otlet erdekel :- ).

Koszi a valaszokat.

Üdv,

Van egy egyszerű adatmodellem:

Jó sok ilyen kapcsolat van és minél gyorsabban kell őket elérném, egymás után, tetszőleges sorrendben. Az adatokat felépítem, feldolgozom és aztán mehetnek a levesbe, nincs szükség perzisztenciára. Az adatok feltöltését és feldolgozását mindenképp szeretném elkülöníteni, ezek más-más nyelveken lesznek implementálva. A tárolást megoldhatnám egy újabb processzel, de annyi féle adatbázis létezik, minek gyártanék mégegyet - gondoltam.

A betöltést és a feldolgozást is több processz végzi párhuzamosan. Betöltésnél a forrásanyagban a way-ek és node-ok rendezetlenül vannak és szeretném elkerülni, hogy a betöltő processzben rendezni kelljen őket, erre nem optimális a nyelv amiben implementáltam (ruby). A feldolgozás fázisában a "state" flag jelzi, hogy feldolgozott-e már a way (feldolgozás után nem dobhatom azonnal, mert az exportálást egy újabb processz végzi).

A feldolgozás egy processze egy időben egy way-en dolgozik, az összes node-ját elemezve. A feladat, hogy a processz hatékonyan hozzáférjen az adathoz.

Néhány adat:
- ways: kb 4M objektum
- nodes: kb 80M objektum
- feldolgozás elvárt sebessége: 10.000 ways/s/processz

Te hogy oldanád meg..? Mindenféle ötlet érdekel, csak az nyelv ami kötött: ruby. Java-ban lehet, hogy a loader hatékonyabban tudná rendezni az adatokat és nem lenne szükség arra, hogy a DB kezeljen kapcsolatokat, de ez első körben nem opció.

(Egyébként OpenStreetMap adatok feldolgozásáról van szó.)

UPDATE: Nincs szükség arra, hogy a DB kezelje a relációkat: első lépésben a Way-eket töltöm be adatbázisba és közben építek egy hash-t:

$node_ways[node_id]->[way1_id,way2_id,...]

- majd jönnek a node-ok és találat esetén hozzácsapja a meglévő rekordhoz a node-ot (sql: UPDATE, redis: RPUSH/APPEND). Bár ez jelentősen megdobta a memóriaigényt a ruby loaderben, de tegyük fel, hogy ezt megoldom valahogy. Viszont a feladat még ettől adott: hogy/hol tároljam ezeket a sorokat?

Üdv!

Azután érdeklődnék, hogy VPS-re v. M$ Azure Cloud szolgáltatásra érdemes tenni az alábbi adatbázist? (MSSQL)
Konkrétabban az adatbázis nem bonyolult, 8-10 tábla lenne és az egyik táblába kerülne be sok adat (a többi tábla metaadatok... stb.). Ez milliós nagyságrendű rekordszám lenne (tehát akár 10-15 millió rekord).
Kb. az éves adatbázis mérete 20-30GB lenne. (Az 1évnél régebbi adatok archiválásra kerülnének.)
Ez a nagy tábla kb. három mezőből állna, pl.: id,timestamp,value(float)
A rögzített adatokat (WCF, web service-en keresztül kerülnének be az adatbázisba) webes (ASP .net) felületen lehetne elérni, de ez nem jelent nagy forgalmat (kb. heti 1-2 lekérdezés).

M$ Azure Cloud esetén a licenc díjakat a szolgáltatás tartalmazza - ez ok.
Pl. "A" sorozat 2mag, 3,5GB RAM, 50GB SQL tárhely.

Egy Azure-on levő SQL mekkora adatbázist bír el? Van valakinek tapasztalata ezzel? Vagy inkább érdemes VPS-ben gondolkodni?
Mennyire bővíthető később ez a "tárhely"? (pl. +RAM, v. +HDD)

Sziasztok,

Adott 2 oracle adatbázis, amelyek sémája kis mértékben különbözik. Olyan megoldást keresek, amelyik megmondja, hol vannak a különbségek és esetleg generál egy SQL scriptet, amellyel szinkronizálni tudom az egyiket a másikhoz.

Tudnátok opensource megoldást javasolni?

Köszi a segítséget!

Szoval van egy rengeteg rekordot tartalmazo innodb tablam, amiben egy boolean erteket is kene hatekonyan tarolnom, az esetek 80-90%-aban false (esetleg '0' vagy 0) az ertek. A kerdes az, hogy jobb-e az, ha megadom a default false (vagy 0, vagy '0') erteket az uj oszlop definiciojanal, vagy 1 byte-os oszlop eseten tok mindegy?

Azaz x tinyint default 0 vagy x char(1) default 'n' esetleg x tinyint vagy x char(1)