Journal Petit bench de bases de données embarquées

• # Fichiers

  Posté par Jb Evain (site web personnel) le 24 janvier 2007 à 13:22. Évalué à 1.

  

  Hey,
  
  On pourrait avoir les fichiers de données (dans c:/temp/20070122 ;) ) pour lancer les tests nous mêmes ?
  
  Merci,

  • [^] # Re: Fichiers

    Posté par Mat (site web personnel) le 24 janvier 2007 à 13:31. Évalué à 1.

    

    en fait, comme le calcul du digest est bidon, tu n'as même pas besoin du parcours de la liste des fichiers.
    
    J'ai laissé ça pour l'exemple; et puis un calcul de digest sur un fichier, quel que ce soit le fichier, ca reste un digest ! :)

• # SQLite est peut-être en C++, mais a un driver JDBC

  Posté par TemPi le 24 janvier 2007 à 14:21. Évalué à 1.

  

  Il y a même un driver 100% java, donc sans une seule ligne de code C.
  (mais il est moins performant)
  
  http://freshmeat.net/projects/sqlitejdbc/

  • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

    Posté par TemPi le 24 janvier 2007 à 14:27. Évalué à 1.

    

    Oups, j'ai mal lu l'article (faut dire, il est tellement long)...
    
    Il y a deux facon d'utiliser le driver JDBC de sqlite:
    1) utiliser le driver JDBC 100% full java
    2) utiliser une interface JAVA + JNI + librairie sqlite en C.
    
    La deuxième solution est environ 5 fois plus rapide.
    

    • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

      Posté par Mat (site web personnel) le 24 janvier 2007 à 14:34. Évalué à 1.

      

      Oups, j'ai mal lu l'article (faut dire, il est tellement long)...

      
      
      :-/ désolé, je voulais être complet sans trop en dire pourtant...
      
      Pour Sqlite, j'ai voulu tester les 2 méthodes, mais seulement l'une des deux à fonctionné. J'avoue ne pas avoir trop insisté puisque de toutes façons je n'aurai pas retenu cette solution, dans la mesure où elle n'était pas 100% java.
      
      L'interface java + jni + librairie sqlite en C c'est une interface particulière, pas JDBC, on est bien d'accord ?

      • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

        Posté par TImaniac (site web personnel) le 24 janvier 2007 à 15:29. Évalué à 3.

        

        Sinon tu as pensé à tester db4o ? Ok, c'est pas vraiment SQL, mais justement, ca serait pertinent de voir si y'a des grosses différences de performance, le but étant bien entendu de stocker le même genre d'information.

        • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

          Posté par TemPi le 24 janvier 2007 à 15:44. Évalué à 2.

          

          Ca a l'air sympa, db4o. Je ne connaissait pas. Merci :)
          
          Est-ce qu'il existe le même genre de truc, mais pas limité à Java et .NET ?

          • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

            Posté par vrm (site web personnel) le 24 janvier 2007 à 15:54. Évalué à 1.

            

            c'est difficle, c'est fortement orienté objet, donc du coup un port en C ou en fortran n'as pas vraiment de sens

            • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

              Posté par TImaniac (site web personnel) le 24 janvier 2007 à 16:12. Évalué à 2.

              

              Non seulement c'est basé sur un modèle objet, mais c'est aussi basé sur les plateformes à bytecode : afin d'exploiter la syntaxe native du langage (Java ou C#) pour les requêtes (et ainsi profiter de toutes les vérifications de typages et le support des IDE), le moteur db4o "compile" le bytecode à la volée. C'est à mon avis beaucoup plus difficilement envisageable dans des environnements qui produisent du code natif sans autre méta-données (type C++).

              • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

                Posté par TemPi le 24 janvier 2007 à 17:58. Évalué à 1.

                

                Ok merci.
                
                Je pensait effectivement à du C++.

        • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

          Posté par Mat (site web personnel) le 24 janvier 2007 à 17:06. Évalué à 1.

          

          non, effectivement je n'y avais pas pensé;
          mais tu sais un peu comment ça s'utilise ? Visiblement il faut s'inscrire pour accèder aux forums...
          Je te demande parce que voilà les résultats :
          
          -------------------------------- db40 ----------------------------------
          17 doublons, 200 ajoutés, nombre de boucles :218
          temps total : 7140ms
          temps moyen : 32.75229357798165ms
          
          
          et c'est pas top top...
          
          et voilà le code source (j'ai pas accès au ftp d'où je suis pour mettre à jour l'archive)
          
          
          package dup.dbengines;
          
          import java.sql.Connection;
          import java.sql.SQLException;
          import java.util.Date;
          
          import com.db4o.Db4o;
          import com.db4o.ObjectContainer;
          import com.db4o.ObjectSet;
          
          import dup.CheckDup;
          
          public class Db4oCheckDup extends CheckDup {
          
          class Dup {
          private byte[] digest ;
          private Long date_insert ;
          
          public Dup(byte [] digest) {
          this.digest = digest ;
          this.date_insert = null ;
          }
          
          public Dup(byte [] digest,long date_insert) {
          this.digest = digest ;
          this.date_insert = new Long(date_insert) ;
          }
          
          public long getDatedate_insert() {
          return date_insert!=null?date_insert.longValue():0 ;
          }
          public byte[] getDigest() {
          return digest;
          }
          
          }
          
          public static final String DB_ENGINE_NAME = "db40" ;
          
          private ObjectContainer db=Db4o.openFile(DB_ENGINE_NAME);
          
          public Connection openConnection() throws ClassNotFoundException,
          SQLException {
          return null;
          }
          
          public void shutdown() throws SQLException {
          }
          
          public synchronized void beginTransaction() throws SQLException {
          
          }
          
          public synchronized void commit() throws SQLException {
          db.commit() ;
          }
          
          public synchronized void rollback() throws SQLException {
          db.rollback() ;
          }
          
          public void closeConnection() throws SQLException {
          db.close() ;
          }
          
          public synchronized boolean isDup(byte[] digest) throws SQLException {
          Dup d = new Dup(digest) ;
          ObjectSet result=db.get(d);
          return result.size() > 0 ;
          
          }
          
          public synchronized void add(byte[] digest) throws SQLException {
          Dup d = new Dup(digest, new Date().getTime()) ;
          db.set(d) ;
          }
          
          public synchronized void createTableDup() throws SQLException {
          }
          
          public synchronized void dropTableDup() throws SQLException {
          }
          
          public synchronized void purge() throws SQLException {
          }
          
          
          }
          

          • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

            Posté par Jb Evain (site web personnel) le 24 janvier 2007 à 17:29. Évalué à 2.

            

            Tu utilises la plus lente des trois façon d'interroger db4o, le Query By Example. En gros tu donnes un objet patron, et db4o va le comparer avec tous les objets du même type pour savoir quoi renvoyer.
            
            Avec le code que je t'ai donné plus bas:
            
            http://linuxfr.org/comments/797287.html#797287
            
            db4o arrive en seconde position derrière hsql chez moi.
            
            Jb

      • [^] # Re: SQLite est peut-être en C++, mais a un driver JDBC

        Posté par TemPi le 24 janvier 2007 à 15:48. Évalué à 1.

        

        La plus simple à utiliser est celle qui utilise le driver 100% java. Il n'y a rien à faire, juste à avoir le jar dans le classpath.
        
        L'autre nécessite une compilation, des arguments sur la ligne de commande de java, ... enfin, plein de bazar.
        
        Donc, je suppose que tu a utilisé le driver 100% java.
        Donc, tu as probablement utililisé la solution la plus lente, ce qui explique en partie tes résultats. :)

