ugrás a tartalomhoz

Mennyire vastag a vastag kliens?

inf · Okt. 12. (H), 14.00
Amennyire én tudom a vastag kliens pl egy single page application, amikor a presentation nagy részét a kliensre toljuk, az üzleti logika viszont marad a szerveren, mert az előtt csinálunk jogosultság ellenőrzést. Valakivel viszont összevitatkoztunk ezen, mert szerinte a vastag kliens az, amikor az üzleti logika is a kliensre megy, és csak egy adatbázis van a szerveren. Ez utóbbi nekem elég fura, de így utánaolvasva intraneten esetleg előfordulhat, hogy elkövetnek ilyet. Van erről valami tapasztalatotok, esetleg véleményetek? Egyáltalán milyen hátrányai vannak, ha az adatbázisra tesszük a jogosultság ellenőrzést, concurrency kezelését, stb?
 
1

Tinédzser korú emlékeim

mind1 valami név · Okt. 12. (H), 15.26
Tinédzser korú emlékeim szerint vékony kliens ami csak a megjelenítést intézi (browserben, remote desktop stb.), ami ennél több, az vastag kliens.
Tévedés joga fenntartva.
2

Itt arról van szó, hogy az

inf · Okt. 12. (H), 16.57
Itt arról van szó, hogy az alkalmazás logika kell e a vastag klienshez vagy sem. Igazából abban sem vagyok biztos, hogy amit a fazon "alkalmazás logikának" hív, az a business logic, de olyan 90%, hogy arról van szó. Na most a webalkalmazásoknál a business logic sosem kerül a kliensre, mert nem lehet megbízni benne. Ha csak egy böngészős JS alkalmazásról van szó, akkor is egy böngésző pluginnel vagy egy XSS-el bele lehet nyúlni, onnantól meg már bármi bekerülhetne az adatbázisba, ha a kliens dönt róla, esetleg az egész ellopható lenne. A jogosultság ellenőrzés, validáció mindig a szerveren szokott menni. A formai validációt esetleg be lehet másolni a kliensre, hogy kevesebb hibás kérés menjen a szerverre, de nagyjából ennyi. Azért nem értem ezt a megközelítést. Nagyon meg kell bízni a kliensben, ha valaki ezeket át akarja tenni oda. Illetve a jogosultság kezelés eléggé beszűkült kell, hogy legyen, mert az adatbázisnál elég kevés a lehetőség bármi egyedi állítására. Plusz az alkalmazás se nagyon tudja elrejteni azokat a dolgokat, amihez nincs joga az embernek, hacsak nem az adatbázisból szedjük ki ezt az infot. Fura az egész, nem is értem miért csinál bárki ilyen rendszert. Talán asztali alkalmazásoknál tudom elképzelni, ha fájlrendszer helyett adatbázist akarnak használni, de kliens-szerver környezetben nagyon idegennek hat.
3

Nem kell

Pepita · Okt. 13. (K), 09.32
Itt arról van szó, hogy az alkalmazás logika kell e a vastag klienshez vagy sem
Nem kell, de nincs is kizárva.
Szerintem az, hogy mit nevezünk vékony vagy vastag kliensnek, eleve véleményfüggő, és nem is igazán lehet éles határt szabni.
Alkalmazás logika is többféle van, pl xy adat megléte esetén lehet z adatot megadni: ezt ki kell vinned frontendre _is_, hogy addig ne jelenítsd meg a z inputot (vagy disabled), amíg nem használható.
Szóval bármennyire is vastag a kliens, abban egyetértek, hogy egy webalkalmazásnak a biztonsága a szerveren van, annyit tud tenni a FE, hogy borzasztóan egyszerűen validálható adatcsomagokat küld be - így csökkentve a BE terhelését.
4

Hát a fazon váltig állította,

inf · Okt. 13. (K), 14.10
Hát a fazon váltig állította, hogy az a különbség a vékony és a vastag kliens között, hogy a kliensben van e az alkalmazás logika. Én meg ezzel abszolút nem értek egyet. Wikipedia szerint sem ez a különbség, hanem csak annyi, hogy a szerver végzi e a munka nagy részét. ref Mindezt információbiztonsággal kapcsolatos előadás után. Olyan helyzetben vagyok, hogy a szakdolgozathoz témavezetőt kellene választanom, és vagy ő vagy egy másik, aki kevésbé segítőkész. Eddig ez felé húztam, de úgy tűnik, hogy nincs meg a szakmai tudása, vagy legalábbis szoftverfejlesztéshez nem ért, csak hekkeléshez. Nekem meg az előbbi kellene jobban a témámhoz.

Igazából ez egy érdekes trend, hogy manapság mindenki azt akarja eladni, hogy ő mindenhez is ért. Orvosoknál is láttam már rá néhány példát az elmúlt években, de most informatikusoknál is ugyanezt látom. Olyat viszont még nem láttam, hogy valaki beismerte volna, hogy nem ért hozzá. :D
5

Hú, így kissé kemény helyzet...

Pepita · Okt. 14. (Sze), 12.02
szakdolgozathoz témavezetőt kellene választanom, és vagy ő vagy egy másik, aki kevésbé segítőkész
Ez így eléggé gáz, elsőre az jutott eszembe, hogy rá se ránts, az "csak" szakdolgozat, legyen meg a papír, aztán majd elfelejted...
De mi van akkor, ha nem tudod megvédeni?...

Sajnos a piac igénye az (egyre inkább), hogy mindenhez is érts... Saját tapasztalat: junior(!) fejlesztő (pár éve, nem túl rég): ő nem junior, hanem "medior" (előzőleg ilyet senkitől nem hallottam), és fullstack. Sőt, üzemeltetésben (LAMP) is gyakorlott. Az első néhány komolyabb backend hiányosság után (sql injection-től kezdve a kódszervezési hibákig kb minden) óvatosan megpróbáltuk inkább frontend irányába terelni - sajnos hasonló eredménnyel, de legalább biztonsági rések nélkül...
Szóval ma egy huszonéves "friss-hús" szoftverfejlesztőnek lehet sértő a junior kategória gyakorlat, tudás és megfelelő hozzáállás nélkül is.
Olyat viszont még nem láttam, hogy valaki beismerte volna, hogy nem ért hozzá.
Dolgozzunk együtt, én rendszeresen mondok olyat, hogy "ezt még nem ismerem, utána kell nézzek, ha valóban így akarjuk csinálni" :). Szerintem sokkal nagyobb baj az, amikor olyan valaki ajánl egy bizonyos technológiát, aki maga sem ismeri, sőt, lusta is arra, hogy megismerje. Nos, győzd meg őt, hogy az adott cél eléréséhez egy másik technológia sokkal jobb lenne...
7

