J'ouvre un topic sur un sujet très à la mode ces temps-ci, les bases de données non relationnelles.
C'est le mouvement du NoSQL ("Not only SQL" ).

L'idée est que les BdD non relationnelles sont plus simples que les SGBD, et permettent en principe d'atteindre des performances plus élevées. D'autres bénéfices importants:
 - les tables sont simplement représentées comme des couples clés-valeurs, avec éventuellement un ou plusieurs index sur les valeurs
 - comme il n'y a pas de schéma, elles peuvent être scalables horizontalement
 - la réplication permet de rendre l'infrastructure plus résistante.

Par ailleurs, certaines n'ont pas les garanties ACID apportées par les SGBD. Evidemment, étant donné leurs limitations, elles ne remplacent pas un SGBD, mais sont plutôt complémentaires, pour des usages spécifiques.
Il n'est pas un secret que nombre de grandes sociétées orientées web (Google en premier) font massivement appel au NoSQL. Mais elles sont de plus en plus utilisées ailleurs pour servir de cache de données en backup de la base principale, qui est généralement un SGBD traditionnel.

Venez ici discuter de vos retours d'expérience sur ces outils.

NB: ce topic n'est pas un topic "pour ou contre le SQL"

Une liste de produits: http://nosql-database.org/

J'ouvre le bal avec Kyoto Cabinet, successeur de Tokyo Cabinet.
 
C'est une simple librairie clefs-valeurs aux performances élevées, qui peut être entièrement en RAM, s'appuyer sur un fichier, ou même sur un système de fichiers. Si celui-ci est distribué, la base peut en profiter. De nombreuses structures de données sont proposées, chacune optimisée pour un type d'application. Il suffit de changer le suffixe du nom de la base pour changer de structure. db.kct est un TreeDB fichier par ex, db.kch est un HashDB.
 
Pour les bases en RAM (à la memcache):
    * time efficiency: CacheDB > StashDB > ProtoHashDB > ProtoTreeDB > GrassDB
    * space efficiency: GrassDB > StashDB > CacheDB > ProtoHashDB > ProtoTreeDB
 
Pour les bases fichier:
    * time efficiency: HashDB > TreeDB > DirDB > ForestDB
    * space efficiency: TreeDB > HashDB > ForestDB > DirDB
 
Il y a un binding pour tous les langages majeurs. Le binding Python est simple bien qu'un peu limité, mais il permet de se servir de KC avec la syntaxe des dictionnaires Python. L'usage en est on ne peut plus simple, ce qui est très attractif.
On peut donc l'utiliser comme une sorte de dictionnaire adossé à un disque de façon transparente, c'est simple et très utile.
Un inconvénient majeur, c'est que la clef et la valeur sont des chaînes de caractères ou des valeurs binaires (au moins en Python). Il faut donc parfois marshaller et unmarshaller les objets, ce qui réduit les performances. L'autre inconvénient est que la base est formée d'un seul fichier qui grossit, et non de plusieurs fichiers. Je pense que ça n'est pas optimal avec pas mal de filesystems.  
J'en parle un peu plus ici.
Les usages évidents de cette librairie sont les caches, le logging, l'indexation, le backup de données.
 
Sur un Core2Duo, le TreeDB en Python les perfs sont excellentes jusqu'à 20 millions d'éléments. Pour le test ci-dessous, le fichier fait alors près de 2Go et la durée des inserts semble croitre exponentiellement avec le nombre d'éléments déjà en base, mais sur moins de 10 millions, la durée est dominée par le marshaling. La durée des retraits est constante.
 
Globalement, c'est un produit comme je les aime: une librairie simple, tout le contraire de l'usine à gaz, qui fait donc relativement peu de choses mais qui les fait bien, et peut donc se révéler très utile en étant immédiatement productive.
 
Un petit prog de test qui ne teste que l'insert et le retrait aléatoire.
Il faut savoir que pour le TreeDB, la clef est triée et que l'on peut itérer sur les éléments en base avec un curseur, ce qui est bcp plus rapide.
 

# Usage: python kctest.py [num of entries] [db name#options]
# Example: python kctest.py 100000 testdb.kct#tune_buckets=10000
#
from kyotocabinet import *
import sys
import os
import re
import time
import random
import marshal
 
def memoryusage():
    for line in open("/proc/self/status" ):
        line = line.rstrip()
        if line.startswith("VmRSS:" ):
            line = re.sub(r".*:\s*(\d+).*", r"\1", line)
            return float(line) / 1024
    return -1
 
musage = memoryusage()
rnum, bulk_size = 1000000, 10000
 
if len(sys.argv) > 1:
    rnum = int(sys.argv[1])
 
if len(sys.argv) > 2:
    hash = DB()
    if not hash.open(sys.argv[2], DB.OWRITER | DB.OCREATE | DB.OTRUNCATE):
        raise RuntimeError(hash.error())
