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 PAC" 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 SQL 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
Toujours les mêmes raisons.