Új hozzászólás Aktív témák

• #1201 Jester01 veterán WolfLenny #1199

  Új Válasz 2012-06-14 14:31:59 #1201

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Jester01

  veterán

  válasz WolfLenny #1199 üzenetére

  Az se mindegy, hogy soronként PHP-ből vagy a mysql erre kitalált LOAD DATA INFILE parancsával csinálod.

• #1200 martonx veterán WolfLenny #1199

  Új Válasz 2012-06-14 11:54:38 #1200

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1199 üzenetére

  Egyrészt a PHP mint interpreter nyelv az ilyen műveletekre alapvetően kb. 100X lassabb (lehet, hogy cak 10-szer, erről ne nyissunk vitát), mint egy compiled (pl. java, .net) nyelv.
  Másrészt ha ezen a szerencsétlen P4-esen még emellett egy MySQL-t is futtatsz, és mindehhez egy ősrégi lassú vinyú kerreg alatta, akkor nem csoda ez a futásidő.

• #1198 rum-cajsz őstag WolfLenny #1195

  Új Válasz 2012-06-13 14:11:19 #1198

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  rum-cajsz

  őstag

  válasz WolfLenny #1195 üzenetére

  Ha ezt a "felszedést" excel csinálta egy p4-es gépen, akkor teljesen ok az egy óra.

  Egyéb esetekben jobban le kellene írnod, hogy mivel akartad betölteni hová, mert nagyon nem mindegy!

• #1197 lakisoft veterán WolfLenny #1195

  Új Válasz 2012-06-13 09:11:37 #1197

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lakisoft

  veterán

  válasz WolfLenny #1195 üzenetére

  Ez elsősorban a server I/O teljesítményétől függ. Milyen gépen és milyen adatbázissal próbáltad/dolgozol?

• #1196 martonx veterán WolfLenny #1195

  Új Válasz 2012-06-11 17:32:45 #1196

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1195 üzenetére

  Valahogy biztos. Ennek a méretnek nem órákig, hanem másodpercekig, na jó maximum 1-2 percig kellene futnia.
  Mivel semmi konkrétumot nem írtál, így nehéz konkrétan segíteni.

• #1149 martonx veterán WolfLenny #1148

  Új Válasz 2012-05-10 12:35:43 #1149

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1148 üzenetére

  ez esetben abszolút nem kell erős hardver a mysql alá. Egy mai bármilyen alap szerver megteszi (kettő mag, pár guriga memória, egy kis raid tömb mondjuk 3 vinyóból, ha fontos a redundancia). Azért ha nem egy 10 éves egy magos xeon-on futtatnátok, az nem lenne hátrány.

• #1147 martonx veterán WolfLenny #1146

  Új Válasz 2012-05-10 11:38:33 #1147

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1146 üzenetére

  MySQL 5.1-től fölfelé 64Tb-os 1-1 adatbázis méretkorlátja. Szerintem ennek a közelében sem lesztek.
  Vasat nehéz javasolni, pláne, hogy eddig csak a havi bejövő adatmennyiségről volt szó. Tudni kellene, hogy a bejövő adatok írása mennyire oszlik szét időben, a lekérdezések mennyire történnek időben szétszórtan, illetve hány konkurens felhasználóra számítotok.
  Általános tapasztalat, hogy legtöbbször a lemezműveletek viszik el a sok időt, még akkor is ha az adott DB szervernek sok memória áll a rendelkezésére. Manapság a sokmagos processzorok korában a processzor egyre kevésbé a szűk keresztmetszet.

• #1143 martonx veterán WolfLenny #1138

  Új Válasz 2012-05-10 08:47:25 #1143

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1138 üzenetére

  1 táblába raknám az adatokat. Aztán ha mégis lassú a dolog, akkor lehet indexekkel játszani, táblát particionálni stb...
  Illetve ha évenkénti lekérdezéseitek vannak, egy év múlva megnézve az SQL teljesítményt, elgondolkodnék azon, hogy érdemes-e az adatokat évenként archiválni.
  Nagyon fontos lenne mindehhez tudni, hogy milyen a vas a MySQL szerveretek alatt. Mivel totál kezdő vagy, erős a gyanúm, hogy ti egy szimpla hoszting cég amúgy is gyengécske MySQL szerverén fogtok osztozni sokadmagatokkal. Ebben az esetben, bármit is javasolnánk elégtelen lesz az SQL teljesítmény, sőt az első adatbetöltés után maga a hoszting cég fog nyakon vágni titeket, amiért fél órára legyilkoltátok a szerverüket.

