[Clarence]

Ursprungligen postat av jayzee

Jag måste ha missat något, på vilket sätt menar detta skulle vara extremt viktigt? Hårddiskutrymme och RAM är inte dyrt nuförtiden, speciellt om man pratar om några extra byte per objekt. Att datat tar lite mer plats än om man använde en annan lösning är inget jag skulle bry mig om, speciellt om du får bra bättre prestanda och skalningsmöjligheter än traditionella lösningar.

Så att fördubbla sitt hårdvaruinköp skulle inte vara en stor deal för de flesta? När man väl kommer till nivån där skalbarheten är en utmaning så är det också desto mer pengar i hårdvara det pratas om.

För övrigt får du sämre prestanda, mindre features, svårare att hitta extern expertis, sämre stabilitet än om du använder en mer beprövad lösning där stabilitet och dataintegritet faktiskt är prio 1.

Det du dock får är mycket lättare horisontell skalning. Vilket är trevligt, om du inte är rädd att förlora data, ha nertid eller lägga massa extra pengar på hårdvara.

[jayzee]

Ursprungligen postat av Clarence

Så att fördubbla sitt hårdvaruinköp skulle inte vara en stor deal för de flesta? När man väl kommer till nivån där skalbarheten är en utmaning så är det också desto mer pengar i hårdvara det pratas om.

För övrigt får du sämre prestanda, mindre features, svårare att hitta extern expertis, sämre stabilitet än om du använder en mer beprövad lösning där stabilitet och dataintegritet faktiskt är prio 1.

Det du dock får är mycket lättare horisontell skalning. Vilket är trevligt, om du inte är rädd att förlora data, ha nertid eller lägga massa extra pengar på hårdvara.

Nu pratar du i nattmössan Clarence
"Fördubbla" är att ta i ganska hårt när vi nu pratar några byte/objekt, sen så är priserna på diskarna på väg ner igen och utrymmet per disk ökar. För att vara helt ärlig har jag aldrig någonsin fyllt upp mina diskar på någon av mina servrar, tittar jag ligger användningen på max ca. 50% - så det är inget problem, iaf. för mig.

Ang. prestanda, vi bytte nyligen från Percona Server 5.5 till mongoDB i ett av större projekten och jag kan säga att prestandan är bra mycket bättre och att programmera OOP mot mongoDB är en dröm i jämförelse med PDO, mysqli & co. Dataintegriteten och stabiliteten har vi inte haft några som helst problem med och jag är väldigt positivt överraskad av atomiska operationerna.

Ursprungligen postat av Adestro

För övrigt kan det vara värt att känna till att MongoDB saknar en ordentlig full-text sökfunktion. Vad gäller prestanda så cachar ju InnoDB data i primärminnet, så om RAM-cache är det enda skälet till att man går igång på MongoDB kan man lugna ner sig.

Jag har _aldrig_ någonsin sökt fulltext direkt i SQL, det jobbet har jag min Sphinx server för och så kommer det förbli. Även om InnoDB-motorn cachar data i RAM så är den långsammare än mongoDB som kör med minnes-mappade filer.

Jag vill klargöra att jag inte på något sätt pushar för ena gentemot det andra, mySQL har sina fördelar och mongoDB har andra - det är upp till var och en att bestämma vilken lösning som passar en bäst för specifik ändamål.

[Adestro]

Ursprungligen postat av jayzee

Ang. prestanda, vi bytte nyligen från Percona Server 5.5 till mongoDB i ett av större projekten och jag kan säga att prestandan är bra mycket bättre och att programmera OOP mot mongoDB är en dröm i jämförelse med PDO, mysqli & co. Dataintegriteten och stabiliteten har vi inte haft några som helst problem med och jag är väldigt positivt överraskad av atomiska operationerna.

Vilka datamängder rör det sig om? Hur presterar MongoDB när databasen inte längre ryms i primärminnet?

[jayzee]

Ursprungligen postat av Adestro

Vilka datamängder rör det sig om? Hur presterar MongoDB när databasen inte längre ryms i primärminnet?

Databasen ligger på ca. 3Gb vilket är ganska stort, servern har dock 48Gb RAM så några problem med att databasen inte ryms i minnet lär vi inte stöta på ett bra tag.

Vill man undvika problem som Foursquare tidigare stött på kan man förallokera fält, dvs. tror man att man kommer lägga till 14.000 entries i ett dokument skapar man 14.000 entries med 0 som värde. Oreilly's senaste "PHP & mongoDB" bok förklarar mer ingående hur man undviker sådana fallgropar, rekommenderas varmt.

[Clarence]

Ursprungligen postat av jayzee

Nu pratar du i nattmössan Clarence
"Fördubbla" är att ta i ganska hårt när vi nu pratar några byte/objekt, sen så är priserna på diskarna på väg ner igen och utrymmet per disk ökar. För att vara helt ärlig har jag aldrig någonsin fyllt upp mina diskar på någon av mina servrar, tittar jag ligger användningen på max ca. 50% - så det är inget problem, iaf. för mig.