• # Provider db4o

  Posté par Jb Evain (site web personnel) le 24 janvier 2007 à 16:14. Évalué à 2.

  

  Re-Salut,
  
  J'ai implémenté un "provider" db4o pour tes tests.
  C'est pas très propre à cause de l'architecture du framework de test, mais ça a des performances sympathiques, et surtout, pas de SQL!
  
  Le code est ici: http://evain.net/public/Db4oCheckDup.html
  
  Jb

  • [^] # Re: Provider db4o

    Posté par Mat (site web personnel) le 24 janvier 2007 à 17:51. Évalué à 1.

    

    effectivement on est obligé de redéfinir toutes les méthodes avec un contenu vide, mais au départ, je ne pensais tester que des bases SQL.
    
    ceci dit, il faut reconnaitre que ça fonctionne pas mal.
    
    merci!

• # sqlite

  Posté par Prae le 24 janvier 2007 à 18:13. Évalué à 1.

  

  -------------------------------- sqlite ----------------------------------
  32 doublons, 1000 ajoutés, nombre de boucles :1033
  temps total : 216892ms
  temps moyen : 209.96321393998065ms

  
  
  Je suis étonné par ce résultat...
  dis moi, tu n'aurais pas oublié de faire un "BEGIN;" et un "COMMIT;" à la fin de ton bloc de requète ?
  Perso, en terme de performance, je suis passé de 5 min à 2 secondes pour 10.000 insertions.

  • [^] # Re: sqlite

    Posté par benja le 24 janvier 2007 à 22:52. Évalué à 2.

    

    Et s'il plante, il doit n'avoir perdu aucune info : elles doivent
    donc être persistées à chaque insertion/suppression.

    • [^] # Re: sqlite

      Posté par Raphaël G. (site web personnel) le 25 janvier 2007 à 13:08. Évalué à 3.

      

      Ben alors c'est complètement inutile de tester sqlite...
      
      Vu que a chaque écriture il va locker la table + écriture atomique + unlock de la table...
      
      Une petite question stupide, mais ne serait-il pas plus simple de mettre en place ton BEGIN+COMMIT et en cas d'erreur de refaire transaction par transaction jusqu'à celle qui pose problème.
      Mes vagues souvenirs de SQL semblent me mentionner que si ça foire lors d'une transaction tu pourrit pas la db et elle est comme avant la transaction.

      • [^] # Re: sqlite

        Posté par Mat (site web personnel) le 26 janvier 2007 à 14:05. Évalué à 1.

        

        Je ne comprends pas ce que tu veux dire.
        
        Quelle que soit la technique utilisée par la base pour pouvoir revenir à un état cohérent en cas de plantage (journaux avant/ après ...), il faut bien écrire qque chose sur le disque à un moment donnée.
        
        Or mon problème n'est pas de savoir si ma table reste cohérente en cas de plantage, pour ça je fais confiance au SGBD, ce que je souhaite c'est surtout être sûr que si une demande de travail est passée, elle a été stockée et persistée sur le disque dur.
        
        Et pour ça, je doute que le système des transactions m'apportent réellement qque chose, même si c'est ce que j'ai codé. Et le problème existe pour sqlite mais pour toutes les autres bases. (excepté DB2 puisqu'elle est distante, et pas dans la JVM de l'appli).

        • [^] # Re: sqlite

          Posté par briaeros007 le 26 janvier 2007 à 14:58. Évalué à 2.

          

          ce que je souhaite c'est surtout être sûr que si une demande de travail est passée
          Si tu entend par 'être passée' : 'que la sgbd m'a rendu la main en me disant , oki c'est bon' -> c'est bien le role d'un sgbd.
          Si c'est juste que tu as envoyé tes données, et que le sgbd ne t'as encore rien dis, alors la je pense pas que ce soit possible.

          • [^] # Re: sqlite

            Posté par Mat (site web personnel) le 29 janvier 2007 à 10:08. Évalué à 1.

            

            Je suis entièrement d'accord avec toi lorsqu'il s'agit d'un SGBD classique. C'est à dire, lorsqu'on passe par le réseau.
            Mais dans mon cas, le SGBD fait partie intégrante du processus de l'application. Donc si processus plante, rien ne me garantit que si ma transaction a été comittée, elle a été effectivement écrite sur le disque dur. Le commentaire (anglais !!!?) https://linuxfr.org/comments/798151.html#798151 me laisse même songeur quant aux délais, et laisse présager d'un sacré boulot de réglage si finalement nous optons pour la solution d'une BD embarquée.
            
            
            C'est pour ca que je disais en réponse à Raphaël que la problématique était la même pour toutes les BDs embarquées dans le cadre de mon test.

