Mennyire vastag a vastag kliens?
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?
■ 
Tinédzser korú emlékeim
Tévedés joga fenntartva.
Itt arról van szó, hogy az
Nem kell
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.
Hát a fazon váltig állította,
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
Hú, így kissé kemény helyzet...
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.
Egyelőre még mindig nem
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.
A "syslog-ng"-t (nem a
Állítólag Balazs Scheidler,
Nem nyert :)
- 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. :)
Ja hát, nem mindig jó kilógni
Attól nem lesz a kliens
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ó.
Attól nem lesz a kliens
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.
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.
Ahol szofisztikáltabb
Én ha nagyon muszáj, akkor
Definíció, filozófia, adatbázisra mit bízzunk, példák, tipp
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.
oracle??
Önmagában az Oracle RDBMS
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!
Bocs, akkor félreértettelek.
Amiket felsoroltál, azokkal szerencsére sosem volt dolgom.
Ha csak ez a kérdés:
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.
Hát azt látom, hogy jó volt
(É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.
Adatbázisba bele lehetőleg
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.
Igen, van lehetőség teszteket
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.
Persze hogy nem
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.
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.
history - audit?
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.
audit
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...
Szerintem félreértesz: azért
Szerintem értelek :). Én azt
Á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.
Ha tudnád, hogy kezdő
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.
"Viszont ez jelentős
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...
Pgp - nem titkosítás, csak
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)
Nem hiszem, hogy paranoia.
IT biztonság a paranoiáról
PGP-t sosem használtam, most
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.
A MySQL-t és a MongoDb-t csak
NoSQL az RDBMS-ekben
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.
Ezt nem értem. Az már húsz
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?
"Az már húsz éve is úgy volt,
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.
Nem igazán értek egyet a
Ha már szóba került az
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. :)
"Nem igazán értek egyet a
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.
Én ebben nem hiszek,
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.
Itt a lényeg
Erről a benchmarkról csak