JSP vs ASP.net konkrétumokkal

Internet: PHP, CGI, stb.

Kiedves HUP tagok!

Valószínűleg sok téma nyílt már hasonló kérdésekkel, ha úgy érzitek máshol is választ kapok a kérdésemre jelezzétek.

Csinálni fogok egy weboldalt aminek (tegyük fel) 100.000 tagja van, ebből 1000 lesz aktív állandóan, ő percenként 20-30 leplekérést is indítanak. Lesz még a servernek egy "trackere" ami kéréseket fog kezelni, folyton fut.

A kérdés pedig hogy szerintetek melyik jönne ki jobban árban, egy ezt stabilan kiszolgáló Dell server Win Srv2K8-al IIs7 -net 3.5, vagy egy SUN server a hozzá tartozó jsp serverével. ASP meleltt szól az output caching ami ezen az oldalon sűrűn használva lenne. Viszont egy Javas server talán kevésbé terheli a servert.

Win-re MSSql 2K8 lenne, a java alá pedig mit ajánlotok?

? Server komplett ára
? Előnyök hátrányok

A válaszokat előre is nagyon köszönöm!

  • 2922 megtekintés

( Mico v | 2009. 01. 31., szo – 15:07 )

A Java szerver oldali technológiák kicsit szerteágazóbbak, mint pusztán "JSP". Addig ne is gondolkozz szerverben, amíg ezt ki nem találtad. (Ha viszont ki van találva, onnantól kezdve viszont azt is tudod, mi kell hozzá.)

( Mico v | 2009. 01. 31., szo – 15:15 )

Egyébként 500 req/sec a program minőségétől függően lehet sok és kevés is. Jobban megcsinált webappoknál 1000-2000 req/sec -et számolunk egy rendes velocity, freemarker vagy akármilyen view rétegre (figyelem! csak a view rétegre) _cpu magonként_. Ilyen házi használású Grails alkalmazásnál a GSP-re (ami tkp JSP) mondjuk 500-at. De én nem tudom, én a szerveres ember vagyok, majd valami web kóder megmondja. Csak annyit tudok, hogy rohadt könnyű eltérni negatív irányba.

ASP mellett meg ne szóljon semmilyen output caching, ilyet ugyanis mindenhol lehet csinálni.

( golgota | 2009. 01. 31., szo – 15:15 )

Ha egyszer kipóbáltad a java-t (jsp, javabeans, JMS, JNDI), akkor utána már nem nagyon fogsz semmi másban gondolkodni. Iszonyat mit meg nem lehet csinálni a JavaBean-ekkel. És a java technológiával.
Nem hiába használnak enterprise környezetben Java alapú alkalmazásszervereket.
Ajánlom olvasgatásra a Geronimo-t, ami ugyen még nem egy JBoss, de már sokkal több, mint egy Tomcat.
D azt javasom, hogy vagy kötelezd el magad az MS mellett (akkor MSSql, ASP), vagy a Java mellett és akkor viszont megnyílik a világ és azt csinálsz amit akarsz. Az MS jó abban, hogy szépen minden össze van reszelve, de technológiailag (szerintem) messze elmarad a Java-tól és annak lehetőségeitől. Ugyanakkor a Java esetében több reszelésre számíthatsz.

( Lovi | 2009. 01. 31., szo – 15:44 )

A kódot nem én fogom írni, arra keresek egy profit, de amíg nem döntöttem el miben legyen írva addig nem haladok. Cachelés valóban sok mindennel meg lehet oldani ez igaz. Viszont ha jól láttam egy Sun server jóval drágább egy azonos tudású Dell vagy Hp egyéb társakkal szembe. Ez is fontos tényező. Nehéz eldönteni a kettőt egyszerre nézve. Az meg hogy mi minden oldható meg javaban nem lényeg mert maga az oldal csak SQL kéréseket fog végezni, minden mást a "tracker" végez majd.

Nem értem a problémádat... :)

Miért gondolod, hogy a JSP csak Sun szerveren megy? Ugyanúgy fel tudod tenni Dell vagy HP szerverre is a kiválasztott alkalmazás szervert (Glassfish, JBoss, stb).

A JSP és az ASP között kb. annyi a különbség, mint a diktatúra és a demokrácia között. ASP esetén a hardvert leszámítva adott, hogy mit használhatsz és azért elég rendes licencdíjat kell fizetni. A JSP esetén van féltucat kiváló alternatíva, amin futtatni tudod, és egy csomó cache között is tudsz válogatni, nem az az opció, hogy igen, vagy nem.

