Nem, nem rázom kisujjból ezeket a dolgokat, nem vagyok rendszergazda. Bár csináltam már szerverállítgatós mókákat bőven melóhelyen is, de ez csak megerősítette bennem, hogy tuti soha nem akarnék rendszergazda lenni, ha nem muszáj. Annyira macerás és szerteágazó témakör, plusz rengeteg hibalehetőség van - ezért is javasoltam, hogy inkább bízz meg valakit a feladattal, nem azért, mert feltételezem, hogy bekapcsolni sem tudod a gépet. De azért vannak dolgok, amikbe az embernek nem ártana legalább minimális erőfeszítést belefektetnie, ha már ezzel akar foglalkozni komolyabban is (pl. egy szerver megfelelő beállítása már elég komoly dolog) - pl. azt kideríteni, hogy honnan tudod letölteni a PHP-t, és egyáltalán ingyenes-e, pont ilyen dolog...ezekkel a kérdésekkel csak azt bizonyítod be, hogy kicsit sem néztél utána a témának, de azért mástól várod a segítséget, hogy majd neki kerüljön energiájába, hogy szinte megfogja a kezedet, és idegenvezetés jelleggel elkalauzoljon téged az internetes nagyvilágban.

Sk8erPeter

Tényleg nem néztem utána hogy ingyenes-e, de itt miért ne lehetne megkérdezni? Egy csomó topikba ott vagyok pl "Milyen notebookot vegyek?" és oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudnák, de mégis mind a 20x meg is válaszoljuk ugyan azt. Ha ez téged idegesít hogy itt kérdeztem meg hogy ingyenes-e, akkor egyszerűen nem kell válaszolnod rá...Plusz igen mástól várom a segítséget, de nem azt hogy segítsen megcsinálni az egészet, hanem elindulni egy vonalon. Időm lesz rá megcsinálni, de ha látom teljesen reménytelen vagyok hozzá akkor átadom másnak ezt az egészet. Plusz szerintem direkt úgy kértem segítséget idézek magamtól: "ha valaki nagyon ráér" szóval isten ments hogy valaki velem foglalkozzon ha nincs rá ideje illetve nem is akar...

[ Szerkesztve ]

"oda is beírják minden nap 20x szinte ugyan azt a kérdést amire a választ a keresőből is megtudná, de mégis mind a 20x meg is válaszoljuk ugyan azt"
És úgy gondolod, ez követendő példa?
Sajnos ez a "divat" a Prohardver fórumain tényleg nagyon elharapózott manapság, pont ez a probléma. Ez nem csak az én szélsőséges véleményem, épp a napokban beszélgettem erről egy modival, sajnos ő is hasonlóan látja a helyzetet.

Félreértesz, nem az a baj, ha felteszel kérdéseket, amik másnak alapvetőek lehetnek (valakinek az is alapvető lehet, hogyan kell csatlakozni egy adatbázishoz PHP-kódból), hanem az a "baj", ha olyan kérdést teszel fel, ami tényleg kideríthető kevesebb, mint 1 percnyi utánanézéssel - kb. annyi idő alatt, amennyi idő alatt megírtad a kérdésedet. Igazából csak nem értem az okát, hogy miért jó ez. Ha megkérdezed, hogyan kell telepíteni a PHP-t, még az is jobb, mint azt megkérdezni, egyáltalán letölthető-e valahonnan legálisan. Az oka, hogy ez zavaró, az az, hogy ezekkel a hozzászólásokkal csak hígul a topic szakmaisága, ráadásul ennek már köze nincs az SQL-hez. Írod is, hogy "Tényleg nem néztem utána" - felmerül a kérdés, hogy vajon miért nem? Egy fórum nem arra való, hogy helyetted gondolkozzanak az emberek, hanem hogy segítsenek, ha valahol elakadtál, és nem sikerült megtalálnod a kellő információt.

Szerk.: most utálhatsz azért, hogy ezeket leírtam, de ha mindenki csendben marad, és soha senki nem szól semmiért annak érdekében, hogy a Prohardver szakmai színvonala azért ne süllyedjen a békának ama bizonyos testrésze alá, akkor csak egyre rosszabb irányba fogunk haladni.

[ Szerkesztve ]

Sk8erPeter

Lehet pontatlan voltam.

Szóval ami a lényeg van 12 db file-om (havi bontású adatok) De amikor megnyitom a 12 db file-t (vagy táblás), akkor logikailag mintha egy file-t (vagy táblát) kezelnék.
Ezt az Union-nal is meg lehet csinálni? Ő állítólag valami create table utasításra emlékszik.. de nem biztos benne....

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.

[ Szerkesztve ]

Sk8erPeter

Ez már jó lehet, csak a kérdés (amit elfelejtettem) hogy ez PHP-ban van....

Valakinek van ötlete erre?

Bocs, nem akartalak összezavarni..

