- Kábeleket és csövezést rejtő "kirakatház" a GameMax logójával
- Felvarrták az Arctic rackmount rendszerekhez szánt CPU-hűtőjének ráncait
- Háromféle kivitelben, és nem kis kapacitásokkal jönnek a Micron 6550 ION SSD-i
- Már a Samsung sem szolgálja ki modern AI lapkákkal Kínát
- Havazáshoz igazított kiadás kap a Steam Deck OLED
Új hozzászólás Aktív témák
-
#1101
Sk8erPeter
nagyúr
B-L-A-C-K
#1100
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1100
üzenetére
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
-
#1102
B-L-A-C-K
titán
Sk8erPeter
#1101
B-L-A-C-K
titán
válasz
Sk8erPeter
#1101
üzenetére
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 ]
-
#1103
Sk8erPeter
nagyúr
B-L-A-C-K
#1102
Sk8erPeter
nagyúr
válasz
B-L-A-C-K
#1102
üzenetére
"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
-
martonx
veterán
válasz
B-L-A-C-K
#1102
üzenetére
A baj csak az, hogy nem jó helyen kérdezted meg.
Ez itt egy SQL szakmai topic. Te pedig egy E-learning CMS-t akarsz beüzemelni, aminek nulla köze van az SQL szakmaisághoz. Na jó SQL-en fut a DB része, de ezzel az erővel mindennek köze van az SQL-hez![;]](//cdn.rios.hu/dl/s/v1.gif)
Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Privátban továbbra is segítek szívesen.Én kérek elnézést!
-
#1106
WolfLenny
aktív tag
Sk8erPeter
#1094
WolfLenny
aktív tag
válasz
Sk8erPeter
#1094
üzenetére
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.... -
#1107
Sk8erPeter
nagyúr
WolfLenny
#1106
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.[ Szerkesztve ]
Sk8erPeter
-
#1108
WolfLenny
aktív tag
Sk8erPeter
#1107
WolfLenny
aktív tag
válasz
Sk8erPeter
#1107
üzenetére
Ez már jó lehet, csak a kérdés (amit elfelejtettem) hogy ez PHP-ban van....
Valakinek van ötlete erre?
-
#1109
WolfLenny
aktív tag
Sk8erPeter
#1107
WolfLenny
aktív tag
válasz
Sk8erPeter
#1107
üzenetére
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?
-
#1111
Speeedfire
félisten
Speeedfire
félisten
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
-
#1113
Sk8erPeter
nagyúr
Speeedfire
#1111
Sk8erPeter
nagyúr
válasz
Speeedfire
#1111
üzenetére
"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
-
#1114
Sk8erPeter
nagyúr
WolfLenny
#1112
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...[ Szerkesztve ]
Sk8erPeter
-
#1115
Speeedfire
félisten
Sk8erPeter
#1113
Speeedfire
félisten
válasz
Sk8erPeter
#1113
üzenetére
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
-
#1118
WolfLenny
aktív tag
Sk8erPeter
#1114
WolfLenny
aktív tag
válasz
Sk8erPeter
#1114
üzenetére
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...
-
#1119
Sk8erPeter
nagyúr
Speeedfire
#1115
Sk8erPeter
nagyúr
válasz
Speeedfire
#1115
üzenetére
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
-
#1120
Speeedfire
félisten
Sk8erPeter
#1119
Speeedfire
félisten
válasz
Sk8erPeter
#1119
üzenetére
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
-
#1121
Sk8erPeter
nagyúr
Speeedfire
#1120
Sk8erPeter
nagyúr
válasz
Speeedfire
#1120
üzenetére
Az adott felhasználónak, akivel kapcsolódsz a Yii-n keresztül, van joga a feltöltéshez is?
Sk8erPeter
-
#1122
PazsitZ
addikt
Speeedfire
#1120
PazsitZ
addikt
válasz
Speeedfire
#1120
üzenetére
Ha attributumon keresztul mentesz nezd meg a safe attributumokat
- http://pazsitz.hu -
-
#1123
Speeedfire
félisten
Sk8erPeter
#1121
Speeedfire
félisten
válasz
Sk8erPeter
#1121
üzenetére
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
-
#1124
Speeedfire
félisten
PazsitZ
#1122
Speeedfire
félisten
válasz
PazsitZ
#1122
üzenetére
Uhh, balga hiba volt.
Ugye anno mikor elkezdtem csinálni az oldalt, csináltam pár teszt adatot.
De ennél az egynél nem töltöttem ki egy mezőt, pedig kötelező kitölteni és a validator miatt nem lett sohasem elmentve.
Kitöltöttem a mezőt, most már megy.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
WolfLenny
aktív tag
Ú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. -
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.
Én kérek elnézést!
-
#1129
martonx
veterán
Speeedfire
#1128
martonx
veterán
válasz
Speeedfire
#1128
üzenetére
Meg mondjuk ott egy DB szerver akkora, mint egy szoba.
Én kérek elnézést!
-
#1130
Speeedfire
félisten
martonx
#1129
Speeedfire
félisten
-
#1132
Speeedfire
félisten
WolfLenny
#1131
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.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
#1134
martonx
veterán
Speeedfire
#1132
martonx
veterán
válasz
Speeedfire
#1132
üzenetére
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!
-
#1136
Sk8erPeter
nagyúr
WolfLenny
#1135
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.[ Szerkesztve ]
Sk8erPeter
-
#1137
Speeedfire
félisten
martonx
#1134
Speeedfire
félisten
válasz
martonx
#1134
üzenetére
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
-
#1138
WolfLenny
aktív tag
Sk8erPeter
#1136
WolfLenny
aktív tag
válasz
Sk8erPeter
#1136
üzenetére
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....
-
#1139
Sk8erPeter
nagyúr
WolfLenny
#1138
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.
Sk8erPeter
-
#1140
PazsitZ
addikt
Speeedfire
#1137
PazsitZ
addikt
válasz
Speeedfire
#1137
üzenetére
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 -
-
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.
=Kilroy was here============================ooO=*(_)*=Ooo=======
-
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.Én kérek elnézést!
-
#1144
martonx
veterán
Speeedfire
#1137
martonx
veterán
válasz
Speeedfire
#1137
üzenetére
Pont a múltkor kezdtem el noSQL-ezni, pont a mongoDB-vel. Én is még csak kostólgatom. Viszont ahhoz, hogy dönteni tudjak közülük (mármint RDBMS - noSQL közül, és ha noSQL, akkor melyik), bele kellett mélyednem az előny-hátrányaikba.
Még annyit tennék hozzá a fentebbi irományomhoz, hogy amit írtam, az a dokumentum alapú NoSQL-ekre vonatkozik. A kulcs-érték, gráf stb... típusú NoSQL-eknek értelemszerűen teljesen más előnyei lehetnek. RDBMS kiváltásához nyilván a dokumentum alapú NoSQL-eket szokták használni.Én kérek elnézést!
-
WolfLenny
aktív tag
válasz
martonx
#1143
üzenetére
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?
-
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.Én kérek elnézést!
-
WolfLenny
aktív tag
válasz
martonx
#1147
üzenetére
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...
-
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.
Én kérek elnézést!
-
#1150
Speeedfire
félisten
martonx
#1144
Speeedfire
félisten
válasz
martonx
#1144
üzenetére
Köszi az infókat.
Ezek szerint egy projektben, olykor célszerű lehet inkább keverni ezeket? Vagy nem ajánlott? Vagy esetleg jóval nagyobb többletmunka lenne, hogy megérje azt?Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Pl. a facebook is SQL-en fut, mégsem itt kell megkérdezni, hogy hogyan kell ismerősnek jelölni rajta valakit.
Új hozzászólás Aktív témák
Hirdetés
- Call of Duty: Black Ops 6
- Milyen notebookot vegyek?
- Sorozatok
- Autós topik látogatók beszélgetős, offolós topikja
- Black Friday november 29. / Cyber Monday december 2.
- Filmvilág
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- HDD probléma (nem adatmentés)
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Építő/felújító topik
- További aktív témák...
- XFX Radeon Speedster SWFT 319 RX 6800 - BONTATLAN - ALZA GARANCIA
- Bomba ár! Lenovo X1 Yoga 3rd - i5-8GEN I 8GB I 256GB SSD I 14" 2K Touch I W11 I CAM I Garancia!
- Bomba ár! Lenovo X1 Carbon G3: i7-G5 I 8GB I 256GB SSD I 14" QHD I HDMI I Cam I W10 I Gari!
- Bomba ár! Lenovo ThinkPad T450s - i5-5GEN I 8GB I 128GB SSD I 14" HD+ I Cam I W10 I Garancia!
- Bomba ár! Lenovo ThinkPad T14s - i5-10G I 8GB I 256GB SSD I 14" FHD Touch I Cam I W11 I Garancia!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: HC Pointer Kft.
Város: Pécs