A tracker milyen nyelven lesz implementálva?
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

No offence de ha nem te tervezed a programot, akkor miért döntesz el egy olyan - relatíve lényegtelen - dolgot, hogy miben legyen írva? Meg mi köze a szerver típusához.

130 lóerős BMW full supporttal jóval drágább egy 130 lóerős Octaviánál Érdről. (A két autó mindenben ugyanazt nyújtja, de legalábbis a lóerőben biztosan. Érted?) Amúgy nem túl jó dolog, ha egy elmondásod szerint 100000 useres szolgáltatás tervezésénél a fejlesztési és egyéb költségek között egyáltalán számít bármit is az 1 db ilyen vagy 1 db olyan szerver közötti árkülönbség..

Nyilván később nem fog számítani, de amíg nincs bevétel belőle addig nagyonis számít hogy mennyi pénzből kell ezt összehozni. Azért akarom eldönteni hogy milyen nyelven íródjon mert aszerint veszem fel a programozót. Ami gondot okoz hogy a sun nagy mysql támogató, viszont mysqlt nem szívesen tennék a szerverre (amiben rendes boolean sincs). Eddig a java meleltt szól pár érv ami meggyőző is, érdekelne viszont a véleményetek az ASP-ről is. Mint már ítam az ASP által támogatott funkciók bőven elegek a feladatra, ezért főleg a teljesítmény számít. a tracker pedig win alatt C#ban lesz írva, egyéb Os alatt pedig rábízom ezt a programozóra. Trackernek is alkalmas lenne egy Java alkalmazás? itt már maximálisan a sebesség számít, csak matematikai műveleteket végez, és SQL kérés.

Nyilván később nem fog számítani, de amíg nincs bevétel belőle addig nagyonis számít hogy mennyi pénzből kell ezt összehozni.

Akkor addig akárhol elvan az alkalmazás szerver, nem kell rögtön alátolni egy brutál vasat. Pláne, hogy később bele lehet tenni clusterbe, és akkor főleg nincs gond.

a tracker pedig win alatt C#ban lesz írva, egyéb Os alatt pedig rábízom ezt a programozóra. Trackernek is alkalmas lenne egy Java alkalmazás? itt már maximálisan a sebesség számít, csak matematikai műveleteket végez, és SQL kérés.

A C# azonos szinten van a Java-val (mindkettő virtuális gépben fut), semmivel se lesz gyorsabb, se lassabb... :)
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

Clustert nem akartam mert szerintem 2 gyengébb gép még mindíg drágább mint egy erősebb, de szóljatok ha tévedek. Az emg igaz hogy managed kódban nincs nagy eltérés. Árban mennyit saccoltok a servernek, vagy servereknek (cluster).

Nem feltétlen drágább két kisebb gép clusterben, mint egy nagyobb, amely azonos megbízhatóságot ad... hogy garantálod egy géppel a rendelkezésreállást? :)

Árban attól függ, hogy az első időszakban mekkora terhelést vársz. Mert ha lesz 100.000 felhasználód, akkor lesz annyi bevétel is, hogy megfelelő gépparkot tegyél alájuk. Ha meg nem jön be és 10.000 felhasználód lesz csak, akkor ott fogsz ülni egy tízszeresen túlméretezett gépparkon...
--
http://wiki.javaforum.hu/confluence-2.10/display/FREEBSD

A Googlenel a sok kicsi tobbet er alapon gondlkodnak, es bejott nekik.
"Estimated 450,000 low-cost commodity servers in 2006". Inkabb vettek tobbszazezer sima gepet, mint keves, de high-end cuccot, igy jobban megeri. Hiszen sokkal olcsobb cserelni, ha naponta tonkre is megy parszaz gep.
"A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work."

Forras: http://highscalability.com/google-architecture

Ezt sokan így gondolják és ezért akar mindenki manapság "clustert" üzemeltetni. A probléma a "reliability on top of unreliability" megvalósításában van. Nap mint nap látom, hogy pont a szoftveres implementáció, vagy épp a "reszelés" miatt áll az a "cluster", aminek épp az lenne a lényege, hogy menjen. Szóval kis méretben nem csak hogy ésszerűbb, de olcsóbb is egy rendes vas + support + átgondolt stratégia + nem ész nélküli üzemeltetés. Google méretű dolgokkal jönni egy ilyen problémára nem teljesen reális.

