OrientDB de escritura lenta

OrientDB sitio oficial dice:OrientDB de escritura lenta

En las ferreterías comunes de hasta 150.000 documentos por segundo, 10 mil millones de documentos por día. Los Big Graphs se cargan en pocos milisegundos sin ejecutar el costoso JOIN como el Relational DBMSs.

Pero, la ejecución del siguiente código muestra que está tardando ~ 17000ms en insertar 150000 documentos simples.

import com.orientechnologies.orient.core.db.document.ODatabaseDocumentTx; 
import com.orientechnologies.orient.core.record.impl.ODocument; 

public final class OrientDBTrial { 

    public static void main(String[] args) { 
     ODatabaseDocumentTx db = new ODatabaseDocumentTx("remote:localhost/foo"); 
     try { 
      db.open("admin", "admin"); 

      long a = System.currentTimeMillis(); 
      for (int i = 1; i < 150000; ++i) { 
       final ODocument foo = new ODocument("Foo"); 
       foo.field("code", i); 
       foo.save(); 
      } 
      long b = System.currentTimeMillis(); 
      System.out.println(b - a + "ms"); 

      for (ODocument doc : db.browseClass("Foo")) { 
       doc.delete(); 
      } 
     } finally { 
      db.close(); 
     } 
    } 

}

Mi hardware:

Dell Optiplex 780
Intel (R) Core (TM) 2 Duo CPU E7500 @ 2.93GHz
8 GB de RAM
de Windows 7 64bits

¿Qué estoy haciendo mal?

Dividir los guardados en 10 subprocesos simultáneos para minimizar la sobrecarga de Java hizo que se ejecutara en ~ 13000 ms. Aún mucho más lento de lo que dice la portada de OrientDB.

Fuente

2012-08-30 Thiago Negri

¿Pudo obtener el máximo rendimiento? Estudio este problema, pero mi rendimiento es incluso peor que usted –

He decidido usar H2 en lugar de OrientDB. H2 se ajusta a mi caso de uso. –

Puede lograr que mediante el uso de 'Base de datos plana' y orientdb como una biblioteca incrustado en java ver más explicados aquí http://code.google.com/p/orient/wiki/JavaAPI

lo que se utiliza es el modo de servidor y envía muchas solicitudes para orientdb servidor, juzgar por su índice de referencia que tienes ~ 10 000 inserciones por segundo lo cual no es malo, por ejemplo, creo que 10 000 solicitudes de e/s es muy buen rendimiento para cualquier servidor web (y el servidor orientdb realidad es un servidor web y se puede consultar a través de http, pero Creo que Java está utilizando el modo binario)

Fuente

2012-09-04 00:45:33 user781903

¡Lea primero la documentación sobre cómo lograr el mejor rendimiento!

algunos consejos:

-> no lo crea oDocument siempre:

final ODocument doc; 
    for (...) { 
    doc.reset(); 
    doc.setClassName("Class"); 
    // Put data to fields 
    doc.save(); 
    }

-> NO depender de System.currentTimeMillis() - Utilización perf4j o herramienta similar para medir los tiempos, ya que la primera ¡uno mide los tiempos del sistema global, por lo tanto, incluye el tiempo de ejecución de todos los demás programas que se ejecutan en su sistema!

Fuente

2012-09-04 08:05:06

No hay problema para una prueba de ejecución tan prolongada para usar System.currentTimeMillis como cronómetro.Por supuesto, podrías hacer algo de calentamiento antes de medir (y usar nanoTime), pero no creo que cambie el resultado por un orden de magnitut. Incluso puedes medir a mano el tiempo y sería válido. – eckes

Los números desde el sitio OrientDB se cotejan para una base de datos local (sin sobrecarga de la red), por lo que si se utiliza un protocolo de control remoto, esperan algunos retrasos.

Como Krisztian señaló, reutilizar objetos si es posible.

Fuente

2012-09-04 09:25:27 gusto2

Respuesta

Cuestiones relacionadas