HOVD 2015 - Kedvenc adatbázis-kezelő

HUP

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

( saxus | 2015. 12. 15., k – 10:35 )

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

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

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.

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."

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.

"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

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-peta…

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.

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....

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

( Pene | 2015. 12. 15., k – 10:45 )

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

( uid_720 | 2015. 12. 15., k – 11:10 )

Hajrá PostgreSQL!

Fuszenecker Róbert

( x-daemon | 2015. 12. 17., cs – 08:19 )

firebird-et ismeri valaki? van valakinek rola barmilyen velemenye? 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.

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!

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-…

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.

( freeoli v | 2015. 12. 17., cs – 09:53 )

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

( toshi_sanyoshi | 2015. 12. 18., p – 20:58 )

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...

( kisauto | 2015. 12. 21., h – 10:50 )

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