HOVD 2015 - Kedvenc adatbázis-kezelő

 ( trey | 2016. január 7., csütörtök - 16:42 )
amazon dynamodb
1% (5 szavazat)
apache derby, java db, h2, cassandra
2% (17 szavazat)
db2
2% (18 szavazat)
mariadb, mysql, percona server
48% (403 szavazat)
microsoft sql server
5% (40 szavazat)
mongodb
4% (33 szavazat)
oracle
5% (43 szavazat)
postgresql
25% (213 szavazat)
solr, elastic search
1% (12 szavazat)
sqlite
7% (57 szavazat)
Összes szavazat: 841

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Akinek az Oracle a kedvence, mondja már el, hogy miért...

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

... vagy a MySQL, de idén ne is kezdjünk bele ebbe a vitába. :)

Akkor most én is szavaztam egyet a MySQL-re :p

A fentiek közül 6-7-et használtam éles projektben. Mindegyiknek megvan az a tulajdonsága, amiért szeretni lehet (kicsi, olcsó, egyszerű, könnyű felrakni, könnyű használni, gyors, nagy tudású, ...) és amiért utálni is (nagy, drága, bonyolult, nehéz beállítani, nehéz használni, lassú, keveset tud, ...).

Akkor szokott baj lenni, ha nem jól van választva a feladathoz az eszköz, vagy nem jól használják, vagy nem ismerik eléggé.
Régebben pl. egy Oracle felinstallálása és beállítása nem éppen a kedvenc programunk volt. Viszont, ha ezt más megcsinálja, üzemelteti és kicsengeti érte a sok pénzt, akkor egész jó használni :)

Jobban el tudom fogadni, hogy 5%-nak volt olyan jo tapasztalata az Oracle supporttal, hogy pillanatok alatt ugy megoldottak egy bonyolult kerdezt nekik hogy csak neztek hogy "jeee, ez az rdbms ilyen okos"? Geleihez hasonloan nekem is inkabb a kozel 50% MySQL faj. Meg a mongodb szavazatat is tul soknak tartom a DynamoDB-hez es a Solr-hoz kepest, ugyanis utobbi kettonek van is eppen ertelme, par esetben ugy skalazodik, hogy igy outperforms SQL badly. Mongo viszont egyaltalan nem is gyors,de legalabb 3x akkora es meg csak nem is konzisztens.

Lehet, de erre lennék kíváncsi.

MySQL-t meg hagyjuk...

MongoDB meg szerintem hasonló eset, mint a MySQL: Felkapta a hype, sokan meg meg se nézték, hogy milyen alternatívák vannak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Lehet pont azert lett a MongoDB, mert akik irtak, azok is csak a MySQL-t ismertek :D :D De tenyleg erthetetlen a hype korulotte muszakilag jobban ranezve.

Mi a baj vele műszakilag?

Az hogy nem arra találták ki, amire használni szeretnék? ;)

Hát igen, ha relációs adatbázisként akarná valaki használni, akkor arra műszakilag nagyon nem alkalmas :)

http://mongoosejs.com/

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szerintem nincs ezzel semmi baj. Ez nem ORM, hanem az, aminek mondja magát: "Elegant MongoDB object modeling".

Sokan összekeverik a sémamentességet azzal, hogy az objektumaidnak van-e sámája. A kettő nem ugyanaz, a mongoose egy - opcionálisan - sémamentes db-be tesz objektumokat, viszont a te szoftveredben ezeknek az objektumoknak (ami pl. egy osztály példányai) igenis van sémája: maga az osztály.

Teljesen igazad van, amit mondasz.

en erre reagaltam:
"relációs adatbázisként akarná valaki használni, akkor arra műszakilag nagyon nem alkalmas :)"

A relacios adatbazis egyik fo ismerve, hogy az adatok tablaban vannak es az oszlopok megadjak a tarolt adat mezoit (sorait).

A mongoose pontosan ezt csinalja az egyebkent szabadformatumu MongoDB adatbazissal.