Egyelőre még mindig nem

inf · Okt. 15. (Cs), 18.50
Egyelőre még mindig nem gondolom úgy, hogy elég tapasztalt lennék hozzá, inkább az elméletét ismerem a szoftverfejlesztésnek, nincs annyira sok gyakorlatom. Meg inkább vállalkozás irányba tendálok még mindig, de majd idővel lehet az lesz, hogy jelentkezek hozzád juniornak, ha meguntam a tengés-lengést és becsődöltem újra a vállalkozással is. :-)

Amúgy erről a képzésről van szó. ref Több a jogi része, mint a technikai, úgyhogy valszeg nem akkora gáz, bármelyiket választom, mert technikai dologról van szó, és szeretnek néha olyat is olvasni sok jogi szöveg után. Konkrétan gépi tanulás a kibervédelemben címen lenne valami szösszenet, és abból is inkább valami egyszerűre koncentrálnék, pl valami egyszerűbb alkalmazás syslogjának a feldolgozása gépi tanulással, és riasztás a rendszergazdának, ha valami rendellenes van. Sőt igazából én csak javaslatot teszek témavezetőre, aztán majd egymás között megbeszélik, hogy kit kapjak. A fazon még fura más szempontból is, mert ilyeneket is mondott, hogy a syslogot is ő csinálta meg, hogy valami magyar tűzfal fejlesztéséhez is hozzájárult meg ilyesmi. Ha rákeresel wikipedian a syslogról az van, hogy valami amcsi találta ki. A google sem talál semmit- róla, ha beírom a nevét, egy fantom. Szóval még akár az is lehet, hogy ez a huszadik álneve. Ki tudja hogy megy ez magasabb szinteken. :D A másik nagyon jól leinformálható prof, bár annak is van egoja ezt olvasva. ref :D Na mindegy, csak legyek túl ezen, aztán tudok GDPR-ezni, meg önkormányzatoknak is dolgozni.

Lehet átgondolom ezt az egészet, és csinálok valami kevésbé technikai jellegűt. Nem biztos, hogy jó kilógni a sorból, és nekem is kevesebb munka. Egyelőre még nem volt téma választás, úgyhogy van időm átgondolni, meg kíváncsi vagyok a listára is, amit felhoznak választhatónak.
10

A "syslog-ng"-t (nem a

BlaZe · Okt. 16. (P), 00.40
A "syslog-ng"-t (nem a syslogot) valóban magyarok csinálták: a Balabit. Simán lehet, hogy igazat mond, ha ott dolgozott :)
11

Állítólag Balazs Scheidler,

inf · Okt. 16. (P), 02.59
Állítólag Balazs Scheidler, akit tanított, de hajlamos egy kicsit magáénak vallani mindent, amit a tanítványai találtak ki ezek alapján.
13

Nem nyert :)

Pepita · Okt. 16. (P), 09.38
idővel lehet az lesz, hogy jelentkezek hozzád juniornak
Két gond van:
- jelenleg tudtommal nem engednek felvenni fejlesztőt
- Te _juniornak_ biztosan nem jöhetsz. :-D

Vállalkozással egyébként nem szükségszerű becsődölni, de kell megfelelő véna hozzá, és szoftverfejlesztésre ma már nem biztos, hogy érdemes egyszemélyes céggel indulni..

A képzés maga egyébként tetszik, kevés igazán jó szakembert ismerek a területen. A témaválasztás érdekes, de szerintem vigyázni kell, hogy ne menjen túlságosan szoftverfejlesztési irányba.
Hát "a másik prof" oldalát olvasva én a javaslathoz is inkább egy pénzt dobnék fel. :)

Lehet átgondolom ezt az egészet, és csinálok valami kevésbé technikai jellegűt.
Csak egy "kibic" véleménye(m): szerintem azzal tényleg jobban jársz.
14

Ja hát, nem mindig jó kilógni

inf · Okt. 16. (P), 16.08
Ja hát, nem mindig jó kilógni a tömegből, meg felesleges kockázatot vállalni. Amit elterveztem, azt meg meg tudom csinálni a képzéstől függetlenül is. Machine learning érdekel, ismerősöm abban dolgozik, úgyhogy van mit olvasgatnom.
6

Attól nem lesz a kliens

BlaZe · Okt. 14. (Sze), 23.08
Attól nem lesz a kliens vastag, hogy UX, vagy terheléscsökkentés stb miatt alkalmazás-specifikus logika van a kliensen (is). A vékony és a vastag kliens ott válik el, hogy a vékony kliens működéséhez szükséges a szerver folyamatos jelenléte, a vastag kliens viszont kapcsolat nélkül is képes ellátni a funkcióját, ha csak korlátozottan is. Például részeredmények átmeneti tárolásával, ami a kapcsolat létrejötte után elküldi a tárolt adatokat a szervernek feldolgozásra.

A concurrency kezelésben elég jók a DB-k, ez nagyon alapvető képességük kell legyen, és feladattól függően érdemes lehet rájuk bízni. Egy tipikus webalkalmazás is jellemzően ezt teszi. Ha a kliensnek csak DB kapcsolata van, akkor ezt érdemes viszont tároltakkal megtámogatni. A jogosultságkezelés is vállalható, viszont szintén kell tárolt logika a validációkra ott is. Nyilván, itt nem üzleti igényekre alakítható, üzleti entitásokkal dolgozó jogosultságkezelésről van szó.
8

Attól nem lesz a kliens

