Ü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?