Tehat amennyiben enpassant emiatt nem gondolja alkalmasnak a MongoDB hasznalatat, akkor van ra megoldas.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Nem arra gondoltam, hogy nem lehet úgy használni, hanem arra, hogy arra nem alkalmas. Sokkal rosszabb lesz a teljesítménye, mint egy hasonlóan felépített relációs adatbázisnak.
Pl. egy rendelés összes adata (rendelés sorok, kedvezmények, vevő adatai, ...) egy dokumentumban van tárolva versus a relációs tárolással, ahol ezek az információk szét vannak dobva 10 táblába.

Nagyjabol az, hogy 2-3x lassabb mint Postgres es 2.5x annyi byte-ot tarol azonos adatra, es semmiben sem skalazodik jobban (ellentetben solr-ral vagy dynamodb-vel vagy hadooppal, azok olyan nosql-ek, amiknek ertelme is van bizonyos adatmennyiseg folott). Replikalni konnyebb a MongoDB-t mondjuk (ok ezt "horizontalis skalazhatosagnak" becezik, hogy szebbnek hangozzon), meg a semamentesseg (kevesbe szigoru adatszerkezet) elony lehet nehol, ahol nem kell konzisztens adat annyira, de ez utobbira sokkal alkalmasabb az orientdb vagy a neo4j (graph adatbazisok) megfeleloen menedzselve. Sima key-value storage-nak meg a Redis sokkal gyorsabb, szoval arra se jo.

Szoval nincs jelenleg az a feladat, amire barmilyen muszaki ok miatt MongoDB-t hasznalnek.

Ha nem tudod, hogy egy eszköz mire való és hogyan kell használni, akkor valóban nem jó.
Ha egy dokumentum alapú NoSql adatbázis kezelőt relációs adatbázisként; key-value vagy gráf alapú NoSql adatbázisként akarod használni, akkor siralmas eredményt kapsz, ez igaz.

"Replikalni konnyebb a MongoDB-t mondjuk (ok ezt "horizontalis skalazhatosagnak" becezik, hogy szebbnek hangozzon)">
Nem, ez a kettő egész más. Kb. az a különbség, mint a Raid 0 és 1 között.

Akkor mondj egy feladatot, amiben verhetetlen a MongoDB barmely mas SQL es NoSQL-lel szemben performance-ban. Pelda adatszerkezet a legjobb talan. Mi az, amire a document database jo egyaltalan es nem jo ra semmi mas, ami jol is performal? Altalaban ugyanis akik a document db-vel jonnek, meg a semamentesseggel, azokrol hamar ki szokott derulni, hogy csak nem ertettek meg meg a graphdb-ket (ami tenyleg nem egyszeru, de sokkal alkalmasabb erre a celra, mint a documentdb, es jobban performalo implementacioi is vannak, es meg konzisztensebb is, ha jol hasznalja a csapat).

"Independent evaluators United Software Associates released new research based on Yahoo! Cloud Serving Benchmark (YCSB) demonstrating that MongoDB overwhelmingly outperforms key value stores. The results show that MongoDB provides greater scalability than NoSQL vendors Cassandra and Couchbase in all tests, by as much as 13x."

Itt letölthető a White Paper

A cassandra meg a couchbase mindketto hiresen lassu, johogynem firebirdhoz hasonlitottak mar. Azokat nem nehez elverni. Verje el a redist vagy az orientdb-t vagy a neo4j-t vagy a hadoopot vagy a solr-t (vagy elobb a postgrest, bar arra ugyis csak azzal jottok, hogy "de hat ne hasonlits mar SQL-t NoSQL-hez!!!!!11!11"). Hint: nem fogja. Egyiket sem. Lassabb mindnel es rosszabbul is skalazodik, meg egy SQL standardok limitacioit mind megtarto PostgreSQL-nel is rosszabbul skalazodik. Pedig a NoSQL-ek lenyege alapjaraton az lenne, hogy sebessegert es big data skalazodasert ezekrol lemondhatsz.