else:
    print "Using Python dict()"
    hash = {}
 
def bulk_insert(rnum, bulk_size):
    print "========== Bulk inserts =========="
    print "Insert %d items" % rnum
    ttime = 0.0
    stime = etime = time.time()
    sum_itimes = 0
    for step in xrange(0, rnum, bulk_size):
 
        steptime = time.time()
        bulk = {}
        for i in xrange(step, step+bulk_size):
            key = "%08d" % i
            #value = (key, 3.1416, i) 
            alea = random.randint(1, rnum*10)
            dec = random.random()
            value = {'index': i, 
                      'entier': alea, 
                      'chaine': "%20.18f %s" % (dec, alea), 
                      'float': dec, 
                      'datetime': dec * 1000000000
                     }
            bulk[key] = value
        
        stime = time.time()
        hash.set_bulk(bulk)
        ctime = time.time()
        itime = ctime - stime
        print "Time: %.5f ms bulk insert time:  %.5f ms, %.0f/sec" % ((ctime - steptime)*1000, itime*1000, bulk_size/itime), step
        sum_itimes += itime
    print 'Count:', len(hash)
    print "Total time: %.3f sec, total insertion time: %.3f sec" % ((ctime - etime), sum_itimes)
    
def inserts(rnum):
    print "========== Single inserts =========="
    print "Insert %d items" % rnum
    ttime = 0.0
    stime = time.time()
    for i in xrange(0, rnum):   
        key = "%08d" % i
        #value = (key, 3.1416, i) 
        alea = random.randint(1, rnum*10)
        dec = random.random()
        value = {'index': i, 
                  'entier': alea, 
                  'chaine': "%20.18f %s" % (dec, alea), 
                  'float': dec, 
                  'datetime': dec * 1000000000
                 }
        hash[key] = marshal.dumps(value)
        if i % 100000 == 0:
            ctime = time.time()
            ttime += ctime - stime
            print "Time: %.3f sec." % (ctime - stime), i
            stime = ctime
    print 'Count:', len(hash)
    print "Time: %.3f sec." %  ttime
 
def retrievals(rnum):
    print "========== Single retrievals =========="
    print "Retrieve %d items" % rnum
    stime = time.time()
    ttime = 0.0
    for i in xrange(0, rnum):
        key = "%08d" % i
        value = marshal.loads(hash.get(key))
        #if value != (key, 3.1416, i):
        #raise ValueError("Retrieved and inserted values do not match !" ) 
        if i % 100000 == 0:
            ctime = time.time() 
            ttime += ctime - stime
        print "Time: %.3f sec." % (ctime - stime), i
            stime = ctime
    print "Time: %.3f sec." % ttime 
 
    print "Count: %s" % len(hash)
    print "Usage: %.3f MB" % (memoryusage() - musage)
 
 
if __name__ == '__main__':
 
    bulk_insert(rnum, bulk_size)
    inserts(rnum)
    retrievals(rnum)

Ou bien t'es pas obligé de choisir et en utilisant MySQL t'as les 2
http://yoshinorimatsunobu.blogspot [...] y-for.html

Les performances d'un SGBDR avec l'intégrité du NoSQL ?

Sinon, j'évalue MongoDB, version 1.8.2.
 
MongoDB a ceci de particulier qu'il intègre un langage de requêtes. C'est pas du SQL, mais ça émule ce dernier. On peut donc faire des critères de recherche sur n'importe quelle clef ou valeur en base. Les données sont stockées sous forme de BSON, du JSON binaire.
MongoDB intègre des outils pour du sharding et de la réplication, mais par défaut, n'est pas ACID. Il faut spécifiquement activer la journalisation.
 
Mon problème est que les binaires proposés sur le site n'ont pas l'air optimisés. J'ai eu des performances complètement erratiques sous Windows, et sur mon PC perso sous Linux, j'ai des performances très médiocres comparées à celles obtenues sur un serveur Linux  de mon bureau: 6900 inserts/seconde sur mon C2D (32 bits) contre 20 000/sec sur celui du bureau (64 bits). Mais c'est encore bien pire pour les requêtes, j'ai une différence qui tourne entre un facteur 30 et un facteur 50. P-ê que le disque est bcp plus lent, mais je doute un peu que cela suffise à expliquer de telles différences.Il semblerait que les perfs de cette base soient boostées sur un PC récent. En query, sur une machine récente, on atteint des perfs excellentes de l'ordre de 100 000 à plusieurs centaines de milliers d'objets Python/sec sélectionnés avec plusieurs critères (voir prog ci-dessous), ordonnés selon un champs et récupérés.
 