• #1141 rum-cajsz őstag WolfLenny #1138

  Új Válasz 2012-05-09 23:46:52 #1141

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  rum-cajsz

  őstag

  válasz WolfLenny #1138 üzenetére

  Nekem foleg oracle-vel vannam tapasztalataim, de ugy sejtem a mysql sem lehet nagyon mas.
  El kell dontened, hogy mi a feladatok prioritasa es az alapjan kell dontened.
  Akkor eri meg a sok tabla, ha nagyom sok adat (tobb szaz millio) kerul bele adott idoitervallumon belul, es a regi adatokat folyamatosan ki akarod torolni.
  Szinte barmelyik SQL adatbazis elboldogul a 100-500 millio sorokkal, ha jol van idexelve, van eleg memoriad, es eleg gyors vinyok vannak alatta.
  A havi bontasokkal csak szivatod magad szerintem.
  Egyreszt gondoskodni kell arrol, hogy letrejojjon az uj tabla. masreszt folyamatosan karban kell tartanod a viewt, harmadreszt az union miatt sokkal lassab lesz a lekerdezesed, mintha egy tablaben lenne az adat.
  VISZONT.
  Ha egy tablaban van az adat, es torolni akarsz belole idonkent sok adatot (havonta partizmillio sort), akkor a torles elegge megfoghatja a tabla elereset, es ilyenkor celszeru a tabla bontasa.

  Remelem tudtam segiteni. kerdezz batran.

• #1139 Sk8erPeter nagyúr WolfLenny #1138

  Új Válasz 2012-05-09 23:22:22 #1139

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz WolfLenny #1138 üzenetére

  Nem azt mondom, hogy a view lassabb, hanem UNION-nal bohóckodni itt felesleges - ha a havi lekérdezés extrém ritka, akkor főleg biztos, hogy egy táblába tenném. Teljesen felesleges szétbontani. Szerintem jóval könnyebben optimalizálható a tábla, de majd remélem martonx megmondja a tutit, hogy mi a helyzet ezzel.

• #1136 Sk8erPeter nagyúr WolfLenny #1135

  Új Válasz 2012-05-09 22:55:21 #1136

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz WolfLenny #1135 üzenetére

  Olvasd el még egyszer, amiket írt neked martonx. Pl. ezt, elég érthetően írja le.

  Szerk.:
  azt írja, hogy "egy SQL tábla kb. bármennyi adatot elbír", ergo tárolhatsz bármennyi adatot így, de lehet, hogy hosszú lekérdezési időkkel kell számolnod.
  Gyorsaság szempontjából - ha azonos hónapon belül lekérendő adatokról beszélünk - lehet, hogy gyorsabb külön táblákban tárolni, de aztán kérdés, hogy milyen lekérések gyakoribbak, havi szintű vagy hosszabb időtartamú, aztán lehet, hogy a UNION-nal való lekérdezések, VIEWS-ba rakás ront a teljesítményen, meg "logikailag" nem biztos, hogy szerencsés a különbontás.
  Na jó, a hsz. végére már magamat is belekavartam, szóval nem tudom, mi lenne az optimális megoldás.

• #1133 martonx veterán WolfLenny #1131

  Új Válasz 2012-05-09 22:32:19 #1133

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1131 üzenetére

  és hogy fogsz a file-odban keresni? Mit értesz leggyorsabb alatt?

• #1132 Speeedfire félisten WolfLenny #1131

  Új Válasz 2012-05-09 22:02:14 #1132

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Speeedfire

  félisten

  válasz WolfLenny #1131 üzenetére

  "De file-ában letárolni az adatokat, és abban keresni, az még rosszabb."
  Pont azt írja, hogy nem.
  Esetleg egy mongodb és nginx sokat dobhat a sebességen.