Ember, szerintem ne dobálózz olyan szavakkal, amiről azt se tudod micsoda, nem áll jól. Solr egy search engine, Redis egy in memory key value store, ami képes perzisztálni (ettől függetlenül folyton mindent a memóriában tart), a hadoop pedig egy distributed computing framework (amiben a HDFS fájlrendszertől kezdve minden van). Meg egyáltalán hogy jönnek ide az SQL standard limitációk? Mi köze a lekérdezőnyelvnek az adott DBMS belső tárolási módszereihez, és hogy hogy van megoldva a skálázás?

Fogalmam sincs mi az a big data skálázódás, amiről beszélsz, de manapság már a big data stackekből is lehet SQL-el lekérdezni, és a relációs adatbáziskezelők is támogatják a schemaless működést (dynamic columns).

Hallottam, hogy mongo-t Hbase -re csereltek skalazodasi okokbol.
HBase "hadoop database" -nek van mondva, consistenciat iger, hadoop -tol fuggetlenul hasznalhato.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"Hallottam, hogy mongo-t Hbase -re csereltek skalazodasi okokbol."

Ez jelentheti azt, hogy jobban skálázódik a Hbase, de azt is, hogy egyszerűen csak rosszul használták. Ezt a konkrét eset ismeretében lehetne megmondani.

A szigorú konzisztencia (strict consistency) és a horizontális skálázódás nem jól férnek meg egymás mellett.
A Mongo-t lehet eventual consistency módon is használni, ami sokkal jobb skálázódást ígér.

https://youtu.be/LSDuz9qG6ks?t=2073 nem tudom tenyleg 15PB gondolt amikor mondta,
lehet hogy csak 15TB.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

15PB az általános use-case NoSQL esetén... a 15TB az egy-öt node adatmennyisége IOPS függvényében.

3 honapra viszameno 5k fizikai gep, 16k vm metrikainak tarolasara soknak tunik.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a konkrét esetre mondtam, hanem általánosságban. :)

Altalanosagban a mongo keves node szammal, meg a mysql-t sem szokta rendesen megverni (meresi hiba kulonbseg nem szamit :) )


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A 16 meg nagyon kevésnek ;)

16k _k_

CERN nagy vm -eket hasznal ~16GB memoriaval.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

15PB általános...?

Milyen storage van ezalatt amúgy általánosságban? Az "általános" szóval azt is ki akartad fejezni, hogy az átlagos adatmennyiség ebben a nagyságrendben mozog?

"15PB általános...?"

Ahja, NoSQL esetén ilyen PB adatmennyiségek vannak azt a use-case-t tekintve, amire használni szokták; a másik használati eset a földrajzilag elosztott adatbázis, a harmadik a kevés írás, sok olvasás denormalizált adatbázissal.

Szóval ha egy DC van csak, akkor több tucat TB adat alatt értelmetlen a NoSQL, annyit tud kezelni az SQL is.

"Milyen storage van ezalatt amúgy általánosságban?"

Általában a legolcsóbb local storage, amit lehet kapni és még megfelelő a teljesítménye. Ha a hardver egyet köhhint, már dobják az egész node-ot a kukába és húznak fel újabb node-ot, nem gyógyítgatják.

--
https://portal.gacivs.info

"több tucat TB adat alatt értelmetlen a NoSQL"

Mi peldaul nem a teljesitmeny miatt hasznalunk Mongot (par gigabajt az egesz db), hanem mert sokkal kenyelmesebb benne az altalunk hasznalt adatok tarolasa, mint egy relacios adatbazisban. Ez is egy szempont.

Szóval azt állítod, ez az _ÁLTALÁNOS_.

Értem.

Ahja. Azt.

Pár tucat TB alatt vagy csak divat a NoSQL, vagy elosztott és replikált adatbázisra van szükség vagy valami speciális tulajdonságát használják ki (document, no scheme, graph, és a többi).

--
https://portal.gacivs.info

