NoSQL vs. SQL

[piemel]

Hallo,

ik ben me de laatste maanden wat meer aan het verdiepen in document-oriented databases. Vooral mongoDB en couchDB trekken wel mijn aandacht.


Onlangs kwam ik op internet een presentatie tegen van openSky, waarin ze in het kort uitlegden hoe ze een document-oriented database (mongoDB in hun geval) combineerden met MySQL. Ik was al langer overtuigd van het nut van een document georiënteerde database, maar ik wist niet dat dat een interessante toepassing was (het gebruik van mongoDB om producten op te slaan).

Nu vroeg ik mij af, of het zo onder de freelance webontwikkelaars en de (kleine) webbedrijven hier in België al zo wat ingeburgerd is? Een vraag dus naar de webbouwers: maken jullie al gebruik van een noSQL database (en dan vooral van een document-oriented database)?

Omdat ik de prefix "discussie" heb en niet opnieuw een infraction wil: ook dus maar even een algemene vraag: zijn er al veel onder jullie bekend met bv. couchDB, mongoDB, cassandra, ... whatever van document-oriented database software, en wat zijn voor jullie de voordelen/nadelen? En eventueel ook: hoe, en voor wat type van applicaties, gebruiken jullie het?

[Cycloon]

Algemene indruk die ik heb is dat de meesten enkel nog maar over RDBMS hebben gehoord. Al de rest is hun vreemd. Wat de boer niet kent eet hij niet. Ik moet de eerste gemiddelde webontwikkelaar nog tegenkomen die geen MySQL gebruikt bijvoorbeeld. Opleidingen focussen ook teveel op RDBMS en vertellen vaak zelf niks over de alternatieven.

Ik ben vorig jaar zelf met een object-databank beginnen werken (die wel een SQL layer heeft, which I like, zo heb je voordelen van beide werelden) en ik zie me niet snel teruggrijpen naar de zuivere RDBMS eigenlijk. Eénmaal je de voordelen hebt ingezien kan je het niet meer naast je neerleggen.

[piemel]

Algemene indruk die ik heb is dat de meesten enkel nog maar over RDBMS hebben gehoord. Al de rest is hun vreemd. Wat de boer niet kent eet hij niet. Ik moet de eerste gemiddelde webontwikkelaar nog tegenkomen die geen MySQL gebruikt bijvoorbeeld. Opleidingen focussen ook teveel op RDBMS en vertellen vaak zelf niks over de alternatieven.

Maar bv. webbedrijven zoals inventis... die moeten dat toch kennen? of is dat ook steeds mysql?

Ik ben vorig jaar zelf met een object-databank beginnen werken (die wel een SQL layer heeft, which I like, zo heb je voordelen van beide werelden) en ik zie me niet snel teruggrijpen naar de zuivere RDBMS eigenlijk. Eénmaal je de voordelen hebt ingezien kan je het niet meer naast je neerleggen.

En welke is dat als ik vragen mag? ik ken alleen zope.

[Cycloon]

En welke is dat als ik vragen mag? ik ken alleen zope.

InterSystems Caché - World's fastest high performance object database

Het is wel een commercieel pakket die vrij prijzig is. Dus niet zomaar iets dat je voor een kleine website gaat gebruiken. Onder andere ESA en de federale politie maken gebruik van dit pakket en er zijn nog wel enkele grote namen.

[Disa]

Voor een project waarvan verwacht werd dat het moest schalen van enkele 100'en users tot 200.000 user waarbij iedere user een content producer is hebben wij een aantal dingen geprobeerd. De snelheidswinsten die systemen zoals Cassandra of MongoDB geven zijn soms echt wel groot. Maar databases zoals Postgres, MySQL of Oracle zijn dan ook veel en veel uitgebreider en bieden een pak meer functionaliteit aan.

Het hangt allemaal af van je projecteisen en persoonlijke voorkeur voor welk soort database je kiest. Probeer er een aantal zou ik zeggen.

Persoonlijk heb ik nog nooit van InterSystems Caché gehoord en claimen dat ze de snelste zijn is nogal erhm .. belachelijk? Ieder systeem heeft zijn use-case..

[piemel]

De snelheidswinsten die systemen zoals Cassandra of MongoDB geven zijn soms echt wel groot. Maar databases zoals Postgres, MySQL of Oracle zijn dan ook veel en veel uitgebreider en bieden een pak meer functionaliteit aan.