inf · Okt. 15. (Cs), 19.05
Attól nem lesz a kliens vastag, hogy UX, vagy terheléscsökkentés stb miatt alkalmazás-specifikus logika van a kliensen (is). A vékony és a vastag kliens ott válik el, hogy a vékony kliens működéséhez szükséges a szerver folyamatos jelenléte, a vastag kliens viszont kapcsolat nélkül is képes ellátni a funkcióját, ha csak korlátozottan is. Például részeredmények átmeneti tárolásával, ami a kapcsolat létrejötte után elküldi a tárolt adatokat a szervernek feldolgozásra.


Aha, hát én is úgy gondoltam, hogy nem jó, amit mond. Ezek szerint az sem, amit én mondok. :-)

Ha már webes fórum, akkor itt érdemes megemlíteni, hogy már vannak offline meg online eventek: ref, szóval elvileg egy SPA-t is meg lehet írni így, a rendelkezésre álló nem éppen nagy tárhellyel, amit a localstorage vagy sessionstorage ad. ref Itt azért ennek van adatbiztonsági vonzata is, ugyanúgy, mint a cache fejléceknek, mert a nagy többség nem ügyel rá, és titkosítatlanul tárolja az adatokat a kliens gépén.

A concurrency kezelésben elég jók a DB-k, ez nagyon alapvető képességük kell legyen, és feladattól függően érdemes lehet rájuk bízni. Egy tipikus webalkalmazás is jellemzően ezt teszi. Ha a kliensnek csak DB kapcsolata van, akkor ezt érdemes viszont tároltakkal megtámogatni. A jogosultságkezelés is vállalható, viszont szintén kell tárolt logika a validációkra ott is. Nyilván, itt nem üzleti igényekre alakítható, üzleti entitásokkal dolgozó jogosultságkezelésről van szó.


Igen, ez világos, de nagyon fapados lenne egy ilyen jogosultság kezelés, ami DB felhasználó alapú, már ha erre gondolsz. Igazából sosem csináltam ilyet, csak így belegondolva nem tűnik túl előnyösnek ahhoz képest, ha alkalmazás specifikusan programozzuk le. Nem látom továbbra sem az előnyét ennek a megközelítésnek, csak a hátrányait.
9

Ahol szofisztikáltabb

BlaZe · Okt. 16. (P), 00.33
Ahol szofisztikáltabb userkezelés kell, ott meg lehet írni azt is tároltban. Igazából egy modern RDBMS elég sokmindent tud, és szinte bármit meg lehet írni benne. Hogy érdemes-e, az már más kérdés :) Ahol semmi más szerepe nem lenne a szerveroldalnak, csak hogy átpasszolja az RDBMS-nek az adatokat, vagy ahol a logika nagy része sok rekorddal dolgozik, amiket nem lenne jó kimozgatni a DB-ből csak a feldolgozás kedvéért, ott ki lehet hagyni, és be lehet tenni az RDBMS-be az egészet. De bevallom én se erre indulnék, ha nem nagyon muszáj :)
12

Én ha nagyon muszáj, akkor

inf · Okt. 16. (P), 03.03
Én ha nagyon muszáj, akkor se. :D
15

Definíció, filozófia, adatbázisra mit bízzunk, példák, tipp

ydsMo9gx · Okt. 29. (Cs), 16.09
A vastag kliens definíciója kb. ez: wikipedia.org/wiki/Fat_client
A vékonnyal összehasonlítva még jobban érthető: wikipedia.org/wiki/Thin_client

Tipikus filozófiai jellegű, elmosódott fogalom. Az a lényege, hogy minél többet bízzunk a kliensoldalra. Kisebb adatforgalom, kisebb szerverterhelés, gyorsabb működés (ha lokális műveletek dominálják az alkalmazási területet) lehet az előnye.

Az adatbázis(ok) kezelését mindenképp a szerverre korlátoznám. Ebből logikai úton levezethető egy sor dolog. A jogosultságkezelés kizárólag a szerverre tartozik. Adatbevitel formai ellenőrzése nyilván mehet a kliensen, a tartalmi ellenőrzés csak a szerveré. El lehet térni ettől, ha erőltetjük, de abból sosem sül ki jó.

Kontrollerek, routing, view-k: ahogy kényelmesebb (hosszú távon). Szívem szerint ezek is szerverre valók, de akik JavaScriptben, TypeScriptben dolgoznak, azok másképp látják.

Adatbázisba bele lehetőleg semmit ne tegyünk, különben debuggolási és verziókezelési rémálmaink lesznek. A tárolt eljárásokkal csak baj van. Triggereket csakis külön engedéllyel, alapos megfontolás alapján, de inkább úgy se. Én előre szóltam...

Példák:

Az Android és iPhone appok mind vastag kliensek. Ezeknél legális és illegális adatgyűjtéssel növelik a bevételt. Döntően ezért erőltetik az appokat, a többi parasztvakítás. Kivéve a játékokat, azokat tényleg appnak érdemes elkészíteni.

Az Oracle Forms és Oracle Reports tipikus vastag kliens. De egyik sem webes, ezért sosem derült ki róluk, hogy adatbiztonság szempontjából alapvetően hibás elképzelésen alapulnak. Részemről soha többé Oracle!

Weben a néhai Flashben és készítettek vastag klienseket, csupa öröm és bódottá közepette. Ettől megkímélt a sors.

Hogy indokolt példákat is említsek: pergős MMOG-okat csak vérbeli vastag klienssel lehet megvalósítani. Még nagy sávszél esetén is, mert a késleltetések (latency) miatt különleges trükkök kellenek mindenképp, hogy a játékosok minél kevesebb lagot kapjanak (wikipedia.org/wiki/Lag).

Könnyen érthető, szép példa a virustotal.com. Csak új fájlt tölt fel szerverre, miután a kliense a) ellenőrzi a fájl méretkorlátját b) kiszámolta annak SHA256 értékét, és annak alapján a szerverének még ismeretlen a fájl.

Tippek:

Weben kerüljük el a kliens vastagítását, amíg lehet. Intraneten mehet, és akkor már ne webes legyen a kliens, hanem asztali (desktop).