Jo par TB adat vagy millios nagysegrendu felhasznalo nelkul, manapsag nincs sok elet :(


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Megértettem, nem kell túlmagyarázni, ez az általános, pont.

Nem mondta rosszul, tényleg tárolnak ennyit, csak nem mindet tartják meg 3 hónapnál hosszabb távon. Kielemzik, aztán csókolom, a haszontalan megy a levesbe, a hasznost meg szalagra archiválják.
Két éves cikk: http://home.cern/about/updates/2013/02/cern-data-centre-passes-100-petabytes

Szerk.: Amúgy olyan 2:30-nál említi a fószer, hogy 22ms-re vannak a Wignertől :)
Meg utána 3:00-nál van egy kép a node-ok számáról.

100 PB meresi adatok mellett eleg valoszinutlen, hogy 15 PB futna `graphite` diagramokra, a szerverek CPU meg hasonlo hasznalatarol. Koztudottan sok mindnet monitoriznak, de azert mindennek meg van a hatara :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ennyire már nem vagyok képben a témában, hogy még ezt is kiegészíthessem, de láttam egy diát, amin az szerepelt, hogy 120 PB-nyi szalagos és 110 PB-nyi szokványos tárolójuk van. Mindenesetre az biztos, hogy többször ennyit is meg tudnának tölteni :)

Ezt nem értem miért nekem írod.

Mester, ezek teljesen más célra való eszközök, nem is lehet összevetni őket: a Redis egy kicsit okosabb cache; az OrientDB egy graph adatbázis, a Neo4J szintén; a Hadoop egy elemzőeszköz, ami alá be lehet kötni mindenféle adatbázist; a Solr egy keresőmotor; a PostgreSQL pedig SQL és egy csomó plugin.

Mutatnál példát arra, hogy kell PostgreSQL-t mondjuk három földrészen replikálni és partícionálni táblákat külön-külön? Ha megvan, akkor létrehozok egy ilyen PostgreSQL konfigurációt és mérünk. Mert másfél éve, amikor mértem, akkor az jött ki, hogy a PostgreSQL kényelmetlen, hibatűrése gyakorlatilag nincs, ha kiesik egy DC hálózati hiba miatt, akkor az irgalmatlan szopás, ha a master esik ki, az pláne irgalmatlan szopás, illetve nagyon nehéz különféle konzisztencia szinteket kezelni és a többi apróság (lapozás, tartományok, konzisztencia szintek, stb), ami egy tipikusan NoSQL feladat esetén előkerül.

--
https://portal.gacivs.info

A legjobb megfogalmazás, amit ezzel kapcsolatban olvastam az az, hogy a relációs adatbázisokra tervezésnél az adatszerkezetek és -tárolás van fókuszban, noSQL-nél pedig a lekérdezések (legyen szó document vagy key-value store-ról). Egyszerűen másra való a kettő, viszont egymást jól kiegészítik.

> Szoval nincs jelenleg az a feladat, amire barmilyen muszaki ok miatt MongoDB-t hasznalnek.

Egyeni preferencia, de en emiatt hasznalok MongoDB-t.

Kis programnal TingoDB-t hasznalok:
http://www.tingodb.com/

Ez kb. olyan mint a Mysql<->SQLite kapcsolata. Api szinten kompatibilis a mongodb-ben, de a hatterben egy sima fajlrendszeren tarolo adatbazis.
Ez mehet Raspberry Pi-ra.

Komolyabb dolgoknal (amikor van ket virtualis gepem), akkor egyikre megy a MongoDB masikra a program.

Aztan ha tovabb no a dolog, akkor a MongoDB-t lehet shardolni, es tobb gepre skalazni.
De meg van ugy, hogy ez elott adatbazisonkent vagy collectiononkent kulon MongoDB-ben tarolom.

Szoval szamomra az egeszen kis dolgoktol az igazan nagyig tud megoldast adni.
De felolem mindenki azt hasznal, amit akar:)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Tipp: nem probaltak meg a Postgrest :)

--
Is that a banana in your pocket, or are you just happy to see me?
Neither, it's my new iPhone.

ez van a cegnel ezt kell szeretni :)
illetve van db2 is akkor meg mar inkabb az oracle...

Megbizhatosag, egyszeru adminisztracio es felugyelet. Nem kell "hack"-ni..