Szerintem először alkalmazz egy system architectet, aki megtervezi neked, hogy pontosan hogyan is álljon össze a rendszer, a komponensei milyen protokollon át kommunikáljanak. Aztán ezután szinte mindegy, milyen programnyelven valósítod meg a rendszertervet, azaz mindegy, milyen programozót alkalmazol. Az architect munkája sokkal fontosabb, mint a programozóé. Az, hogy a SUN nagy MySQL támogató, nem meglepő, övék. Ilyen erővel mondható, hogy a Microsoft nagy MSSQL támogató.

"Trackernek is alkalmas lenne egy Java alkalmazás? itt már maximálisan a sebesség számít, csak matematikai műveleteket végez, és SQL kérés."
Sok esetben a Java gyorsabb, mint egy ekvivalens C++ megvalósítás.

Amúgy szinte mindegy, hogy a .NET és a Java platformok közül melyikben valósítod meg a dolgodat, mindkettőben lehet szar és jó szoftvert is fejleszteni. Viszont nem mindegy, hogy mennyit akarsz erre költeni. A .NEThez, annak érdekében, hogy minden szolgáltatását kihasználd, szükséges szoftverlicenceket fizetned, míg a Java platform alatt sok ingyenes, nyílt forráskódú, szabad szoftver áll rendelkezésedre.

Amúgy az, hogy van caching vagy nincs, az alkalmazandó platformot ne befolyásolja. A weboldatl előállító kódnak nem kell tudnia arról, hogy kimenete cachelődik-e, vagy nem. Így eleinte ne vedd figyeleme a cache létét, és később beépítheted a szofverrendszeredbe a cache kezelést. Java platform alatt is sok alkalmazásszerver tudja ezt beépítve, a progamok számára átlátszatlan módon.

( Lovi | 2009. 01. 31., szo – 17:47 )

_Franko_ és Persicsb meggyőzött cluster terén. köszönöm a segítséget.
Jason a MySqlben a booleant nem lehet Variable = !Variable módon váltani. Mellesleg amikor feltöltöttem egy boolt azt smallintkéne kezelte(ha jól emlékszem, de semmiképp se boolként). system architect emberkéket hol találok? itt nézelődjek?
Köszönöm az eddigi válaszokat, hasznosak voltak.

Tinyint-kent kezeli, es de, lehet. 


mysql> SELECT 'a' != 'b';
+------------+
| 'a' != 'b' |
+------------+
|          1 |
+------------+

Altalaban amugy a adatbaziskezelo retegek ezt el szokjak rejteni. Amugy meg, altalaban a programozok meg szoktak ezt a problemat oldani. Mivel ugyse te leszel a programozo, nem feltelten neked kell aggodni emiatt - foleg, hogy nem is ismered a cuccot.

A masik: eloszor is, legyenek meg neked a terveid: pontosan miket szeretnel, miben gondolkodsz. Addig ne keress architekt-et, mert ezt o sem fogja kitalalni helyetted, o neki kell egy hatarozott cel.

Talalni embereket itt az Allast kinal forumban, vagy valamely allaskereso portalon talalhatsz.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azért nem tetszik a my mert ezt szerintem egy valamirevaló sql 1 bitnyi helyen is el tudná tárolni. Amúgy php programozó vagyok ismerem a mysql-t sokat használom. A terveim megvannak, összeírtam mi kell hozzá, de a pénz még csak részében, így van kis idő kezdésig. Nagyon köszönöm a válaszokat, hasznosak voltak, valószínűleg java alapú lesz, és eszerint keresek embereket. mégegyszer köszönet mindenért.

( uid_16401 | 2009. 02. 01., v – 02:50 )

Huuh, ez a topic már a születésénél off volt.

( Imo | 2009. 02. 01., v – 08:19 )

Azért nem árt megjegyezni, hogy a normális (bocs, nálam a mysql a játékszer kategória) adatbáziskezelők (pl mssql) is csak akkor tudják optimalizálni a boolean adattipust, ha rekordszinten több van benne. Ha egy rekordban 1 boolean mező van, az pont ugyanúgy 1 byte-ot foglal mint mysql-ben, viszont ha 2,3,4...8 db van, akkor az még mind elfér ugyanabban a byte-ban. 9-16 db között 2 byte-ot foglal stb. Az esetek 99%-ban nem is a helymegtakaritás a lényeg, hanem, ha egy lekérdezésben az összes boolean mező feltételként benne van, akkor brutális a sebességnövekedés, mert egyetlen integer egyenlősséggel ellenőrizhető az összes feltétel. És persze az IO megtakaritás sem lényegtelen nagy adatbázisoknál.