Ha már muszáj vastag klienssel bajlódni, Javát és más JVM alapú nyelveket javasolnék, szerverre és desktopra. Leginkább Kotlint. Androidra is. iPhone-ra is Kotlint, esetleg Swiftet.
16

oracle??

mind1 valami név · Okt. 29. (Cs), 16.22
Bocs, de mint ex-ex-ex DBA, hadd kérdezzem meg, mi bajod az Oracle programokkal?
17

Önmagában az Oracle RDBMS

ydsMo9gx · Okt. 29. (Cs), 18.04
Önmagában az Oracle RDBMS kétségtelenül a legjobb, és még sokáig az is marad. De:

Forms, Reports: az adatbiztonság a belügyük, képtelenség auditálni őket. El kell hinned a cég állításait, márpedig az Oracle-nek sem hiszek el semmit látatlanban. És a vizuális fejlesztőeszközök alapvetően tévúton járnak, mert a) sok mindent újra meg újra el kell készítened, a módosításokat ugyanígy (nem lehet kiemelni a közös részmegoldásokat) b) minden „lötyög” bennük (ellenpélda: CSS grid) és semmi nem reszponzív (lásd responsive design) c) körülményesek a részellenőrzések, ezért általában nem is foglalkoznak velük, egybefogva mennek-jönnek az adatok d) rettenetesen körülményes a picit bonyolultabb adatszerkezetek kezelése e) nem láttam még jó cache-elési megoldást hozzájuk, csak gányolásokat f) verziófüggők: ha az RDBMS, Forms, Reports közül valamelyiket cseréled, mindent cserélned kell, ezért aztán sok helyen leginkább nem cserélnek semmit, ezért aztán kőkorszaki eszközökkel krampácsolnak.

Az a)-e) összefoglalva: kőkorszak. Lehet, hogy a legújabb verzióik sokkal jobbak, de legfeljebb a vaskorig fejlődhettek.

Apex, Forms, Reports: talán a legnehezebben debuggolható fejlesztőeszközök.

Minden, ami Oracle: jellemzően az államigazgatásban használják a cuccait. Költség ugyebár ott nem számít, illetve jut is, marad is a megfelelő zsebekben. Magánszférában majdnem ugyanez megy a multiknál is. Ahol viszont számít a költség, ott licencek helyett inkább a hardverre és a fejlesztőkre érdemes költeni.

Tíz évvel ezelőtt talán még indokolható volt Oracle-t választani. Ma már azt kell alaposan megindokolni szerintem, hogy miért nem PostgreSQL-t választunk adatbázisnak (helyi [desktop, smartphone] adatbázisnak SQLite, cache-eléshez Redis a tuti). MySQL, MariaDB, MongoDB, Oracle, ...: felejtsük el mindet.

És van egy szempont, ami a zsebek megtöltésén kívül szintén felülír minden mást: a blame game. Enterprise fejlesztéseknél ezek és a (céges, állami) politika uralja a döntéseket. Meg a közeg, a jól megszokott állóvíz (mondhatnám csúnyábban is). Ami eddig jó volt, ezután is az lesz, ej, ráérünk arra még, amíg nem szólnak felülről (felül meg nem értenek a technikai kérdésekhez).

Ha tévedtem valamiben, írd meg, engem is érdekel a véleményed!
18

Bocs, akkor félreértettelek.

mind1 valami név · Okt. 29. (Cs), 18.23
Bocs, akkor félreértettelek. Azt hittem, olyan hibákról beszélsz, amik magának a desktop szoftvernek okoznak sérülékenységet vagy a kliens-szerver kommunikáció titkodítasának a hiányára.

Amiket felsoroltál, azokkal szerencsére sosem volt dolgom.
19

Ha csak ez a kérdés:

ydsMo9gx · Okt. 29. (Cs), 19.22
Ha csak ez a kérdés: cvedetails.com/vendor/93/Oracle.html
Van mit csemegézni...

Tegyük hozzá, hogy Ellison mindig nagyon agresszívan lépett fel az Oracle termékeinek megbízhatóságával (és teljesítményével) kapcsolatban felmerült kételyek ellen. Nem mintha rosszabbak lennének a többinél, de a zsíros profitból illene atombiztos megoldásokra törekedni. Ehhez képest egyes sérülékenységeket évekig nem javítottak...

Messze-messze az Oracle a legjövedelmezőbb adatbáziskezelő, és ezt nem a technikai erényeinek köszönheti a cég.
21

Hát azt látom, hogy jó volt

mind1 valami név · Okt. 29. (Cs), 19.46
Hát azt látom, hogy jó volt anno a megérzésem,miszerint a 10i-vel meredek zuhanásnak indult az Oracle.
(Én a 10i megjelenésekor hagytam fel az egész IT-vel)

De azért azt tegyük hozzá, hogy míg az említett postgresql csak egy adatbáziskezelő, addig az Oracle gyakorlatilag egy önálló op.rendszer, rdbms-nek álcázva.
20

Adatbázisba bele lehetőleg

inf · Okt. 29. (Cs), 19.41
Adatbázisba bele lehetőleg semmit ne tegyünk, különben debuggolási és verziókezelési rémálmaink lesznek. A tárolt eljárásokkal csak baj van. Triggereket csakis külön engedéllyel, alapos megfontolás alapján, de inkább úgy se. Én előre szóltam...


Ez így szerintem nem igaz. Szemlélet és eszköz függő, hogy működik e egy kód vagy debuggolni kell. Tárolt eljárásnál is van lehetőség automatizált teszteket írni, igazából bármilyen nyelven és módszerrel van erre lehetőség, mert csak annyi kell hozzá, hogy egy függvény képes legyen meghívni egy másikat, pl ref.

A gond nem a tesztelhetőség, hanem, hogy baromi kényelmetlen mondjuk egy objektum orientált nyelvhez képest ebben bármi komolyabbat alkotni. Kb. olyan, mint bash scriptet, XSLT-t vagy hasonlókat írni.