Nincs olyan benne, hogy "ja ez nem mukodik, de ha ezt meg ezt feltelepited forrasbol, akkor a kovetkezo verzioig igy kerulheted meg a problemat", valamint "ugyan ezt nem tudja, de az xyz funkcio az nagyon hasonlot tud" (ugye postgres rules).

De mar regen foglalkoztam a temaval, raadasul legutoljara pont postgis-t hasznaltunk, amire egy szavam sem lehet.

Cserébe olyan van benne, hogy "ja, most ezt még nem tudja, majd a következő tudni fogja", aztán a következőnél "ja, most már tudja, de még nem ajánljuk éles környezetben", majd két év múlva "ja, igen, most már lehet éles környezetben is, kivéve ezt a kismillió kivételt, amikor nem ajánljuk"... :)

--
https://portal.gacivs.info

Pl/SQL nekem bejött.

mert ahhoz ért, azzal dolgozik mindennap, a többit meg nem ismeri?

Valahol érthető, simán el tudom képzelni, hogy ha csak az Oracle-t ismerném, akkor se lenne a kedvencem :). Elég sok furcsasága van, főleg PLSQL-ben láttunk elég hülye korlátozásokat.

--

Oh, azt hittem a percona nem lesz végül benne. Zsír :)

Hajrá PostgreSQL!

Fuszenecker Róbert

+1

+1

+1

+1

Remélem mindenki, aki erre szavazott nem fogja le +1 -ezni! ;)

:D

firebird-et ismeri valaki? van valakinek rola barmilyen velemenye? koszi!

Elég régóta használjuk. Kicsi, egyszerű, jó. Konkrétan mire vagy kíváncsi ?

pl. arra hogy technikailag van-e ertelme ezt valasztani mssql helyett.
koszi!

Ha csak adatoot tároltok vele, és ti teszitek bele / ti veszitek ki az adatot, akkor lehet egy jó döntés.

Az MS-SQL nagy előnye, hogy mindenféle business intelligence szoftver van (jár) hozzá, ami nagyon leegyszerűsíti az adatok belapátolását, kimutatások, riportok készítését, elemzések elvégzését.

Fuszenecker Róbert

Attól függ mire használod az mssql-t és miért akarsz helyette mást :)
Amennyiben az mssql-t ismered és elégedett vagy vele akkor nem fog többet nyújtani neked a Firebird.

Röviden Firebirdhez:
+: multiplatform, kicsi, egyszerű, kisebb adatmenyiségnél gyors (nálunk ügyvitelben nincs néhány milliónál több rekord). Többnyire egy fájl egy adatbázis. Ingyenes.
-: Debug, Stored Proc, beépített függvény lehetne több/jobb/kényelmesebb. Bár ezek bővíthetőek ha kell, illetve folyamatosan fejlődik. Kevésbé támogatott különféle nyelvekben/keret és programozási rendszerekben.

> Amennyiben az mssql-t ismered és elégedett vagy vele akkor nem fog többet nyújtani neked a Firebird.

+1, illetve az a kérdés még, hogy elég-e a free tier mssql, vagy ha nem, mennyire vagy árérzékeny

jo lenne ha a free mssql nem csak 1GB memoriat tudna hasznalni, firebird 64 bites rendszerben feltetelezem ki tudja hasznalni a 32GB memoriat ha szukseges.
-mssql: windows szervert kell uzemeltetnem miatta.

tegyuk fel hogy egy uj projekt es e kozott a ketto kozott vacilalok :)
firebirdben van valami olyan mint a profiler? vagy egy olyan tool mint az sql manager studio amivel meg tudom nezni az adatszerkezetet illetve adatokat? le tudok futtatni olyan parancsot ami megnezi hogy nem serultek-e az adatok, konzisztensek-e az adatok?
a tobbit ertettem.
koszi!

Alapból parancssori eszközök vannak.

Itt válogathatsz a grafikusokból is.
https://www.ibphoenix.com/download/tools/