Bij een user-systeem komt het erop neer zo'n systemen goed te combineren.

Als ge een document-oriented database hebt gebruikt om een user-systeem te maken, dat lijkt mij niet de beste oplossing... itt tot gegevens van users (gewone data), die kan dan wel in zoiets worden opgeslagen.


Dit is mijn mening natuurlijk, anderen kunnen daarvan verschillen. Ik weet gewoon één regel (van internet): "never trust data that's in a document-oriented database".

[dJeez]

Ik ben vorig jaar zelf met een object-databank beginnen werken (die wel een SQL layer heeft, which I like, zo heb je voordelen van beide werelden) en ik zie me niet snel teruggrijpen naar de zuivere RDBMS eigenlijk. Eénmaal je de voordelen hebt ingezien kan je het niet meer naast je neerleggen.

Heb je dan nooit met een ORM layer gewerkt? Want uiteindelijk vergemakkelijkt dat ook wel het werken met je DB als je OO programmatie gebruikt. Queries schrijf je dan ook nog zelden (je DB benader je via fluent interfaces). Of het qua performantie even snel is als Caché zou ik niet weten (ik vermoed wel dat het iets trager zal zijn gezien de vertaalslag naar het RDBMS die nodig is), heb zelf nog nooit - buiten eens een enkel testje, maar da's al heel lang geleden - met een pure OODB gewerkt.