Mais même avec des différences de disque dur, je ne comprends pas comment on peut obtenir des résultats aussi disparates avec la même version, sur des machines différentes, et curieusement, je ne vois rien sur le site qui explique comment "tuner" la base pour en tirer le maximum. Par ailleurs, si l'espace disque est trop limité, le serveur a tendance à non pas s'arrêter de façon propre, mais à crasher violamment (c'est pourtant la version de production compilée en statique du site).
Enfin, quelle que soit la machine cible, dans mes benchmarks, 98 à 100% du temps CPU est utilisé par Python, ce qui semble indiquer que binding Python, entièrement écrit en Python n'est pas très optimisé et est le bottleneck. Je n'ai pas fait de mesures avec Java et C++.
 
Un prog de test inserts et requêtes:
(Si qq a le loisir de passer mon script de test chez lui, ça m'intéresserait de connaitre les résultats obtenus.)

# Usage: python mongotest.py num_of_entries bulk_size
# Example: python mongotest.py 100000 1000
#
 
import sys
import os
import re
import time
import datetime
import decimal
import random
import json
 
 
 
def memoryusage():
   for line in open("/proc/self/status" ):
       line = line.rstrip()
       if line.startswith("VmRSS:" ):
           line = re.sub(r".*:\s*(\d+).*", r"\1", line)
           return float(line) / 1024
   return -1
 
 
 
rnum = 1000000
fname = 'documents.txt'
if len(sys.argv) > 1:
   rnum = int(sys.argv[1])
   bulk_size = int(sys.argv[2])
 
 
def bulk_insert(rnum, bulk_size):
    random.seed(17) 
 
    print "Insert %d items" % rnum
   
    f = open(fname, 'r')
    if 'posts' in db.collection_names():
        print 'cleaning db.posts'
        db.drop_collection('posts')
        print db.posts.count()
 
    posts = db.posts
    ttime = time.time()
    sum_itimes = 0
    
    for step in xrange(0, rnum, bulk_size):
        steptime = time.time()
        bulk = []
        for i in xrange(step, step+bulk_size):
            r = json.loads(f.readline())
            r['datetime'] = datetime.datetime.fromtimestamp(r['datetime'])
            bulk.append(r)      
 
        stime = time.time()
        posts.insert(bulk)
        ctime = time.time()
        itime = ctime - stime
        print "Time: %.3f sec insertion time:  %.3f sec, %.3f/sec" % (ctime - steptime, itime, bulk_size/itime), step
        sum_itimes += itime
    etime = time.time()
 
    print 'Number of docs in posts', posts.count()
    print "Total time: %.3f sec, total insertion time: %.3f sec" % ((etime - ttime), sum_itimes)
 
def retrievals():
    random.seed(17) 
    print "==========Indexing==========="
 
    db.posts.create_index('entier') 
    stime = time.time()
    sum_itimes = 0
 
    print "==========Sorted Queries==========="
    sum_num = 0
    ttime = time.time()
    for i in xrange(0, 10):       
        dec = random.random()
       
        a_date = datetime.datetime.fromtimestamp(dec * 1000000000)
        query = { 'datetime': {'$gt': a_date}, 'float': {'$gt': dec, '$lt': dec+0.25} } 
        num = 0
        stime = time.time()
        db.posts.find(query).count()
        for num, record in enumerate(db.posts.find(query)):
            pass
 
        ctime = time.time()
        itime = ctime - stime
        sum_num += num
        sum_itimes += itime
        form = "Time: %.3f sec. to fetch %s records (datetime > %s, float > x=%f < x+0.25)" 
        print form % (itime, num, a_date, dec) 
 
    etime = time.time()
    print "%s records retrieved retrieved in %.3f sec." % (sum_num, sum_itimes)
    print "Total time: %.3f sec., total query time: %.2f sec." % ((etime - ttime), sum_itimes)    
 
def generate(rnum):
    f = open(fname, 'w')
    print 'Generating random %s documents' % rnum 
 
    random.seed(17) 
 
    for i in xrange(0, rnum):
        # a random record
        alea = random.randint(1, rnum*10)
        dec = random.random()
 
        record = {'index': i, 
                  'entier': alea, 
                  'chaine': "%20.18f %s" % (dec, alea), 
                  'float': dec, 
                  'datetime': dec * 1000000000
                 }
 
        dump = json.dumps(record, separators=(',',':'))
        f.write(dump + '\n') 
 
if __name__ == '__main__':
 
    from pymongo import Connection  
 
    if not os.path.exists(fname):
        generate(rnum)
    
    connection = Connection('localhost', 27017)
    db = connection.test_database
    
    bulk_insert(rnum, bulk_size)
    retrievals()
 
    print "Used memory %d Mb" % memoryusage()

 
Exemple de sortie sur ma machine:

Ces mêmes queries tournent autour de la fraction de seconde a la seconde sur un autre PC. Je ne comprends pas bien ces résultats.

Ca commence à troller sur MySQL

Intéressant.
Ici un post comparant un MySQL "normal" et MongoDB. Pas sûr qu'il ait bien indexé MySQL pour obtenir de telles différences, ou alors sa base était entièrement en RAM ?

Ce comparatif est ridicule.

Je pense aussi. Vu qu'on n'a plus accès aux sources, on ne sait pas s'il a indexé la base, ni si ce sont des queries avec un résultat unitaires ou retournant un certains nombre d'éléments, etc.

+1
 
Pour le DELETE : il pourrait faire un TRUNCATE vu qu'il a pas de critère dans son DELETE
Pour le SELECT : c'est indexé vu que la colonne k est PK (mais pour faire du PK lookup faut utiliser ce que j'ai mis + haut). Il utilise même pas de prepared statement.
Pour les INSERT : il utilise pas d'INSERT bulk ou de LOAD DATA donc oui les perfs ça fait mal.
 
Bref, il sait pas utiliser MySQL

J'obtiens ça sur un netbook (atom n550 1,5GHz):

OK, ça parait cohérent avec les résultats des autres machines. Je ne comprends pas pourquoi ça rame autant sur mon C2D@2GHz.

T'as pensé à mettre à jour ta zlib ?
 
 

Nan mais y'a un vrai pb sur ma machine, on dirait, même en insertion, c'est plus lent que ton netbook. Ceci dit, sous XP, au boulot, j'ai eu aussi des perfs anormalement mauvaises, du genre 1 record/seconde (pas d'antivirus). Mais si ça se trouve, les données passaient par le réseau...