Hallottam / olvastam már több helyen, hogy "kisebb adatmenyiségnél gyors" - szerintem ez - bár nem definiáltad, hogy mi a kisebb adatmennyiség - egy tévhit. Nem csak kis adatmennyiségnél használatos és gyors. Vannak komoly adatbázisok firebird alatt. Az előadásokon az orosz postát és az orosz tőzsdét szokták felhozni a fejlesztők.

Nem régen volt egy ilyen rendezvény is Prágában:
http://www.firebirdsql.org/en/news/firebird-big-databases-free-seminar-in-prague-november-13-2015--73453/

Bár én sem dolgozom terrás adatbázisokkal, de ha az ember érti az sql-t, akkor nagyon jó eredményeket lehet kihozni belőle.

Debug-hoz, sp íráshoz egyértelműen IBExpert. Fizetős, de visszahozza az árát (és nagyon kezes).

Tudok olyan helyről, ahol egy szerveren több tucat 256 (vagy 512) MB RAM-os debian virtuális gépen futnak a firebird-ök és szolgálják ki a különböző cégek backoffice-ait. A másik adatbázis szerver véglet, amin én firebird-öt láttok dolgozni az 24 mag, 64 gb ram.

Bár a fejlesztők Visual Studioban fejlesztik, tapasztalatom (méréseink) szerint linuxon kicsit jobb performancia érhető el vele, ha csúcsra kell járatni a hardvert.

Ha valakinek tényleg fontos a performancia érdemes a tranzakció-kezelésének megértésére egy kis időt fordítani a fejlesztés megkezdése előtt, azzal is lehet nyerni.

És, minimálisra csökkenteni a felesleges disk irást, a forced-write miatt ez fontos lehet.

egyik ugyviteli programunk azt hasznal. (Symbol)
nincs vele semmi gond, alig eszik memoriat, a program is gyors (tehat az adatbazis is vloszinuleg gyors).
igaz szamlazasi adatok vannak benne, de 4-5 evre visszamenoleg, olyan 1-2GB az egesz adatbazis, tehat ilyen forman nem nagy, rekordszam olyan millios nagysagrend lehet.
az egesz adatbazis egy nagy fajl.

egyebkent a firebird a Delphi-fele Interbase leszarmazottja.

Az adatbázis kezelőknél a solr, elastic search egy picit meglepett.

Adat megy bele, es le tudsz kerdezni.

--
|8]

Hát, erre alapvetően a gnu text toolok is alkalmasak, de valahogy mégsem arra valók.

Pedig rengetegen szeretik erre hasznalni. (Pl, logok.)

--
|8]

Az nem jelenti azt, hogy ezekre alkalmasak is. ld. gépi elemzés, összesítés, lekérdezés. Nem a nézegetés az egy pöttyet kevesebb, mint a lekérdezés.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem mondtam, hogy alkalmas, csak hogy hasznaljak ilyen celra is.

--
|8]

Nem szokvanyos elastic search hasznalat:
https://www.elastic.co/blog/elasticsearch-as-a-time-series-data-store


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az "adatbázis-kezelő" véletlenül nem egy helyi vagy kliens menedzser alkalmazás, amivel adatbázis szolgáltatáson vagy szerveren az adatbázist lehet kezelni? Mint például a 'MySQL Workbench' vagy 'LibreOffice.org - Base'? Itt pedig adatbázis típusok és nyelvezetek vannak felsorolva? Egyébként MySQL a kedvenc...

Egyszerűen így terjedt el a köztudatban a DBMS, ami database management system, ami adatbázis kezelő (rendszer).

--
https://portal.gacivs.info - Golden Age of Civilizations

Áh! Hát akkor így élünk (élek) tovább... :-)

én azért megemlíteném a greenplum ot is

(*) Spanner

--

Ez most valami belső Google projekt vagy elérhető publikusan is?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

subs

Alapvetően belső, de van róla publikus paper, és mintha azt meg is valósította volna egy nyílt projekt emlékeim szerint.

--

Mondjuk a paperrel önmagában kitörölhetem... :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

CockroachDB lesz az.

--

FlockDB bekerülhetett volna.