Szóval van 12 db tábla, ami havi adatokat tartalmaz. Szükségünk van az adatokra úgy mintha a 12 db tábla egy nagyba lenne. De nem akarjuk a 12 db táblát egybe összefűzni fizikailag. Mert már túl nagy lenne így és méret korlátba ütközhetünk, illetve jobb kezelni külön. Amikor lekérdezéseket csinálunk, akkor az UNION-nal 12x kell leírni. Ezt szeretnénk egyszerűsíteni, ha lehet..

Így már tiszta?

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


select oszlop1, oszlop2, ... from osszes_tabla;

Phpmyadmin-ban létrehoztam egy felhasználót, de azt írja, az engedélyezve oszlopba, hogy nem. Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?
Vagy ez mire vonatkozik?

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Üdv.!

Van tippetek vagy linketek, hogyan lehetne a MySQl sebességét optimalizálni?

100.000 rekordos lekérdezésénél is perceket dolgozott....
Ütlet, link?

Előre is köszi

"Hogy lehetne engedélyezni ezt a felhasználót az adatbázisban?"
Screenshot
1.) "Jogok" fül
2.) itt hozzá tudod adni az új felhasználót; de nálad ez már megtörtént, úgyhogy "Jogok szerkesztése" az adott felhasználónál
3.) "Adatbázis-specifikus jogok" résznél "Jogok hozzáadása a következő adatbázison:", kiválasztod a megfelelő adatbázist,
4.) itt a "Jogok szerkesztése" ablakban kiválasztod, milyen jogokat akarsz adni az adott felhasználónak (kattints a "Mind kijelölése" linkre, ha minden jogot meg akarsz adni az adott felhasználónak ezen az adatbázison belül
5.) Indítás, és kész vagy.

Sk8erPeter

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...

[ Szerkesztve ]

Sk8erPeter

A 3-ason kívül minden megvolt. Ezek szerint anélkül nincs engedélyezve. Bár érdekes mód, így is tudok kapcsolódni custom felhasználóval.
Lehet sz*rul van az sql-em beállítva.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

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

Én kérek elnézést!

Kipróbáljuk...

Köszi!

Átolvassuk.

=======

Igen, mert még nem beszéltem azóta az illetővel. (Nem én programozom, csak segítek neki.. )

Ma elvileg tudunk foglalkozni a dologgal...

Hát akkor lehet, hogy az adott táblára globális jogok vonatkoznak, hogy minden felhasználó hozzáférhessen, szóval akkor az adott adatbázisnál a "Jogok ellenőrzése" résznél meg kellene kukkantani, milyen jogosultságok vannak beállítva; vagy az adott júzereknek túl sok a joga. Az tényleg nem jóféle, ha mindenki hozzáfér.

=====================
WolfLenny : nincs mit!

[ Szerkesztve ]

Sk8erPeter

Ja, nem a legjobb. De szerencsére csak localhost szóval, annyira nem nagy para.

Más: Adott egy admin panel php alatt, ahol ajax-al tudom módosítani egy mező értékét sql alatt. Érdekes mód, egy db ilyen sorban nem tudom módosítani. A yii nem dobott semmilyen hibát sem. Egyszerűen a mentésre azt írja, hogy nem sikerült neki.
De minden más adatnál sikerült. A fura, hogy phpmyadmin alatt viszont tudom ezt a sort szerkeszteni.
Se az sql, se a php, se az apache nem dob nekem erre hibát.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?

Sk8erPeter

Ha attributumon keresztul mentesz nezd meg a safe attributumokat

- http://pazsitz.hu -

Igen van. A többi sornál működik is a módosítás.

PazsitZ: Na, ezt megnézem majd.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Zsír király!

Müxik a cucc...

Újabb kérdések:

A dilemma a következő:
Mi a gyakorlati korlát egy táblában. Az adatok havi szinten jönnek és kb.1-1.3 millió rekord nagyságúak és kb. 50 mezőt tartalmaznak. Melyik megoldás lenne a gyorsabb. Ha külön file-ban tároljuk havi szinten, vagy ennyit még bepakolhatunk egy táblába.

Jogosultsággal kapcsolatos kérdések:
1. PHP+MySQL páros. Ha belép valaki a weboldalon keresztül, akkor a jelszót az MySQL-nek kódolva kell továbbítani? Vagy elfogadja TEXT-ként is az adatbázis szerver?
2. 3 szintű jogosultságot szeretnénk létrehozni.
a. Full jog.
b. Korlátozott jog. Bizonyos táblákat módosíthat csak. Viszont mikor új táblák készülnek,akkor azok a FULL joggal rendelkező user-rel készülnek. Tehát külön kellene az elkészülés után adni jogot minden egyes ilyen táblához?
c. Csak olvasás a fő adatbázisra és egy másik külön adatbázisba (pl output database) lenne írási joga.

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.

Én kérek elnézést!

Akkor simán mehet egy file-ba mondjuk egyévnyi adat...Így lesz a leggyorsabb a lehetőségekhez képest?

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

Én kérek elnézést!