(nem tudom mysql konkrétan hogyan működik ezügyben, lehet, hogy ugyanigy, nem emiatt komolytalan)

én legalább leirtam pontosan, szakmai érvekkel hogyan működik normális rendszereken a boolean optimalizálás és nem hülyeséggekkel tereltem, hogy milyen ügyes a mysql, hogy tinyintként is tudja kezelni...

Ha mssql gondod van, javaslom nyissál neki topicot, ez nem az, talán majd ott elmagyarázzák neked mik azok a dirty adatok egy transaction rollback esetén.

Hát persze hogy nem érted, ha még csak alapfokú db könyveket láttál :)

Teljesen természetes a rollback egy node halál esetén, mivel sosem tudhatod, hogy a többi node-hoz eljutott-e az utolsó kliens által kiadott művelet mielőtt kihúzták a tápkábelt a node-ból, igy nem garantálható a konzisztencia, csak rollback-kel.

De nyugodtan dobd be ezt hogyan oldja meg a mysql high availability solution-je, mert a mssql az szar :)))

Ez komolyan érdekel. Végigfutottam oracle HA solution leirásokat és egyetlen szó se volt ilyenről. Csakis transactionally consistent átállásokról a node-ok között, ami rollback.

mssql vs oracle-höz nincs sok hozzáfűznivalóm, ezek teljesen egy súlycsoportban játszanak, én mssql-t preferálom általában a projekteknél, de az oracle is korrekt. Mysql viszont szóba sem jöhet komoly projektnél.

honnan fogja tudni a szerver a folytataskor hogy melyik klienshez tartozik a felbehagyott tranzakcio?
vagy hiba eseten a failoverbol belepo vason akarod ujrakezdes nelkul folytatni a tranzakciot?
szerintem annyira ritka az ilyen, hogy abban a keves esetben inkabb veszits egy kis futasi idot, mint a ki tudja hol hogyan felbehagyott tranzakcio folytatasabol eredoen esetleg adatvesztes lepjen fel...

Tyrael

amugy mivel a tranzakcio imho mindenhol sessionhoz kotott es ha lehal a vas, akkor bomlik a session, ezert szerintem ilyet nem nagyon fogsz tudni csinalni.
de az ilyen feature requesteknel, idezd magadat:
http://hup.hu/node/66584#comment-711008
:)
anno egyik munkahelyemen lebaszott a fonok, hogyha 2 ablakbol (de 1 bongeszobol) nezi az oldalt, akkor nem tud 2 kulonbozo felhasznaloval belepve lenni egyszerre az oldalon.

Tyrael

oke, de aki ezt kerdezte, nem tudatlan ugyfel volt, hanem egy senior developer mashol. le akartak vinni a tranzakciokezelest a middle-tierbol a dbhez, igy megusztak volna a jdbc driver hianyossagait XA teren. mert persze a gfben van distributed transaction support, csak ha a jdbc drivered nem tamogatja...

probakepp most takolunk ossze egy olyan archot, ahol minden sajat (ertsd: sajat db szoftver, sajat alkalmazasszerver szoftver, etc), bar csak demo celokat fog szolgalni :)

mssql fanboyunkat kerdeznem: oracle vs mssql temahoz tud vmit mondani? akarkit kerdeztem, az aron kivul sok okosat nem tudott mondani. mi az, amit tud az egyik, mi az, amit a masik? nem sok kozom volt mssqlhez, csak amennyit adott kerdesek doksival valo megvalaszolasara forditottam, es nem lattam semmit, amit mssql ne tudna (vagy forditva).

szoval? :)

miert nem latom a boolean-t az msdn-en?
talan a bit-re gondolhattal.
http://msdn.microsoft.com/en-us/library/ms187752.aspx

viszont a bit-et a mysql is supportalja mar egy ideje:
"As of MySQL 5.0.3, a BIT data type is available for storing bit-field values. (Before 5.0.3, MySQL interprets BIT as TINYINT(1).) In MySQL 5.0.3, BIT is supported only for MyISAM. MySQL 5.0.5 extends BIT support to MEMORY, InnoDB, BDB, and NDBCLUSTER. "
szoval nem ertem mi ez a nagy siras...