Ang. prestanda, vi bytte nyligen från Percona Server 5.5 till mongoDB i ett av större projekten och jag kan säga att prestandan är bra mycket bättre och att programmera OOP mot mongoDB är en dröm i jämförelse med PDO, mysqli & co. Dataintegriteten och stabiliteten har vi inte haft några som helst problem med och jag är väldigt positivt överraskad av atomiska operationerna

Jag har prestanda-testat ett par databaser som redan i MySQL har en dokument-lik struktur pga dess denormalisering och fått helt annorlunda resultat. Minnet räckte inte till varken med innodb eller mongodb då databasen är ca 60gb och med mongodb hamnade den väl över 100gb.

Sen var det svårt att utnyttja all CPU trots att svarstiderna steg rejält trots tillräckligt med minne för att bli CPU-bound. Sedan har QPS:en alltid legat ca 50% lägre. Största problemet är förmodligen att jag inte försökte sätta upp en instans per CPU core då det var tungt med writes och reads. Men då kommer man dit igen, mongodb ska vara lätt att skala. Men tungt med både write och read gör det svårt att skala vertikalt vilket nu för tiden är väldigt lätt att göra med innodb.

Angående data-integrtiteten finns det knappt möjligheter att upptäcka problemen. Dels det grundläggande att du helt saknar constraints utöver unika index. Men sedan att disk-skrivningen kanske inte sker alls och det saknas information om varför eftersom den inte kör någon integritetskontroll, journalling eller fsync - det finns ingen som helst skyddsmekanism som de klassika databas-systemen har överflöd av. Hell, ett elavbrott kan korrumpera din databas så att den inte ens går att reparera med lite otur, med tur förlorar du bara 100 random inserts i ditt kluster. Back to backup.

Jag vill inte säga att mongodb är ett dåligt val. Det finns dock väldigt många nackdelar som man bör vara medveten om - om man väljer det som en primär databas för ett större projekt.

[jayzee]

Ursprungligen postat av Clarence

Angående data-integrtiteten finns det knappt möjligheter att upptäcka problemen. Dels det grundläggande att du helt saknar constraints utöver unika index. Men sedan att disk-skrivningen kanske inte sker alls och det saknas information om varför eftersom den inte kör någon integritetskontroll, journalling eller fsync - det finns ingen som helst skyddsmekanism som de klassika databas-systemen har överflöd av.

"MongoDB v1.7.5+ supports write-ahead journaling of operations to facilitate fast crash recovery and durability in the storage engine."
Källa: http://www.mongodb.org/display/DOCS/Journaling

Just saying...

[Clarence]

Ursprungligen postat av jayzee

"MongoDB v1.7.5+ supports write-ahead journaling of operations to facilitate fast crash recovery and durability in the storage engine."
Källa: http://www.mongodb.org/display/DOCS/Journaling

Just saying...

Riktigt positivt att de gör något åt sina brister, hade jag inte sett. Fast det förändrar inget för mig förräns den kommit med i stable och testats ordentligt under något år.

[jayzee]

Senaste stable är 2.0.2, ändringen tillkom i 1.7.5 för mer än ett år sedan, nur får du fasen i mig vakna Calarence.

[abergman]

Ursprungligen postat av Clarence

Jag har prestanda-testat ett par databaser som redan i MySQL har en dokument-lik struktur pga dess denormalisering och fått helt annorlunda resultat. Minnet räckte inte till varken med innodb eller mongodb då databasen är ca 60gb och med mongodb hamnade den väl över 100gb.

Sen var det svårt att utnyttja all CPU trots att svarstiderna steg rejält trots tillräckligt med minne för att bli CPU-bound. Sedan har QPS:en alltid legat ca 50% lägre. Största problemet är förmodligen att jag inte försökte sätta upp en instans per CPU core då det var tungt med writes och reads. Men då kommer man dit igen, mongodb ska vara lätt att skala. Men tungt med både write och read gör det svårt att skala vertikalt vilket nu för tiden är väldigt lätt att göra med innodb.

Angående data-integrtiteten finns det knappt möjligheter att upptäcka problemen. Dels det grundläggande att du helt saknar constraints utöver unika index. Men sedan att disk-skrivningen kanske inte sker alls och det saknas information om varför eftersom den inte kör någon integritetskontroll, journalling eller fsync - det finns ingen som helst skyddsmekanism som de klassika databas-systemen har överflöd av. Hell, ett elavbrott kan korrumpera din databas så att den inte ens går att reparera med lite otur, med tur förlorar du bara 100 random inserts i ditt kluster. Back to backup.

Jag vill inte säga att mongodb är ett dåligt val. Det finns dock väldigt många nackdelar som man bör vara medveten om - om man väljer det som en primär databas för ett större projekt.

Konstigt att du hade så stora problem med MySQL.. om det är tungt med read/write, vad körde/kör du för disksystem?

[Clarence]

Ursprungligen postat av abergman

Konstigt att du hade så stora problem med MySQL.. om det är tungt med read/write, vad körde/kör du för disksystem?

Tvärtom, det var ett test för att se hur mongodb skulle prestera.