• #1127 martonx veterán WolfLenny #1126

  Új Válasz 2012-05-09 18:45:31 #1127

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1126 üzenetére

  Egy SQL tábla kb. bármennyi adatot elbír. Távközlésben DB admin ismerős mesélte, hogy van olyan táblájuk, amibe napi 130 millió sor kerül bele.
  Nálunk is vannak szép nagy táblák.
  Másrészt úgy látom, hogy ti PHP + MySQL-t akartok használni, ahol gondolom a MySQL ingyenes, nem Enterprise verzió, és nincsenek fürtözött SQL szervereitek a MySQL mögött. Ilyenkor szép hosszú keresési időkkel számolhattok, egy - egy lekérdezésnél. De file-ában letárolni az adatokat, és abban keresni, az még rosszabb.

  A jogosultságos kérdésben kevered a szezont a fazonnal. Az SQL szintű user jogosultságok általában köszönő viszonyban sincsenek az alkalmazás szintű user jogosultságokkal. Általában 1-2 SQL usert szoktak létrehozni, 1-et a DB adminnak full jogkörrel, és 1-et az alkalmazásnak csak a szükséges jogkörrel. Utána minden más jogisultságot az alkalmazáson belül szoktak intézni.

• #1116 martonx veterán WolfLenny #1112

  Új Válasz 2012-05-07 19:39:30 #1116

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  martonx

  veterán

  válasz WolfLenny #1112 üzenetére

  ha elküldenéd a lekérdezést, akkor tudnánk segíteni

• #1114 Sk8erPeter nagyúr WolfLenny #1112

  Új Válasz 2012-05-07 17:28:08 #1114

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz WolfLenny #1112 üzenetére

  Többek közt a táblák megfelelő indexelésével... Query cache használatával...
  EXPLAIN segít, hogy hol kellene többek közt az indexelésen javítani...
  Itt van pár tipp.
  Aztán még számtalan más oka lehet.

  Túl általánosan írtad le a problémádat ahhoz, hogy konkrétan tudjunk segíteni. De a fentiek közül valamelyik segíthet.

  ===
  Szerk.: egyébként -Zeratul- írt neked egy elég jó választ itt korábban, de arra nem reagáltál... ez végül is megoldotta az előző problémádat? Nem árt - illik - válaszolni az illetőnek, ha segítséget kaptál...

• #1110 bpx őstag WolfLenny #1109

  Új Válasz 2012-05-04 19:24:47 #1110

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  bpx

  őstag

  válasz WolfLenny #1109 üzenetére

  create view osszes_tabla as
  select * from tabla1
  union select * from tabla2
  ...
  union select *from tabla12;
  
  
  select oszlop1, oszlop2, ... from osszes_tabla;

• #1107 Sk8erPeter nagyúr WolfLenny #1106

  Új Válasz 2012-05-04 13:50:39 #1107

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz WolfLenny #1106 üzenetére

  Lehet, hogy ilyenre gondolsz: [link]. Nem?
  Szerk.: bár most már akkor kevésbé értem a feladatot. Először azt írtad: "Van két (vagy több) tábla ami azonos struktúrával rendelkezik." - és ezekből "egyesítve" (union) kellene lekérni adatot.
  Akkor lehet, hogy a kettő kombinációja kellene. Összefűzni a fájlokat, majd union, de már kicsit összezavartál.
  Igazából most nem vágom, az a sok különálló file egy-egy adatbázis dump file? Tehát nincsenek eleve felküldve az adatbázisba? Pontosíts plíz.

• #1095 rum-cajsz őstag WolfLenny #1093

  Új Válasz 2012-05-03 21:42:03 #1095

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  rum-cajsz

  őstag

  válasz WolfLenny #1093 üzenetére

  igen, az union lesz a barátod:

  select idopont,valami from valahonnan1
  union
  select idopont,valami from valahonnan2
  order by 1,2;

• #1094 Sk8erPeter nagyúr WolfLenny #1093

  Új Válasz 2012-05-03 21:40:48 #1094

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Sk8erPeter

  nagyúr

  válasz WolfLenny #1093 üzenetére

  UNION?

  Pont ilyen kérdést tettek fel Stack Overflow-n: [MySQL - Selecting data from multiple tables all with same structure but different data]

  Ott javasolt megoldás:
  (SELECT * from us_music where `genre` = 'punk')
  UNION
  (SELECT * from de_music where `genre` = 'punk')

Új hozzászólás Aktív témák