A noSQL sem csodaszer. Select-ek futtatásában pláne nem.
Bonyolult adatstruktúrák írásakor sokszorosa, akár százszorosa a sebessége a hagyományos RDBMS-ekhez képest.
Bonyolult adatstruktúrák olvasásakor van olyan eset, amikor jóval gyorsabb (néhány szoros) a sebessége a hagyományos RDBMS-ekhez képest.
Full-text search-ben sokkal rugalmasabbak, gyorsabbak a noSQL-ek, különösen azok, amelyek magukba intergálják a Lucene-t is, ilyen pl. a ravenDB
Viszont ha van egy komolyabb adatstruktúrád, de annak csak bizonyos elemeit akarod lekérdezni (mintha több táblád lenne hagyományos sql-ben, de éppen csak egyet akarsz lekérdezni, vagy csak 1-2-t), nos egy ilyen triviális feladat noSQL-ben már korántsem triviális.

Ebben az esetben a webszerver, hogy Apache, vagy nginx, vagy IIS, vagy Tomcat vagy bármi totál lényegtelen. Nem az lesz a szük keresztmetszet.

Én kérek elnézést!

Na várjunk. Fogalom zavar van..

Szóval mint kezdőként álljatok hozzám...
File-ban úgy értettem, hogy táblában. Szóval melyik a gyorsabb, ha a 12 hónap 12 táblában van vagy ha 1 táblában van?

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.

[ Szerkesztve ]

Sk8erPeter

Látom te jobban otthon vagy azért ebben.
Nem próbáltam még egyik ilyen nosql-t sem, csak a mongoDB annyira dicsért lett már, hogy...egy ideje én is nagyon agyalgatok rajta, hogy nekiesek és megnézem mit tud.

Az nginx-et csak azért írtam, mert azzal is lehet nyerni valamennyi szerver időt. Még ha csak mp-enként +1 lekérdezést is.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Havi lekérdezés extrém ritka. Inkább teljes év vagy up2date lekérdezések vannak. Viszont az input adatok havi szinten jönnek. Ha view-sal nézzük, akkor könnyebb kezelni, mert nem kell havin szinten nyitogatni. Akkor lehet érdemes egy táblába tenni egy teljes évet, ha view-sal lassabb....

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.

Sk8erPeter

NoSQL DB-knél, mindegyiknek megvan a maga rendeltetése célja, amire jól hasznosítható.
Nincs és nem is lesz ultimate winner.
[link]

- http://pazsitz.hu -

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.

=Kilroy was here============================ooO=*(_)*=Ooo=======

tekintve hogy mysql-ben is lehet range partícionált táblát létrehozni, nem értem, hogy még miért mindig ezen megy a vita

view-t felejtsd el, átmeneti megoldásnak jó volt, de ide az túl buta

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.

Én kérek elnézést!

Egyelőre a vas még kérdéses. A szerver helyben lesz és kizárólag mi fogjuk használni.
Még nincs alatta konkrét vas, ehhez is szeretnék tőletek javaslatot.

Bővebben, hogy mi is lesz rajta. Kb. 9 ország adatai dolgozzuk fel. Az egyes országokat külön adatbázisba tervezem. Átlag 1 hónap kb. 100.000 rekord/ország. Azonban van 1-2 nagyobb ország, ahol akár 1-1.5 millió rekord/hó is lehet majd (egyelőre kb. 1 milla a legnagyobb). Az input adatok bekerülnek a táblába, majd utána lekérdezések, szegmentálások (bizonyos mezők kitöltése) fog történni. Amikor eltelik 1 év, akkor "lezárjuk" azaz, nem módosítunk rajta már semmit, azonban bizonyos kimutatásokhoz szükség lesz lekérdezésekre.
Szóval egyelőre kb. 9 adatbázis lenne azokban pedig 3 tábla egyenként max 12-15 millió rekorddal.

Ehhez milyen vas kellene? Mi az mi sokat dob a sebességen? HDD, CPU, RAM?

Köszi!

File méret korlát van? Mert pl. Foxproban sincs rekord korlát, de file méret ott max 2GB-t volt.

Itt mi a helyzet?

[ Szerkesztve ]

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.

Én kérek elnézést!

A feldolgozások egymás után történnének. Tehát lesz egy admin aki a bejövő adatokat kezeli és az adatbázisba dolgozza be. Nem egyszerre hanem egyik, majd másik. Lesz kb. 3-4 felhasználó akik ezekről leválogatásokat csinálnak, pl. egy hirdetőre. Nagyon ritka. Mondjuk naponta 1 és 95%-ban különböző időben. De ők pl. a "fő adatbázisban" írni nem fognak, csak onnan adatokat kinyerni ha kell...

Kb. ennyi. Szóval nem lenne erős felhasználás. A fő munka inkább az adatok bevitelénél és az azok után feldolgozásnál lenne sok írás pl. Utána már szinte semmi...

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.

Én kérek elnézést!