Wat NoSQL betreft : ik heb al wat met MongoDB liggen experimenteren, en zie er wel voordelen van in (vooral bij quasi pure key-value stores, vb. pagina's binnen een CMS). Maar je moet ze dan ook gaan gebruiken waarvoor ze bedoeld zijn, dus niet als zuiver alternatief voor een RDBMS (want dat zijn ze niet). Als je Lucene ook tot NoSQL rekent, daar heb ik al wat ervaring mee, vooral in combinatie met Solr (faceted searching is enorm simpel dan ). In september (allez, als onze Duitse vrienden erin slagen van hun data terug correct consulteerbaar te maken) gaat er een (Drupal) site live waar we het op gebruiken.

[piemel]

Wat NoSQL betreft : ik heb al wat met MongoDB liggen experimenteren, en zie er wel voordelen van in (vooral bij quasi pure key-value stores, vb. pagina's binnen een CMS). Maar je moet ze dan ook gaan gebruiken waarvoor ze bedoeld zijn, dus niet als zuiver alternatief voor een RDBMS (want dat zijn ze niet).

Inderdaad. Ik zag dus een presentatie van opensky: zij gebruiken mongoDB voor de productinformatie enzo in op te slaan, en MySQL voor order- en usergegevens in op te slaan.

Het lijkt mij het verstandigste om gewoon de twee te combineren in zo'n geval, gelijk zij ook doen.

EDIT: @djeez: wat is eigenlijk het verschil tussen lucene en sphinx? ik heb ooit sphinx gebruikt omdat dat compatibel was met MySQL. Lucene weet ik niet .

[dJeez]

EDIT: @djeez: wat is eigenlijk het verschil tussen lucene en sphinx? ik heb ooit sphinx gebruikt omdat dat compatibel was met MySQL. Lucene weet ik niet .

Sphinx is gewoon een full text search server, maar ook niet veel meer dan dat. Lucene is document oriented storage (waarbij je verschillende types van documenten - waarbij een document is een geheel van verschillende velden is - in 1 store kan steken, maw het is schemaless net zoals NoSQL), die specifiek geoptimaliseerd is voor gebruik als search engine. Daarnaast kan je bij Lucene ook andere dingen indexeren (zoals PDF, Word, Excel en andere documenten) dan databases, wat het ook weer een breder spectrum qua gebruik geeft. De drempel ligt misschien wel iets hoger (zeker bij de combinatie Lucene/Solr), maar eens je die hebt genomen wil je niet meer terug - het is gewoon bliksemsnel .

Indexeren doe je wel best met de Java implementatie van Lucene, maar om de Lucene store te consulteren (als je geen gebruik maakt van Solr) kan je perfect de Zend_Search_Lucene classes van het Zend framework gebruiken (indexeren daarmee is echter tergend traag als je het vergelijkt met de Java implementatie, het is echter wel doenbaar voor vrij statische content zoals pagina's indexeren voor een CMS vb.).

[piemel]

ah ok, sphinx is gewoon een "layer" tussen een query met daarin fulltext search dingen, en MySQL dan. (??) Allez ja, zo heb ik het toch gebruikt .

Zend_Search_Lucine: ik gebruik geen zend framework (nooit gedaan). De moeite om het aan te leren? (waarschijnlijk wel). Ik programmeer zelf meestal gewoon de site "from scratch", OOP (MVC pattern). Ik veronderstel dat het zend framework ook een soort van MVC-pattern aanhoudt? of ben ik hier fout in?

[dJeez]

Het Zend Framework gebruikt ook MVC ja, hoewel het eerder als library is opgebouwd. Je kan dus perfect in om 't even welke applicatie gebruik maken van die delen (componenten) van het framework die je nodig hebt, en de rest links laten liggen. Maar het volledige framework leren is zeer zeker de moeite, eens je het doorhebt ga je het wel weten te appreciëren (en kan je zeer snel dingen ontwikkelen), zeker als je het combineert met een ORM layer als Propel of Doctrine . De ZF2 wiki (Home - Zend Framework 2.0 - Zend Framework Wiki) is nog niet zo lang geleden gelanceerd trouwens, die heb ik nog niet bekeken om na te gaan wat de wijzigingen precies zijn.

[Cycloon]

Heb je dan nooit met een ORM layer gewerkt? Want uiteindelijk vergemakkelijkt dat ook wel het werken met je DB als je OO programmatie gebruikt. Queries schrijf je dan ook nog zelden (je DB benader je via fluent interfaces). Of het qua performantie even snel is als Caché zou ik niet weten (ik vermoed wel dat het iets trager zal zijn gezien de vertaalslag naar het RDBMS die nodig is), heb zelf nog nooit - buiten eens een enkel testje, maar da's al heel lang geleden - met een pure OODB gewerkt.

Ik heb uiteraard al met ORM frameworks gewerkt. Ik ben iemand die zeer graag experimenteert met alles. Maar ORM is een pleister op de wonde. Deze discussie is ook al eens gevoerd in het programmeerforum hieronder.

Persoonlijk heb ik nog nooit van InterSystems Caché gehoord en claimen dat ze de snelste zijn is nogal erhm .. belachelijk? Ieder systeem heeft zijn use-case..

Ze claimen zelf dat ze de snelste zijn, maar we zijn er zelf wel bewust van dat dit in sommige use cases zeker niet zo is. Dat hebben we zelf al genoeg ondervonden . Maar ik vermoed dat ze dat claimen omdat ze één van de weinige object databanken zijn die zo goed zijn uitgewerkt (al is er nog steeds ruimte voor veel verbetering).

Maar ik wil hier geen propaganda voeren voor caché. Er zijn genoeg RDBMS alternatieven en ik raad iedereen aan om er met te experimenteren.

[Drone]

Eerste die ik gebruikt hebt is MongoDB. Daarna heb ik Datastore van GAE eens gebruikt en nu ben ik bezig met CouchDB.

MongoDB is niet slecht maar is eigenlijk enkel een database zonder veel extra. Als je naar CouchDB of Riak kijkt dan heb je een database die ook apps kan serven.

Redis is ook interessant omdat het zo snel is wat het ideaal maakt om dingen te sharen tussen verschillende onderdelen. Bijvoorbeeld een PHP website die iets bewaard in redis terwijl je een Node.js server hebt die die database in het oog houd en zodra er iets bijkomt een actie uitvoert. Op die manier moet de front-end gebruiker niet te lang wachten en heb je een losgekoppeld systeem waar iedereen kan op subscriben.

Paar weken geleden ook wat zitten lezen over Elastic Search. Op het eerste zicht een search engine/indexer als Lucene maar er is ook integratie met CouchDB zodat je je data niet verliest. Je kan het dus gebruiken als database met als grote voordeel dat er een search engine aanhangt.

Wat ook opvalt is dat er veel Javascript wordt gebruikt en daarom hoort je ook geregeld dat er binnen 5 jaar enkel nog met Javascript zal gewerkt worden. Op de client heb je enkel toegang tot Javascript. Node.js is al een tijdje een hype als het over server-side platforms gaat en NoSql gebruikt meestal Javascript om queries te doen en Json om data op te slagen.