ja, es hogy miert maradt ki mindket adatbaziskezelobol a boolean tipus?
"The BOOLEAN type is optional (has feature ID T031), which is a bit surprising for such a basic type. However, it seems that endless discussions of how NULL is to be interpreted for a boolean value is holding BOOLEAN from becoming a core type. "

Tyrael

Jézusom b***meg, vitatkoztok itt egy boolean 1byte-ján, mikor a legtöbb komoly adatbázis terrabyte-okra rúg! Ti nem vagytok normálisak!
Osztán meg egyiknél se jöjjön nekem senki az optimalizációval, mert az mssql-nek egy teljes irodaháznyi szerver kell egy kibeba$$ott lekérdezés elvégzéséhez, a mysql meg nem is lenne képes lekérdezni azt az adatot. Röhej!

próbáld ki amikor azt a terabyte-os adatbázist lekérdezed mondjuk 6 féle boolean mezőre szűrve, akkor mekkora különbség lesz a sebességben, ha rekordonként egyetlen byte-ot kell egyetlen iffel megvizsgálni vagy 6 byte-ot 6 iffel. Aztán nézd meg a kettőnek az IO költségét, ha van egy százmillió rekordos táblád, mindjárt nem biteken való szarakodásnak fog tűnni. Mondjuk aki mysql-ben akar ekkora adatbázist használni, az úgyis hülye...

"talan a bit-re gondolhattal."

Teljesen mindegy, hogy hivják, a lényeg, hogy igaz/hamis/ismeretlen háromállapotú mező. A mssql ezt valóban bit szinten végzi, mig a mysql tinyint-ként tárolja, nagyon nem mindegy, a fent már kifejtett okokból.

A mysql bit-je ugyanúgy tinyint-ként viselkedik, ha felveszel 8-at belőle egy táblába az 8 byte-ot fog foglalni és nem tudod őket egyszerre vizsgálni (1 integer feltétellel) mig mssql-en egyetlen byte-ot foglal és 8x gyorsabb a lekérdezése/szűrése.

mint ahogy feljebb irtam mysql is tudja a bit-et.
mint ahogy feljebb is irtam, mar joideje bit a bit, nem pedig tinyint(1).
hogy osszefogja-e a szomszedos biteket byte-ta, es ugy vizsgalja-e mint az mssql, azt nem tudom.
de a 8szoros gyorsulas szerintem csak papiron letezik, fugghet a query-tol, az indexektol, magatol a query plannertol, de valoban nem tunik hulyesegnek. de azert ha mar csak ennyi a kulonbseg akkor visszaszivhatnad a korabbi allitasaidat a mysql nevetseges boolean kezeleserol.

Tyrael

"mint ahogy feljebb is irtam, mar joideje bit a bit, nem pedig tinyint(1)."

A mysql dokumentáció szerint a bit egy alias a tinyint-re.

"hogy osszefogja-e a szomszedos biteket byte-ta, es ugy vizsgalja-e mint az mssql, azt nem tudom."

Próbáld ki, nem fogja össze.

"de azert ha mar csak ennyi a kulonbseg akkor visszaszivhatnad a korabbi allitasaidat a mysql nevetseges boolean kezeleserol."

miért, mi változott? A mysql egy byte-ot pazarol minden bitre (és boolean-re) az mssql meg nem, ennek pedig a már 10x leirt következményei vannak. Pont, nincs mit ezen szépiteni, van akit nem érdekel, van aki nem érti miről van szó, mert csak 1 megás adatbázisokat látott, de a tényeken ez nem változtat. (és mint mondtam, nem emiatt nem jó választás komolyabb projektekhez a mysql, ez csak apróság, felesleges ezen rugózni)

ja, ha nem tudsz olvasni, azzal nem tudok mit kezdeni.
na, de azert meg1szer utoljara, hatha: 

BIT[(M)]

A bit-field type. M indicates the number of bits per value, from 1 to 64. The default is 1 if M is omitted.

"As of MySQL 5.0.3, a BIT data type is available for storing bit-field values. (Before 5.0.3, MySQL interprets BIT as TINYINT(1).) In MySQL 5.0.3, BIT is supported only for MyISAM. MySQL 5.0.5 extends BIT support to MEMORY, InnoDB, BDB, and NDBCLUSTER. "