• # Suggestions

  Posté par ThomasMueller le 26 janvier 2007 à 11:13. Évalué à 4.

  

  Hi,
  
  Thanks for sharing the benchmark results! I have some suggestions to improve the test:
  
  The test should keep and re-use the prepared statements, this would improve the performance for all databases.
  
  The test is only run once; that's OK if you run it for a long time. If not, I suggest to execute it twice (or to measure the time a little bit after starting it), to given the JVM a chance to compile the classes (JIT).
  
  To have 'fair' results, the same data should be used for all databases. Using a seed value in the random number generation solves this problem: Random r = new Random(0); and then use r to get 'repeatable' results. Or use r.setSeed to reset the random number generator.
  
  For HSQLDB, the default mode is used, which is in-memory. That means the table may not fit in the memory if it grows larger (OutOfMemoryException). An easy solution is to use the following database URL: jdbc:hsqldb:test;hsqldb.default_table_type=cached
  
  I hope this helps,
  Thomas

  • [^] # Re: Suggestions

    Posté par Mat (site web personnel) le 26 janvier 2007 à 14:10. Évalué à 1.

    

    Thanks for your suggestions.
    
    I didn't know that using PreparedStatement could improve performance.
    I'll try it !
    
    About HSQLDB, do you know if in the in-memory HSQLDB writes the table on the FS after each commit ? If not, this is clearly not the mode I should use for my purposes...
    
    Thanks!

    • [^] # Re: Suggestions

      Posté par ThomasMueller le 27 janvier 2007 à 00:08. Évalué à 3.

      

      In HSQLDB, the data is persisted (to a log file) even in this case. The problem is, the amount of data in the tables is limited by the memory. That means at some point you will run out of memory when using the default mode. When using HSQLDB, opening the database becomes slower and slower the more data is in the database.
      
      In HSQLDB, the log file is written up to 20 seconds after the commit, see also: http://hsqldb.org/doc/guide/ch09.html#set_write_delay-sectio(...)
      Other databases try to write the log file before the commit returns. I say 'try', because this is not actually working unless you have special hard drives and/or BIOS settings. I have tested this using a 'power off' test. For details, see also: http://www.h2database.com/html/advanced.html#acid
      The H2 database uses a default delay of up to 1 second (this can be changed).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.