Ami még ellene szól, hogyha más adatbázis típusra akar migrálni valaki, pl MySQL-ről MongoDB-re, akkor nagyon költséges lesz minden tárolt eljárást újraírni, és hacsak nem nagy adatmennyiséggel dolgozik az ember, amit nem akar az adatbázis és a program között oda-vissza küldözgetni, akkor nincs értelme.
22

Igen, van lehetőség teszteket

ydsMo9gx · Okt. 30. (P), 01.24
Igen, van lehetőség teszteket írni, sőt, debugger is van az adatbázis-kezelők többségéhez. Csak konkrét hiba javításakor aztán 2 debuggerrel és 2 naplórenddel kell bűvészkedni (jó esetben). Mezei feature flagek átadása, létrehozása, módosítása, törlése is többletmunka. Stb. stb. stb. Minden megoldható, csak nehézkesen, többlet munkával. Ha szorít az idő, ha nem értünk egyes részletkérdésekhez (nem eléggé értünk hozzájuk), akkor ez könnyen rémálommá válik.

Az adatbázis-kezelők közötti migrálás végképp rémálom lehet ilyen tekintetben. Tárolt eljárások nélkül is az...

Amíg megoldhatók a sebességproblémák másképp is, addig ne tárolt eljárásokkal akarjunk tuningolni. Más hasznukat pedig nem ismerem. Jobb adatszerkezetek, jobb algoritmusok, erősebb hardver: szerintem általában ezek a tuningolás lépései.

Minden alól van kivétel, ezek alól is. Láttam komplett webes rendszert tisztán tárolt eljárásokban megírva, Apache előtéttel. Üzleti logika is, a view-k kézzel összerakva (sablonkezelés hiányában), admin oldal, dashboardok, monitorozás, tényleg minden az adatbázisban volt, néhol nagyon fapadosan, de hibátlanul. Az az egy ember értette a működését, aki készítette. Lecserélhetetlen, pótolhatatlan (talán ez is volt a cél). Nyilván ő is pótolható, csak roppant drágán.

Szóval legjobb a lehetséges minimumra szorítkozni ebben.
23

Persze hogy nem

Pepita · Okt. 30. (P), 09.36
Mind a tárolt eljárásnak, mind a triggereknek meg van a maguk szerepe, előnye és hátránya éppúgy, mint pl a bash scripteknek vagy hogy használ-e az alkalmazás keretrendszert és milyet.

Nem feltétlenül kell big data ahhoz, hogy indokolt legyen tárolt eljárást használni, az is "elég", ha pl több egymás utáni query eredményétől függ a "végső", hasznos adatot visszaadó query szerkezete, logikája. Nyilván ilyen esetben felmerülhet gyanúként a rossz adatbázis-szerkezet is, de ha arra gondolok, hányszor futottam bele olyan utólagos feature - kérésbe, hogy "ha itt ez történt, akkor innen számoljuk a statisztikát meg onnan, ha az történt, akkor amonnan" stb.. Erre nem tudsz előre felkészülni, és választhatsz, hogy a szoftvered küld 4-5 kvázi felesleges kérést a db szerver felé, mielőtt összerakná a megfelelőt, vagy mindezt áthelyezed a db szerverre és megúszod 1 kéréssel (utóbbi lényegesen gyorsabb).

Megemlíteném a triggereket is, van igazság abban, hogy "csakis külön engedéllyel, alapos megfontolás alapján", de pl ha szükség van history táblára (a figyelt táblában pontosan mikor és mi változott), akkor a legkézenfekvőbb megoldás a trigger.

más adatbázis típusra akar migrálni valaki, pl MySQL-ről MongoDB-re
Ezen csodálkoznék (konkrétan ha MySQL-ről MongoDB-re), mert az egyik gyors és sok lekérdezésben erős, míg a másik insertben és nagy mennyiségű adat kvázi statikus tárolásában jó. Ezt a két db-t egymás mellett többször használtam már, egymás helyett (migrálás) még soha.
Megjegyzem, hogy előbbi history problémára az is lehet jó megoldás - amennyiben megtehetjük (teljesítmény, biztonság), hogy a szoftver intézi - hogy az xy MySql tábla history-ja a MongoDB-be kerül, esetleg annak legutóbbi n napját frissítgetjük vissza egy MySql táblába.
24

history - audit?

mind1 valami név · Okt. 30. (P), 10.10
Rég volt és most nem néztem utána: oracle-nek van audit funkciója. Tábla szerkezetének, egyéb admin jellegű módosításoknak a követésére biztosan jó, de rémlik, hogy akár a selectek figyelésere is jó.
Ha ez igaz, akkor history jellegű dolgokra is alkalmas lehet.
Amit nem tudok:
- más adatbázisnak van-e hasonló funkciója?
- gyorsabb vagy lassúbb, mint a trigger.
27

audit

ydsMo9gx · Okt. 30. (P), 18.13
Audithoz alapvető követelmény, hogy ne lehessen törölni vagy módosítani (észrevétlenül) a bejegyzéseket. Vagy legalább nehezítsük meg annyira, amennyire lehet. Ideális esetben fizikailag is nehezen elérhető helyre kerüljön az erre fenntartott adatbázis vagy napló. Event sourcing ebben is segít. Az észrevétlen törlések, módosítások ellen integritás-ellenőrzés kell. "Kézzel" is készíthető korrekt audit-rész, és sebességproblémák aligha lépnek fel itt.

Ehhez képest jellemzően megbíznak egy auditor céget, az meg nem a technikai részleteket firtatja. A bábák közt pont a baba vész el...
29

Szerintem félreértesz: azért

mind1 valami név · Okt. 30. (P), 20.41
Szerintem félreértesz: azért vetettem fel az auditot, mert szó volt róla, hogy history, amihez trigger kell, ami lassú. Erre gondoltam alternatív megoldásként az audit opciót, ami tudtommal nem lassít lényegesen.
31

Szerintem értelek :). Én azt

ydsMo9gx · Okt. 30. (P), 22.53
Szerintem értelek :). Én azt írtam le, ami eszembe jutott a kérdéseid nyomán. Az Oracle auditja biztosan nem lassú, azért, mert semmi olyat nem csinál, ami lassú lehetne (sosem használtam, de most megnéztem a leírását). Viszont készen kínál egy sor szolgáltatást, amiket ennek köszönhetően nem kell leprogramozni.

