propel sharding
Hofferek Attila
propel mennyire boldogul az előre nem tudható táblanevekkel? Egy
primitív sharding szerűséget szeretnék megvalósítani, vannak GPS útvonal
adatok, és a vehicles tába ID alapján külön táblákba szeretném tenni a
külön kocsik adatait gps_vehicle_id formában pl gps_243. Erre a propel
mit tud nyújtani nekem szerintetek, mert az nyilvánvaló, hogy előre
generált modelt nem. Mégis szeretném az ORM kényelmét, lehet-e olyat,
hogy egy X táblára egy létező model (template) struktúrát kényszerítsek rá?
Szabolcs Heilig
Hofferek Attila
> Szevasz!
>
> Tekintve hogy konkrét megvalósítással jössz (külön tábla minden
> járműnek), nem az alap problémára keresel egy jó megoldást,
> felteszem erre jó okod van, így maradok az eredeti kérdésednél.
Jó ok az, hogy 3 hónapra visszamenőleg kell online megőrizni az
adatokat, és ez most érte el a 100.000.000 (szazmillio) rekordot? Elegge
idoigenyesek kezdenek lenni a lekerdezesek, es ez az autok szamaval csak
novekszik. Meg nincs gond, mukodik minden rendesen, de pl egy havi
menetlevel generalasa mar 25-30mp kocsinkent. Az elejen, amikor csak
partiz kocsink volt, ez masodperc alatti volt.
> A problémádra a megoldást a Propel önmagában nem ad, viszont
> lehetőséged van megírni erre magadnak egy Propel behavior-t. Kiindulásnak
> olvasd el ezt:
> http://www.symfony-project.org/cookbook/1_2/en/behaviors
Megolvasom, koszonom!
--
Hofferek Attila
Szabolcs Heilig
Jó ok az, hogy 3 hónapra visszamenőleg kell online megőrizni azadatokat, és ez most érte el a 100.000.000 (szazmillio) rekordot? Elegge
idoigenyesek kezdenek lenni a lekerdezesek, es ez az autok szamaval csak
novekszik. Meg nincs gond, mukodik minden rendesen, de pl egy havi
menetlevel generalasa mar 25-30mp kocsinkent. Az elejen, amikor csak
partiz kocsink volt, ez masodperc alatti volt.
János Krnák
Esetleg egy mysql explain a lassu querykre publikussa teheto?
Bar valszeg itt az optimalizacio mar nem sokat segit, mert iszonyat az adat mennyiseg.
Hofferek Attila
> Ezért is írtam, biztosan megvan a jó okod minderre. :) Szerintem addig
> biztosan nem lesz gondod, hogy a behaviort-ban megfogalmazd, más
> táblához kéne nyúlni a query-k esetében. Viszont az új jármű felvitelekor
> elő is kell állítani az ehhez szükséges táblákat. Doctrine-ben erre is
> látni példát (pl Versionable behavior hoz létre plusz táblákat), Propel
> esetében nem tudom, mi a megoldás.
Az már megvan, most a (perl nyelven íródott) szerver teszi a rekordokat
a nagyközös táblába, meg szét egyenként vehicle ID alapján. Az első
bejelentkezéskor hozza létre a táblát, ha még nem létezik.
--
Hofferek Attila
János Krnák
vagy megadsz neki egy masik ososztalyt a schema yml/xml-ben, es a Peer osztalyodban atirod, h ne az osztaly ::TABLE constansat hasznalja a querykhez, hanem amit te megadsz neki.
Hofferek Attila
> Az eletben nem lattam meg ennyi recordot egy helyen :)
> Esetleg egy mysql explain a lassu querykre publikussa teheto?
> Bar valszeg itt az optimalizacio mar nem sokat segit, mert iszonyat az
> adat mennyiseg.
explain SELECT date(g.dt) as date, time(g.dt) as time, g.geocode, g.lat,
g.lon, g.ign, g.speed, g.dist, g.dt from gpsgeo g where g.unit='1358'
and g.dt between '2009-11-04 23:00:00' and '2009-12-04 23:00:00' order
by g.dt;
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref
| rows | Extra |
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------------+
| 1 | SIMPLE | g | ref | unit,dt_ndx | unit | 5 |
const | 8200 | Using where; Using filesort |
+----+-------------+-------+------+---------------+------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)
Ez 8200 pont, egy auto egy honapja, de ez nem ment valami sokat,
atlagban 15ezer rekorddal szamolunk per honap per auto.
--
Hofferek Attila
János Krnák
Filesortot hasznal sorbarendezesre, ami lassu. (persze lehet nem lehet megoldani maskep)
Ha csinalsz egy kulcsot, ami a unit, dt mezokon van, lehet gyorsabb query-t kapsz.
Megprobalod? Akkor mit ad az explain?
Gyorsabb lesz a query? (ezt probald meg SQL_NO_CACHE -el, h midnen alkalommal tenyleg lefutassa a query-t)
SELECT SQL_NO_CACHE ...
udv
Hofferek Attila
> A unit kulcs csak a gpsgeo.unit -on van?
> Filesortot hasznal sorbarendezesre, ami lassu. (persze lehet nem lehet
> megoldani maskep)
> Ha csinalsz egy kulcsot, ami a unit, dt mezokon van, lehet gyorsabb
> query-t kapsz.
>
> Megprobalod? Akkor mit ad az explain?
> Gyorsabb lesz a query? (ezt probald meg SQL_NO_CACHE -el, h midnen
> alkalommal tenyleg lefutassa a query-t)
> SELECT SQL_NO_CACHE ...
Megprobalom, de nem most. Az ejjeli mentesbol majd csinalok egy
visszaallitast itt a sajat gepemen, nem akarnek szarakodni az indexekkel
az online rendszeren. Majd itt jatszom vele hetvegen, aztan referalok mi
a helyzet. Koszi meg egyszer!
János Krnák
Szabolcs Heilig
Megprobalom, de nem most. Az ejjeli mentesbol majd csinalok egyvisszaallitast itt a sajat gepemen, nem akarnek szarakodni az indexekkel
az online rendszeren. Majd itt jatszom vele hetvegen, aztan referalok mi
a helyzet. Koszi meg egyszer!
János Krnák
ennel a querynel unit van elol, aztan a dt, szal a unit, dt lesz a legjobb megoldas.
es utana dt alapjan rendez (na itt nem tudom, h tudja e hasznalni az indexet, v kiteszi e filesortba...)
Sulik Szabolcs
http://www.mysqlperformanceblog.com/2009/09/19/multi-column-indexes-vs-index-merge/
On dec. 4, 16:32, János Krnák <janos.kr...@gmail.com> wrote:
> MySQLnel szamit az, h a WHERE reszben hogy sorolod fel a mezoket
> ennel a querynel unit van elol, aztan a dt, szal a unit, dt lesz a legjobb
> megoldas.
> es utana dt alapjan rendez (na itt nem tudom, h tudja e hasznalni az
> indexet, v kiteszi e filesortba...)
>
>
>
> > Megprobalom, de nem most. Az ejjeli mentesbol majd csinalok egy
> >> visszaallitast itt a sajat gepemen, nem akarnek szarakodni az indexekkel
> >> az online rendszeren. Majd itt jatszom vele hetvegen, aztan referalok mi
> >> a helyzet. Koszi meg egyszer!
>
> > Érdemes lesz majd megpróbálnod a több mezőre készített indexet
> > úgy is, hogy a unit van elöl, meg úgy is, hogy a dt. Egyáltalán nem
> > mindegy,
> > másképp tudja a mysql is optimalizálni a végrehajtási tervet függően attól,
> > mennyire sokféle értéket vehet fel ez vagy az a mező.
>
> > --
> > Heilig Szabolcs