edit:

Bon, mongostat m'indique que la base ne fait rien la plupart du temps, et les commandes:

m'indiquent qu'aucune requête n'a pris plus de 150 ms. On dirait qu'iIl y a de mon coté un pb de communication entre la base et le driver Python. D'ailleurs, mongod occupe 0% du CPU tandis que Python mouline comme un coureur du tour de France...

edit: j'avais oublié que j'avais le driver pur Python et non le driver écrit en C...

Pour comparer, même programme mais avec SQLite 3 (qui est inclus par défaut dans la distrib Python). Vous avez quoi comme perfs ?

import sys
import os
import re
import time
import datetime
import decimal
import random
import json
import sqlite3
 
def memoryusage():
   for line in open("/proc/self/status" ):
       line = line.rstrip()
       if line.startswith("VmRSS:" ):
           line = re.sub(r".*:\s*(\d+).*", r"\1", line)
           return float(line) / 1024
   return -1
 
rnum = 1000000
fname = 'documents.txt'
if len(sys.argv) > 1:
   rnum = int(sys.argv[1])
   bulk_size = int(sys.argv[2])
 
def bulk_insert(conn, rnum, bulk_size):
    random.seed(17) 
    
    c = conn.cursor()
    c.execute("drop table if exists record" )
    c.execute('''create table if not exists record (idx integer,
                                      chaine text, 
                                      float real, 
                                      entier integer, 
                                      datetime real)''')
 
    print "Insert %d items" % rnum
    
    f = open(fname, 'r')
    ttime = time.time()
    sum_itimes = 0
    
    for step in xrange(0, rnum, bulk_size):
 
        def tuple_gen():
            for i in xrange(step, step+bulk_size):
                r = json.loads(f.readline())
                #r['datetime'] = datetime.datetime.fromtimestamp(r['datetime'])
                yield tuple(r.values())
 
        steptime = time.time()        
        stime = time.time()
        c.executemany("insert into record values (?,?,?,?,?)", tuple_gen())
        conn.commit()
        ctime = time.time()
        itime = ctime - stime
        print "Time: %.3f sec insertion time:  %.3f sec, %.3f/sec" % (ctime - steptime, itime, bulk_size/itime), step
        sum_itimes += itime
    etime = time.time()
    print 'Number of docs in record table:', c.execute("select count(*) from record" ).fetchone()[0]
    print "Total time: %.3f sec, total insertion time: %.3f sec" % ((etime - ttime), sum_itimes)
    
def retrievals(conn):
    random.seed(17) 
    c = conn.cursor()
 
    print "==========Indexing================"
    c.execute("create index if not exists entier_idx on record(entier)" )
    c.execute("analyze" )
    #c.execute("create index if not exists datetime_idx on record(datetime)" )
    #c.execute("create index if not exists float_idx on record(float)" )
    stime = time.time()
    sum_itimes = 0
 
    print "==========Sorted Queries==========="
    sum_num = 0
    ttime = time.time()
    for i in xrange(0, 10):       
        dec = random.random()
        
        a_date = datetime.datetime.fromtimestamp(dec * 1E9)
        num = 0
        stime = time.time()
        query = "select * from record where datetime > %s and (float > %s and float < %s)" % (dec*1E9, dec, dec+0.25)
        c.execute(query)
        for num, record in enumerate(c):
            pass
        ctime = time.time()
        itime = ctime - stime
        sum_num += num
        sum_itimes += itime
        form = "Time: %.3f sec. to fetch %s records (datetime > %s, float > x=%f < x+0.25)" 
        print form % (itime, num, a_date, dec) 
    etime = time.time()
    print "%s records retrieved retrieved in %.3f sec." % (sum_num, sum_itimes)
    print "Total time: %.3f sec., total query time: %.2f sec." % ((etime - ttime), sum_itimes)
 