Ámde pont azt nem kínálja, amit fontosnak tartok, és amit ezért megemlítettem: 1) integritás-ellenőrzés, az észrevétlen belenyúlások megakadályozásához 2) fizikailag is elkülönített tárolás, szintén a belenyúlások elkerülésére.

Konkrét, életből vett példa: ilyen adatbázis-kezelésbe épített audit nélkül futnak komoly rendszerek, és előfordul, hogy (anyagi haszonszerzés céljából) belenyúlnak fontos adatbázisokba. A "komoly" és a "fontos" jelzőt nem részletezem, okkal. Ilyesmihez magas szintű jogosultság(ok), hallatlan tudás és hosszú idő kellhet (nem minden esetben!), de... nem mondok többet.

Van, amihez 1) és 2) is kevés, de fokozhatjuk megtöbbszörözött távaudittal, hogy mindegyik példányhoz hozzá kelljen férnie a támadónak, ráadásul szűk időintervallumon belül. Az integritás-ellenőrzés is végtelenségig tuningolható. Mindezek nem lesznek lassúak, ha van elég sávszélesség. Szóval ez a két alapelv szükséges és elégséges a megfelelő védelemhez.
32

Ha tudnád, hogy kezdő

mind1 valami név · Okt. 30. (P), 23.30
Ha tudnád, hogy kezdő DBA-ként mi mindenben turkáltam... :D

Sajnos az emlékeim megkoptak, auditot mintha ki lehetett volna tenni WORM-ra is, ezzel többé-kevésbé biztosítva, hogy az audit tábla ne legyen hackelhető.
De még mindig ott tartok, hogy nem a tényleges auditálás a lényeg, hanem a beépített audittal kiváltani egy lassúbb megoldást.
Egyébként az audit, ha biztosítva van, hogy ne tudjanak belenyúlni, legalább visszakereshetővé teszi az esetleges illetéktelen módosításokat.
Viszont ez jelentős lassulást okozhat.

Ami manapság elvárás lenne... Ahhoz valami pgp jellegű kódolás kellene ami megintcsak lassít és körülményessé teszi az adatok kezelését.
Szerintem.
33

"Viszont ez jelentős

ydsMo9gx · Okt. 31. (Szo), 00.48
"Viszont ez jelentős lassulást okozhat."
Csak akkor lassíthat, ha mindent-egybe jellegű az architektúra.

1) Ahol audit kell, ott teljen külön gépre, távoli helyen (szerintem). Nem a fizikai távolság a lényeg, hanem az, hogy máshol (másik épület, másik telephely, másik város) legyen, és nehéz legyen hozzáférni. 2) Ha ez megvan, akkor következő lépésben minden egyes műveletet és annak eredményét (hibákkal együtt) el kell tárolni azon a távoli helyen. 3) Az így eltárolt adatokhoz read-only jellegű hozzáférést kell adni, az auditálásra jogosultaknak, az auditálásra jogosult helyekről (!), az előre, írásban (jogszabályban, belső szabályzatban) rögzített módon. Ezek között lehet akár biztonsági jellegű dashboard is, tehát nem csak hagyományos audit, tehát mindez a biztonsági részleghez tartozik.

Az auditnak nem kell valósidejűnek lennie, nem tudok olyan helyzetet elképzelni, ahol mondjuk 1 percnyi csúszás komoly gondot okozhatna. Az adatkapcsolat megszakadása persze riasztást indítson.

Szerintem még az is elfogadható, ha nagy ritkán kimarad néhány művelet az auditból, de ez már e műveletek jellegétől függ.

Ezek alapján az audit kezdőpontja egy vagy több memóriában tárolt sor, a műveletek paramétereivel, eredményével, hibákat is beleértve, sorszámmal+időkóddal kiegészítve, titkosítva, integritásvédetten. A sorbeli adatokat ütemezetten, kötegekben érdemes továbbítani, nem egyesével.

Ha ez 1%-nál nagyobb terhelést okoz, akkor valami nem stimmel. A PGP rossz választás itt, nem a titkosítás feltörhetetlensége a cél, hanem a megnehezítése, mert a műveletekről eltárolt adatok értelmezése belsős ismereteket igényel. És viszonylag kis adatcsomag ír le egy-egy műveletet, ennek megfelelő titkosítást és integritásvédelmet érdemes választani. Extrém esetben külön gépre is bízható a titkosítás, de hány magnál is tartanak a modern CPU-k? Szóval nem kell külön gép se ehhez. Ha még így is kételkedsz, gondolj a HTTPS/SSL-re, az se lassú.

"legalább visszakereshetővé teszi az esetleges illetéktelen módosításokat"
Csak a detektálást teszi lehetővé, önmagában nem akadályoz meg semmit. De a fent említett 1 perces késleltetéssel együtt is hamar riaszthatja a megfelelő embereket, attól kezdve pedig nem (nem elsősorban) technikai jellegű a feladat.

Az adatmennyiségről: biztonsági kamerák képét H.264-es kodekkel tömörítve színes kép és nagy felbontás esetén is a hanganyagéval közel azonos méretű adatfolyamot kapunk. A 256 kbit/s már túlzás, és gondolj a 128 kbit/s-os MP3-ra...
35

Pgp - nem titkosítás, csak

mind1 valami név · Okt. 31. (Szo), 07.33
Pgp - nem titkosítás, csak aláírás. És nem pgp, hanem "pgp jellegű". Pusztán azért, mert egy akármilyen hash simán újraszámolható, míg a kulccsal történő aláíráshoz meg kell szerezni a kulcsot is.

A többibe (egyelőre) nem mennék bele, a nagy részét indokolatlannak érezném egy pénzügyi dolgokkal foglalkozó helyen is. Egy bizonyos szint fölött a paranoia már a kezelhetőség, üzemeltetés rovására megy. (És pont az audit funkció rgy olyan, ahonnan nem lenne szabad egy bitnek sem elvesznie)
37

Nem hiszem, hogy paranoia.