ez mind szép és jó, csak mi köze van a KÜLÖNÁLLÓ boolean tipusú mezők össze(nem)fogásához? Semmi. Remélem nem azt akarod mondani, hogy te majd a hivó kódból fogsz bitmaszkokkal bohóckodni, hogy elérj valami megközelitőleg hasonló funkcionalitást amit a normális adatbáziskezelők out-of-the-box adnak?

milyen boolean? bit tipusrol beszelgetunk
miutan harmadszor is hulyeseget irtal, gondoltam harmadszor is odairom, hogy hulyeseg.
egyik elozo munkahelyemnel volt bitmask-os bohockodas, nem szerettem, kenyelmetlen.
De hogy osszefoglaljuk, hogy szerinted miert jatekszer a mysql, es nem komoly adatbazisszerver:
Ha van egy olyan tablad, amiben van 1-nel tobb bit(1) tipusu mezo, ami alapjan gyakran futtatsz olyan query-t, amiben 1-nel tobb ilyen mezore hivatkozol, akkor az gyorsabb, es kevesebb helyet foglal mssql-en mint mysql-en.
ha csak 1 ilyen oszlopod van, akkor mssql alatt is 1 byteot foglal.
ha meg nem hivatkozol 1-nel tobb oszlopra a keresesben, akkor meg nincs sebessegnovekedes.
en nem erzem ugy, hogy a valo vilagban, egy eles alkalmazas eszlelheto merteku gyorsulast erne el emiatt.
persze ez lehet hogy csak nekem tunik igy.

Tyrael

én meg negyedszer is leirom, hogy még mindig összekevered a dolgokat. A bit=boolean-nel, ha mssql-ről beszélünk és egészen mást jelent mysql alatt. (de ott sem oldja meg a boolean-eknél felvetett problémákat)

"en nem erzem ugy, hogy a valo vilagban, egy eles alkalmazas eszlelheto merteku gyorsulast erne el emiatt."

azon nem tudok segiteni sajnos. Nem véletlen működik igy a komolyabb adatbáziskezelőkben.

( kl3on v | 2009. 02. 01., v – 19:58 )

Inkább egyik szálat sem folytatom a hozzászólásommal, még a végén megkövez engem is akire épp válaszolnék :)

Szóval, homályos ismereteim alapján, nem elég az adatot eltárolni, azt is el kell tárolni, hogy hol tároltuk el az adatot. Ha egy byte-ot feloszt az adatbázis-kezelő, boolean értékek számára, azt is tudnia kell, hogy melyik bit melyik érték. Tehát amikor valami hivatkozik az egyik booleanra, nem elég az, hogy melyik byte tartalmazza ezt, hanem az is kell, melyik bit ezen a byte-on belül. Többe kerül a lé mint a hús.

--
Keep it simple, stupid.

Rosszul gondolod. Ezt pl az mssql olyan "elképesztő" módon oldotta meg, hogy a mezők sorrendjében tárolja a biteket egymás után a byte-ban, igy pontosan tudja, hogy ha az 5. mezőt keresi ami boolean, akkor az az egyetlen letárolt byte 5. bitje lesz és nincs szükség arra, hogy leirja mégegyszer, hogy melyik bit melyik mezőt tárolja.

Jogos. Változásnál meg gondolom csúsztatja őket, vagy megjegyzi és kevésbé terhelt időszakban elvégzi.

Egymillió rekordnál a különbség nincs 1 megabyte. És 1 bitnek kell félremennie ahhoz, hogy az egész káoszba dőljön. Nyilván kicsi rá az esély, de címzés nélkül, ilyen kicsi erőforrás spórolás értelmetlennek tűnik számomra. Valamint ennél sokkal-sokkal komolyabb problémáival, kompromisszumaival és tulajdonságaival foglalkozhatna a kedves topic indító az adatbázis-kezelőknek.

--
Keep it simple, stupid.

"Egymillió rekordnál a különbség nincs 1 megabyte. "

Az a baj, hogy az adatbázis lekérdezések nagyon nem szekvenciális olvasásból állnak. És persze, csak akkor 1 mb, ha egyetlen boolean mező van a táblában. De ha 16, akkor már nagyobb a különbség. A lekérdezés sebességében pedig nagyságrendes különbségek lehetnek.

"Változásnál meg gondolom csúsztatja őket"