def generate(rnum):
    f = open(fname, 'w')
    print 'Generating random %s documents' % rnum 
    random.seed(17) 
    for i in xrange(0, rnum):
        # a random record
        alea = random.randint(1, rnum*10)
        dec = random.random()
        record = {'index': i, 
                  'entier': alea, 
                  'chaine': "%20.18f %s" % (dec, alea), 
                  'float': dec, 
                  'datetime': dec * 1000000000
                 }
        dump = json.dumps(record, separators=(',',':'))
        f.write(dump + '\n') 
    
if __name__ == '__main__':
    
    if not os.path.exists(fname):
        generate(rnum)
    
    conn = sqlite3.connect('sqlite.db')
    
    bulk_insert(conn, rnum, bulk_size)
    retrievals(conn)
    print "Used memory %d Mb" % memoryusage()

Les perfs sont excellentes. A noter que sans la clause ORDER BY, les requêtes s'exécutent en 9,6 sec au lieu de 37,5 sec.
Curieusement, le fait d'ajouter un index sur cette colonne à la création de la table fait que l'insertion ralentit considérablement. On passe de 6000 à moins de 1000 insertions/sec.
verdoux, tu as quoi, comme résultats ?
En outre, il faut savoir que SQLite ne vérifie pas les types de données (typage dynamique), contrairement aux SGBDR traditionnels. Les données peuvent être corrompues.

OK, problem solved.
Via easy_install, j'avais installé le driver pur Python et non le driver C. Maintenant, les insertions via Pymongo se font à 48 000/sec (sauf qu'elles ne sont pas forcément écrites sur disque instantanément). Les requêtes ne sont pas extrêmement rapides, mais prennent autour de 7 secondes pour 250 000 lignes sur une base d'un million. C'est pas mal, mais c'est plus lent que SQLite. Dans ces tests, MongoDB est 8 fois plus rapide en insertion, et 4 fois plus lent en query, via leurs drivers Python respectifs. Reste que la vitesse du disque est primordiale et les tests en query sur un SSD donnent des vitesses très élevées. Globalement, les perfs sur un seul node sont satisfaisantes au regard des possibilités offertes par la base. Je n'ai pas fait de tests en cluster.

Comme la base est memory mapped, MongoDB ne fonctionnera pas sur des bases de plusieurs millions de lignes en 32 bits. Il faut obligatoirement un OS 64 bits.

Une bonne présentation: http://nosql.mypopescu.com/post/64 [...] y-and-when

Le progrès fait rage
http://www.theregister.co.uk/2011/ [...] _facebook/

Quelques liens utiles:

http://nosql.mypopescu.com/post/61 [...] experience
http://kkovacs.eu/cassandra-vs-mon [...] b-vs-redis
http://code.google.com/p/scalable-frameworks/
http://www.slideshare.net/ksankar/nosql-4559402

Le diagramme ci-dessous fait référence au "théorème CAP" qui dit qu'un système distribué ne peut pas satisfaire plus de deux propriétés simultanément parmi les 3 que sont Partition tolerance, Availibility et Consistency.
Les différentes bases garantissent donc seulement deux de ces propriétés. L'application envisagée doit impérativement tenir compte de ces limitations.

Sinon, d'un point de vue conceptuel, il me semble que les bases orientées "tables" façon BigTable sont plus complexes à appréhender que les bases orientées documents comme MongoDB, qui se prêtent bien à la programmation OO, chaque document représentant une hiérarchie d'objets; tandis que les bases orientées clefs-valeurs sont les plus simples, et peuvent être utilisées comme des dictionnaires améliorés.

Cassandra, ou le NoSQL qui rajoute une couche... de SQL...

Rien de très étonnant. Cassandra/HBase/BigTable sont des bases NoSQL avec schéma.

Les concepts de Cassandra/HBase/BigTable sont bcp plus clairs si on fait la correspondance:

Il n'y a pas de jointure dans Cassandra, parce que que les ColumnFamilys peuvent contenir d'autres ColumnFamilys, ce qui revient effectivement à faire l'équivalent d'une jointure.
Dans Cassandra, les supercolumns et les columns sont des dictionnaires clefs-valeurs. L'absence d'une clef correspond à un NULL dans une table SQL.
Donc les concepts sont équivalents, ce qui explique le fait qu'on puisse faire un SQL par dessus les tables Cassandra.
Il y a cependant une différence majeure, qui est que dans Cassandra, les columns et les Supercolumns sont triées par défaut, contrairement aux RDBMS. L'avantage est un gain certains de perfs. Il est possible d'obtenir des données en sens inverse via SliceRange tant que le nombre de données requêté tient en RAM, ça n'est donc pas aussi performant qu'un ORDER BY d'un RDBMS.

Bon, MongoDB a mauvaise presse ces temp-ci:
http://news.ycombinator.com/item?id=3202081
http://news.ycombinator.com/item?id=3200683
Réponse du boss de 10gen:http://news.ycombinator.com/item?id=3202959
En particulier, les multiples posts indiquant des pertes de données (même avec une version 2.0),sont particulièrement inquiétants, donnant l'impression que ce produit n'est pas mature.

Fais ressortir la réponse du boss quand même, ça met en lumière que les posts précédents étaient de la merde : http://news.ycombinator.com/item?id=3202959

Non, ça n'était pas de la merde.
http://blog.engineering.kiip.me/po [...] th-mongodb
 
MongoDB n'est manifestement pas un outil fiable.

 
Si, c'était un peu de la merde. Y'a quand même un monde entre : "l'intégrité des données n'est pas garantie" et "l'exploitation de MongoDB est délicate du fait de certains problèmes liés aux performances".

Et encore des gens qui lâchent mongodb:
http://www.korokithakis.net/posts/ [...] 3-i-guess/
http://www.zopyx.de/blog/goodbye-mongodb <-- disparu
http://news.ycombinator.com/item?id=4477974

Toujours les mêmes raisons.

Bonjour à tous,
 
Voilà dans le cadre de mon stage je dois effectuer une étude dans laquelle je dois récolter plusieurs tests de performances effectués sur MongoDB (écriture, lecture, update) afin de pouvoir en connaitre les avantages et les limites pour un futur projet. Et ainsi superposer les différents tests trouvés selon la taille de l'objet, le nombre de clients, quel driver de langage utilisé.
 
Jusque là je me sens un peu bloqué sur la démarche à adopter. En effet je suis surtout habitué à faire du développement classique et je ne suis pas très  à l'aise avec ce genre d'exercice "tout seul".  J'aurais vraiment besoin d'aide, même en MP. j'aurais peut être besoin de l'expertise d'un expert MongoDB.
 
Merci d'avance pour votre contribution quelle qu'elle soit.
 

Une bonne comparaison entre les deux éléphants des bases de données distribuées open source:
http://bigdatanoob.blogspot.fr/201 [...] andra.html

Les deux systèmes sont capables de gérer des clusters de centaines de serveurs, et des centaines de To de données, avec réplication entre data centers. Les performances des deux systèmes ont considérablement avancé, de même que leurs fonctionnalités respectives.
Performances
Ce benchmark montre qu'à part dans le cas d'une base où les lectures sont fortement majoritaires, où un shard de MySQL est vainqueur, HBase et Cassandra dominent largement, ce qui n'a rien de surprenant dans la mesure où ces bases sont optimisées pour l'écriture sous forte concurrence.
Difficile de savoir lequel est le plus rapide des deux. HBase a la réputation d'être très rapide (Facebook, après avoir développé Cassandra, a décidé de partir sur HBase pour son système de messaging), mais semble nettement plus compliqué à administrer.

Un très bon article: http://www.cubrid.org/blog/dev-pla [...] cale-data/

Excellente conférence de Martin Fowler: http://www.youtube.com/watch?v=qI_g07C_Q5I
Visionnage recommandé.

Article intéressant: NoSQL data modeling
 
 
et en bonus:
 

Je dois avouer que jusqu'à présent, je voyais le NoSQL utile uniquement pour du décisionnel...
 