inf · Okt. 31. (Szo), 08.15
Nem hiszem, hogy paranoia. Gondolom elő van írva, hogy minek kell megfelelni, milyen biztonsági szint van, stb.
38

IT biztonság a paranoiáról

mind1 valami név · Okt. 31. (Szo), 08.57
IT biztonság a paranoiáról szól ;)
39

PGP-t sosem használtam, most

ydsMo9gx · Nov. 1. (V), 01.44
PGP-t sosem használtam, most is csak a sebességét néztem meg :).

A biztonság a paranoiáról szól, mindenhol. Mindenhol üldöznek ;). A védekezés tetszés szerint fokozható, de sosem nyújt teljes biztonságot.

"És pont az audit funkció rgy olyan, ahonnan nem lenne szabad egy bitnek sem elvesznie"
Ez attól függ, mit auditálnak és milyen céllal. Az audit ugyebár csak detektál, nem garantál. És van olyan, hogy egyszerűen nem tudsz pótolni egy-egy kevésbé fontos adatot, ha belepusztulsz, akkor sem.

Scenario: adott egy rendszer, ahol nincs teljes event log, nincs audit. Továbbfejlesztés során felmerül az igény az auditra. Első lépésben az addig szórványos naplózást teljesítik ki, de kihagyják belőle a lényegtelennek tekintett műveleteket. Erre az event logra már lehetetlen teljes auditot ráépíteni, és ez nem is tűnik fel senkinek, amíg nem hívja fel rá a figyelmet valaki. És ha jelzed ezt, akkor jó eséllyel paranoiát emlegetnek majd :).

A teljes körű event log helyigénye sokszorosa lehet a többi adatbázisénak. Ez a kezelését is lassítja, hamar el lehet jutni addig a pontig, hogy vissza kell nyesni a naplózást.
25

A MySQL-t és a MongoDb-t csak

inf · Okt. 30. (P), 10.42
A MySQL-t és a MongoDb-t csak azért hoztam fel példának, mert teljesen eltérő logikát követnek, és a tárolt eljárásaik is tök mások lesznek. Ha másik relációs adatbázisra migrálunk, akkor jóval egyszerűbb a helyzet, és nem kell nulláról újraírni az egészet.
26

NoSQL az RDBMS-ekben

ydsMo9gx · Okt. 30. (P), 17.31
"az egyik gyors és sok lekérdezésben erős, míg a másik insertben és nagy mennyiségű adat kvázi statikus tárolásában jó"
A NoSQL irányzat sikere után több-kevesebb késéssel az összes nagyobb RDBMS-t kiegészítették dokumentumkezelésre kihegyezett résszel. A lassabb INSERT-eknek két oka maradt: az egyenkénti tranzakciókra szabdalás és a téves indexelési beállítások. Más szóval a MongoDB elveszítette minden korábbi előnyét.

google.com/search?q=MySQL+document+store
google.com/search?q=PostgreSQL+JSONB+MongoDB+benchmark

Nagy tömegű adat betöltésekor érdemes letiltani az indexelést és a végén újraindexelni.
28

Ezt nem értem. Az már húsz

mind1 valami név · Okt. 30. (P), 20.38
Ezt nem értem. Az már húsz éve is úgy volt, hogy nagy mennyiségű adat betöltése=indexek eldobása, majd create index. (Oracle és DEC Rdb, meg még sokkal régebben dbase/clipper is ilyen volt)
LOB/BLOB stb. szintén ezeréves találmányok, mondjuk ezekkel élesbrn csak Oracle esetében talalkoztam, ott gyárilag szállított tárolt eljárásokkal is megvolt/-van támogatva.
Lehet, hogy végső soron jogos volt anno az értetlenkedésem a NoSQL adatbázisok létjogosultságát illetően?
30

"Az már húsz éve is úgy volt,

ydsMo9gx · Okt. 30. (P), 22.30
"Az már húsz éve is úgy volt, hogy nagy mennyiségű adat betöltése=indexek eldobása, majd create index."
Aham. Csak éppen sokan még most sem így készítenek sebességteszteket. A PostgreSQL tranzakciókezelése is feszesebb, mint a MongoDB-é vagy akár a MySQL-é. A MySQL adatbázismotorjai cserélhetők, egymással párhuzamosan is futhatnak, és a tranzakciók nélküli MyISAM volt sokáig az alap. Ez csak két példa. (Röviden: akkor lesz leggyorsabb a betöltés, ha minél kevesebb tranzakcióval és indexelés nélkül futtatjuk.)

A NoSQL-eknek volt, van és mindig lesz létjogosultsága. A "NoSQL" összefoglaló megnevezés, van ebben a halmazban sokféle adatbáziskezelő, egyedi erősségekkel és hátrányokkal.

Ha az alapot adó RDBMS (ez szerintem egy ideje a PostgreSQL) valamihez végképp lassú, vagy hosszas, hibalehetőségekkel terhelt programozást igényelne valaminek a megvalósításához, de azt a valamit egy NoSQL adatbázis-kezelő készen nyújtja, elfogadható (kisebb) ráfordítással (licencdíj, hardverigény, fejlesztési költségek, karbantartás várható költségei stb.), akkor (de CSAK akkor) érdemes mellé tenni azt a bizonyos NoSQL adatbázis-kezelőt. És ez meglepően ritka eset, szinte mindig jobban járunk nélküle. Ad abszurdum gyakran a fájlrendszer a legjobb adattároló, csak arra kell figyelni, hogy kevés fájl kerüljön egy-egy mappába/folderbe/directoryba, és mindenképpen hagyjunk 10-20%-nyi helyet szabadon a partíció(ko)n a töredezés lassítása érdekében. Másik véglet: mindent RAM-ban tartani: már nem olyan drága, villámgyors, és ha elfogadható az adatvesztés (meglepően kis) kockázata, akkor ez lehet a legjobb választás. RAM+Redis: kiforrott NoSQL adatbázis. Nézhetnénk még példákat, a lényeg: a NoSQL hasznos lehetőségeket rejt.
34

Nem igazán értek egyet a