Ezt nem értem. Miért kéne csúsztatni? Ha az egyik mező megváltozik, akkor azt ah egy bitet átirja a byte-ban és kész.

"És 1 bitnek kell félremennie ahhoz, hogy az egész káoszba dőljön"

Ha bitek/byte-ok csak úgy "félrecsúsznak" egy adatbáziskezelőben, az már régen rossz... De nincs is mi félrecsússzon, csak ha a tábla sémája is megváltozik, de akkor úgyis át kell irni az egészet.

"Valamint ennél sokkal-sokkal komolyabb problémáival, kompromisszumaival és tulajdonságaival foglalkozhatna a kedves topic indító az adatbázis-kezelőknek. "

Na ezzal egyetértek. Ha mysql-t választ egy komolyabb projekthez, akkor a legkissebb gondja a boolean-ek primitiv kezelése lesz...

"termeszetesen sem a google, sem a wikipedia, sem a facebook nem ert ahhoz, amit csinal."

Jaj, ezek a cégek/szolgáltatások mysql-el való reklámozása pont olyan röhejes mint amikor a tv-ben a citroen a berlingo-t a rally vb cimeivel hirdeti... :))
Elképzelem ahogy egy google lekérdezés egy 10 terabyte-os mysql adatbázis clusterbe fut bele, ROTFL :)))

Ezek teljesen speciális alkalmazások, ahol részterületeken teljesen egyedi megoldásokra használnak mysql-t, az ég világon semmi köze az átlagos mysql felhasználáshoz, butaság ezekkel példálózni.

google valoban egyreszt szenne patchelt mysql-t futtat, masreszt a soksok terrabyte-os adatbanyaszathoz megvan a sajat (bigtable talan a neve) adatbazisa, viszont a wikipedia ha jol emlekszem kb. vanila mysql-lel megy, aztan facebook ugyan nagy mysql contribute-or tehat o is peccselget, de ott van meg a flickr meg a youtube, ha meg nagy site-okat kell mondani.
imho webre az ilyen "lightweight" adatbaziskezeloke a jovo.

Tyrael

,,Az a baj, hogy az adatbázis lekérdezések nagyon nem szekvenciális olvasásból állnak. És persze, csak akkor 1 mb, ha egyetlen boolean mező van a táblában. De ha 16, akkor már nagyobb a különbség. A lekérdezés sebességében pedig nagyságrendes különbségek lehetnek.''

Értem én, hogy be smart, meg amellett is vagyok. Van, hogy több terás adatbázis-sal dolgozom, de valahogy nem tudom átérezni ezt az 1 bit vagy 1 byte dolgot (sebesség tekintetében sem). Aztán fene tudja, lehet hamar tudnék olyan helyzetbe kerülni, hogy áldanám azt a bites megoldást. Cselesek ezek a lekérdezések.

,,Ezt nem értem. Miért kéne csúsztatni? Ha az egyik mező megváltozik, akkor azt ah egy bitet átirja a byte-ban és kész.''

Például, törölsz egy rekordot. Akkor a sorrend változik (pl a 9-dik boolean a 8-dik lesz), minden utánalévőt egyel visszább kell mozgatni. Nyilván ez nem lehet kihívás egy rendszernek sem, csak megemlítettem.

,,Ha bitek/byte-ok csak úgy "félrecsúsznak" egy adatbáziskezelőben, az már régen rossz...''

Az tuti :)

,,Na ezzal egyetértek. Ha mysql-t választ egy komolyabb projekthez, akkor a legkissebb gondja a boolean-ek primitiv kezelése lesz...''

Nem olyan rossz az a MySQL :)
--
Keep it simple, stupid.

"Például, törölsz egy rekordot. Akkor a sorrend változik (pl a 9-dik boolean a 8-dik lesz)"

Szerintem keversz valamit. Az az egy byte (mondjuk 8 bit mező esetén) minden egyes rekord végén ott van. Nem központi helyen tárolódik, hanem a rekord többi adata mellett. Ha kitörölsz egy rekordot, akkor törlődik az egész byte, nincs mi félrecsússzon.

( uid_16401 | 2009. 02. 01., v – 22:40 )

Ez a diszkurzus alulról konvergál a a -oo -hez, ott ahol a függőleges tengelyre a "értelmi szint"<->"hülyeségi fokot" kablirálták fel, míg a vízszintesre a hozzászólások számát...