Edit: en tout cas, topic très intéressant (j'ai bien aimé le lien sur Mysql et le HandlerSocket)

Non, c'est utilisé pour de la transaction aussi. Par exemple, la distribution de colis à La Poste est maintenant gérée sous Cassandra.

Ça c'est un truc que je ne comprends pas.
La distribution de colis c'est bien trop petit pour justifier du noSQL.
 
Avec 4.000.000 de colis par jours on est même pas a 50/s, même si il y a des pics a 500/s voir même 5000/s ça reste toujours a portée de n'importe quel server avec 2 bête cores et un minimum d'optimisation.
 
Le reste c'est du web server qui peut augmenter en capacité de façon pratiquement linéaire. Et tout ça sans même parler de l'utilisation de cache et d'optimisation un peut plus poussée.

Faut avouer que la gestion de la distribution de colis, ça nécessite pas beaucoup de tables La clé est le n° du colis, après y'a qq dates et lieux associés pour avoir le parcours.
 
Maintenant, je vois mal du NoSQL pour un outil de help-desk, par ex, ou une base de connaissance style Wikipedia

Ca fait 1,46 milliards de colis-lignes/an Ils ne gardent que 15j de données. Il y a effectivement des pics de transactions de plusieurs milliers de lignes/s en fin d'année, ce qui n'est possible en insert que pour une table complètement dénormalisée, et bien sûr un uptime > 99, 99%. Ca me paraît un use case raisonnable pour du NoSQL. Apparemment, ils venaient de MySQL (un shard ?).

c'est utilisé pour un projet de gestio des oevures d'art( gertrude ) pour sa facilité a gérer de la petite cuillère au chateau  
Ils utilisent mongodb  
 
 

Je dois dire que Cassandra a une architecture tout à fait intéressante et séduisante. Elle est basée sur Google BigTable pour le modèle de données et Amazon Dynamo pour l'archi réseau. En fait Cassandra est une implémentation pratiquement complète de l'architecture Dynamo. A noter que Riak est aussi une implémentation de l'architecture dynamo, mais le modèle de données est simplement un modèle clef-valeur.

Le modèle de données

Le modèle de données est de façon schématique une DistributedHashMap<rowkey, SortedHashMap<column name, value>>, où value peut être un objet ou une collection, et column name peut être une clef composite. Ce modèle est l'équivalent d'un ensemble dénormalisé de tables  dans un SGBD relationnel, et s'appelle une ColumnFamily dans la terminologie Cassandra.

La SortedHashMap peut contenir jusqu'à 2 milliards de paires <Column Name, value> et le nombre de rows n'est pas limité. A noter que value peut être absent et c'est une pratique courante de se servir des Column Names pour contenir les valeurs elles-mêmes.

Pour donner un exemple de la façon dont on se sert de ce modèle, voici un schéma relationnel.

Et le schéma Cassandra équivalent.

On constate que le modèle relationnel décrit de façon compacte les relations entre les entités. Une vue particulière sur les données sera créée dynamiquement lors des requêtes grâce à des jointures. Parce que le modèle Cassandra est essentiellement dénormalisé, il décrit une seule vue des relations entre les entités, il ne possède pas la souplesse d'un SGBD relationnel. Chaque vue supplémentaire sur les données nécessitera d'ajouter une table d'indexation sous la forme d'une Column Family supplémentaire. Cela pourrait se comparer à une vue matérialisée d'un SGBDR. A noter que le schéma non relationnel de BigTable se prête plus plus facilement à un mapping orienté objet que le modèle relationnel, car un objet peut être sérialisé et relu de façon séquentielle, - et donc efficiente -, dans/depuis une ColumnFamily.

Le token ring et la répartition des données

Ce modèle de données est conditionné par l'organisation physique du système. Dans l'architecture dynamo, les serveurs/nodes sont tous identiques et organisés en un token ring.

Chaque row d'une ColumnFamily réside sur un même serveur, avec toutes les données associées, celles qui seraient jointes par des relations dans un SGBD relationnel. Ainsi l'on préserve la localité des données, ce qui est vital pour les performances.

La rowkey est une clef de hachage (MurMur3) qui permet de répartir les rows uniformément entre les nodes (plus de détails ici).

On égalise ainsi automatiquement les données et donc la charge, ce qui est plus délicat avec un sharding MySQL naïf (par exemple pour des time series, les données les plus récentes sont souvent les plus souvent accédées). A noter que chaque node physique contient 256 virtual nodes, ce qui permet de répartir encore mieux les données dans de petits clusters. Lorsqu'un node physique est rajouté/enlevé, les données des vnodes sont automatiquement réparties pour équilibrer la charge.

La réplication en temps réel

Pour assurer la redondance des données, chaque row est répliqué N fois (facteur de réplication) sur des nodes distincts via peer-to-peer. Cassandra est capable de répartir les données sur des baies différentes, et de faire de la réplication en temps réel entre plusieurs data centers ou entre un data center et un cloud. En général, N = 3 dans un même data center et des baies distinctes est e type de réplication le plus courant. Les débits et latences d'écriture tiennent compte de ces réplications.

Si N > 1, cependant, le délai induit par la réplication fait que pendant quelques ms à quelques centaines de ms (en fonction de la topologie physique du token ring et des diverses réplications en jeu), les serveurs ne sont pas tous synchronisés. Si une requête tombe sur l'une des copies non synchronisées, elle ne retournera pas le résultat escompté: on dit que Cassandra est une base "éventuellement consistante". Le degré de consistance est configurable par requête: on peut par exemple pour une requête donnée interroger un seul serveur (consistency level = 1), au moins N/2+1 serveurs (consistency level = LOCAL_QUORUM), ou les N serveurs sur un même data center (consistency = ALL). Le tradeoff sera donc entre la consistance et la latence (le C et le Availability du théorème CAP), en fonction des besoins. Une BD qui ne retourne pas systématiquement le bon résultat a-t'elle un intérêt ? Cela dépend des applications. Une application de monitoring d'un réseau de senseurs peut par exemple n'avoir besoin de connaitre le temps réel qu'à la dernière minute près, si ces senseurs monitorent des phénomènes transitoires qui mettent plusieurs minutes ou dizaines de minutes. Une application OLAP peut ne servir à faire des statistiques que pour des périodes allant de 1j à des années. un retard qui se compte en secondes n'a alors aucune importance. A l'inverse, la plupart des applications OLTP ne tolèrent pas de telles approximations et la consistance est primordiale.

Comme tous les nodes sont identiques, une ferme de serveurs d'application peut attaquer indifféremment n'importe lequel des nodes via la rowkey. Comme on le voit, l'architecture du système est telle que la scalabilité de la base est linéaire: on double les débits d'écriture et de lecture en doublant le nombre de nodes.

Autre conséquence intéressante de cette symétrie: il n'y a pas de "single point of failure". Pour cette raison associée aux possibilités étendues de réplication, Cassandra est réputé être extrêmement résistant aux pannes. Il est bien adapté pour des applications où la disponibilité est primordiale.

Les restrictions par rapport à un SGBDR
Le revers de la médaille est que le modèle de données est relativement inflexible et nécessite d'être organisé au préalable afin d'optimiser les requêtes qui vont être faites. On voit que si le langage CQL est en surface réminiscent du SQL, ce qui se cache derrière est absolument sans comparaison, et la conception d'un modèle de données performant nécessite de comprendre dans le détail comment fonctionne Cassandra. De plus, la nature distribuée et décentralisée du système rend très difficiles des opérations considérées comme des acquis dans les SGBDR. Ainsi, Cassandra n'offre pas de jointures (c'est en partie compensé par la dénormalisation), mais pas non plus GROUP BY. La contrainte d'unicité sur les rows n'xiste pas pour des raisons évidentes de performance, mais peut être simulée par l'adjonction d'un UUID à la rowkey. L'utilisation de DISTINCT est très restreinte, et SORT BY doit dans la mesure du possible être pris en compte dès la modélisation. Enfin, il n'y a pas d'opérations d'aggrégation, bien que ça soit à l'étude. Il est à noter toutefois que le sharding de bases MySQL impose généralement le même genre de restrictions, tout en ayant en sus les contraintes liées à la réplication et à la durabilité d'une base distribuée, contraintes que Cassandra résout élégamment. Le sharding de bases MySQL privilégie la consistance (au sens CAP) au détriment de la durabilité. Cela équivaut à un facteur de réplication égal à 1.

Détails d'implémentation
L'implémentation de Cassandra inclut une conception et des algorithmes très sophistiqués. En vrac, ConcurrentSkipList, LZ4 ou Snappy pour la compression, Paxos pour les transactions légères, LMAX disruptor, MurMur3, Bloom filter, Snap tree, Merkle tree, protocole Gossip (détection de panne), I/O non bloquantes, architecture SEDA, n'en jetez plus. Pour étudier dans le détail le fonctionnement dynamique de Cassandra, ce blog post est technique mais excellent.
La base est optimisée pour l'écriture. Les données sont écrites d'abord sur un fichier de commit log, puis dans une memtable, qui est ensuite flushée sur disque dans une SSTable quand elle est pleine. Toutes les écritures sont séquentielles, même pour les mutations de données. Ces dernières sont timestampées, mais il n'y a pas de notion d'historisation. Pour une suppression, on leur assigne une valeur spéciale, la tombstone (pierre tombale), et régulièrement, une phase de compaction des SSTables supprime physiquement les valeurs en tâche de fond via un GC.

J'espère par ce petit tour d'horizon avoir fait comprendre que Cassandra est un produit sérieux et très avancé, dont l'usage est réservé aux applications non transactionnelles pour lesquelles la scalabilité et la disponibilité sont importantes.

Ressources:
https://blogs.atlassian.com/2013/09 [...] cassandra/
http://horicky.blogspot.fr/2010/10 [...] hbase.html
http://highlyscalable.wordpress.co [...] databases/

 
C'est quoi la différence entre les 2 ?

J'allais te répondre que dans le premier cas, on a le contrôle des nodes, pas dans l'autre, mais effectivement, dans le cas d'une BD, il n'y en a pas vraiment, il faut avoir le contrôle des nodes.

Et encore un excellent post d'Ilya Katsov: http://highlyscalable.wordpress.co [...] rocessing/
Le sujet cette fois-ci est le traitement en temps réel distribué.