inf · Okt. 31. (Szo), 07.24
Nem igazán értek egyet a megközelítéseddel. Itt nem csak adat tárolásról van szó, hanem lekérdezésekről is, amiknek gyorsnak kell lennie. Ha csak tárolni akarnánk, akkor minden mehetne a fájlrendszerbe egy esemény napló formájában, aztán kész. Nem rémlik, hogy pl egy gráf adatbázist ki lehetne váltani bármelyik relációs adatbázissal, mert vért izzadnánk a lekérdezésekkel.
36

Ha már szóba került az

mind1 valami név · Okt. 31. (Szo), 07.45
Ha már szóba került az Oracle:

https://www.oracle.com/database/technologies/spatialandgraph.html

Nem tudom, hogy ez arról szól-e, amire gondolsz, sosem volt dolgom vele, csak emlékeztem, hogy valami gráfokkal kapcsolatos borzalom is volt a doksiban. :)
40

"Nem igazán értek egyet a

ydsMo9gx · Nov. 1. (V), 02.19
"Nem igazán értek egyet a megközelítéseddel. Itt nem csak adat tárolásról van szó, hanem lekérdezésekről is, amiknek gyorsnak kell lennie."
Ez nem megközelítés. Az évek során többször is nekifutottam a témának, köztük a MongoDB-hez hasonló dokumentumtáraknak és a gráf-adatbázisoknak is. Már akkoriban is voltak benchmarkok, amikből kiderült, hogy az adatok betöltése, módosítása, lekérdezése, törlése, tehát a CRUD, de más műveletek sem feltétlenül gyorsabbak a NoSQL adatbázis-kezelőkben a legjobb RDBMS-ekhez képest.

A 26. hozzászólásban megadtam két Google keresést, arra válaszként, hogy "Ezen csodálkoznék (konkrétan ha MySQL-ről MongoDB-re), mert az egyik gyors és sok lekérdezésben erős, míg a másik insertben és nagy mennyiségű adat kvázi statikus tárolásában jó.".

Nomármost jellemzően pont az összetett lekérdezések (inner és outer join, feltételek és szűrések stb.) mennek gyorsabban az RDBMS-ekben a NoSQL-ekhez képest, szerintem egyszerűen a query optimizerük sokkal fejlettebb. És (például) a gráfkezelésben sem gyengék, rövid kereséssel ezt találtam:
arangodb.com/2018/02/nosql-performance-benchmark-2018-mongodb-postgresql-orientdb-neo4j-arangodb/

Mindezek ellenére könnyen találhatsz olyan NoSQL-eket, amelyek egyes műveletekben nagyságrendeket (10×, 100×, 1000× stb.) vernek mindenki másra (benchmarkokban). Mert ezekre hegyezték ki őket, olykor akár adatbiztonságra való tekintet nélkül (mert az kevésbé fontos volt). Ha arra a célra keresel megoldást, akkor lehet, hogy nincs is más választási lehetőséged. De amit a MongoDB és a gráf-adatbázisok nyújtanak, arra ma már a PostgreSQL és a MySQL is képes, legrosszabb esetben erősebb hardvert kell adni nekik. Jobban jársz így, mint újabb elemmel bővítve a rendszerelemek egyre bővülő halmazát.

A jövő útja szerintem egyértelműen az, hogy kevés kivétellel a NoSQL-ek képességeit lemásolják az RDBMS-ek, és a NoSQL-ek (attól a kevés kivételtől eltekintve) megmaradnak a kísérletezés terepének.
41

Én ebben nem hiszek,

BlaZe · Nov. 1. (V), 02.53
Én ebben nem hiszek, alapvetően másra való egy RDBMS és egy NoSQL. Egy NoSQL (attól függ melyik persze) megteheti azt, hogy eldobja a konzisztenciát a sebesség, vagy elérhetőség kedvéért. Egy klasszikus RDBMS ilyet nem tehet. Szintén megteheti, hogy speciális elosztott adatszerkezeteket implementáljon, amik nem férnek bele az RDBMS-ek világába. Egy Redis, vagy egyéb in-memory cuccok pl ezeket előszerettel megteszik, és ezért (is) sebességben nagyságrendeket vernek egy RDBMS-re. Szintén alapvetően más egy time-series database stb. Viszont másra is valók ugyebár, és sokuk valójában nem is adatbázis (ahhoz, hogy a Redist adatbázisnak hívjuk kell egy elég erős jóindulat, bár tudom, ők szeretik magukat annak nevezni :))

Abban viszont egyetértek, hogy az RDBMS-ek maradni fognak, és első helyen, mert sziklaszilárd elméleti és gyakorlati alapokon nyugvó "szinte mindenre jó" eszközök, és a hardware-ek fejlődésével a teljesítményük is eléggé rendben van. Főleg rendben lesz, ha lesznek Optane-re optimalizált RDBMS-ek (illetve azok tárolói).

Ami viszont érdekes lesz, hogy a mindenféle elosztott tárolók egyre jobb elosztott SQL képességekkel rendelkeznek. Itt van a streaming SQL is. Ilyen szempontból egyre nagyobb lesz az átfedés.
43

Itt a lényeg

Pepita · Nov. 2. (H), 14.38
Én ebben nem hiszek, alapvetően másra való egy RDBMS és egy NoSQL. Egy NoSQL (attól függ melyik persze) megteheti azt, hogy eldobja a konzisztenciát a sebesség, vagy elérhetőség kedvéért.
Egyetértek, kb erre próbáltam rávilágítani a MySql - MongoDB különbségnél.
ahhoz, hogy a Redist adatbázisnak hívjuk kell egy elég erős jóindulat
A "jóindulat" kimondottan tetszik. :)
42

Erről a benchmarkról csak

inf · Nov. 1. (V), 19.03
Erről a benchmarkról csak pont a lényeg maradt le, pl valaki shortest path miatt használhat gráf adatbázist: ref Elvileg kerülőúton ez is beletákolható postgres-be: ref. Kérdés, hogy megéri e ezzel kínlódni, ha egy neo4j-vel triviális összehozni, és valószínűleg jóval gyorsabb is... Igazából nekem nem kérdés.