Extrem langsame Abfrage Apache Drill mit Oracle jdbc

Question

Ich habe erfolgreich eingerichtet Apache Drill (neueste 1.9) mit dem JDBC-Client von Oracle (neuestem ojdbc7.jar von Oracle) als Speicher Plugin:

{ 
    "type": "jdbc", 
    "driver": "oracle.jdbc.driver.OracleDriver", 
    "url": "jdbc:oracle:thin:@server:1521/myservicename", 
    "username": "TEST_USER", 
    "password": "password", 
    "enabled": true 
} 

ich kann Machen Sie Abfragen, aber selbst die einfachsten Dinge brauchen buchstäblich Minuten, um ausgeführt zu werden. Das Abfragen einer Single-Row-Tabelle dauert 78 Sekunden. Und nur das Standardschemas Einstellung dauert eine Minute über:

0: jdbc:drill:zk=local> use oracle.TEST_USER 
. . . . . . . . . . . > ; 
+-------+-------------------------------------------------+ 
| ok |      summary      | 
+-------+-------------------------------------------------+ 
| true | Default schema changed to [oracle.TEST_USER] | 
+-------+-------------------------------------------------+ 
1 row selected (77,5 seconds) 

Aber ich habe mit einer einfachen Hallo-Welt-Stil Java-Anwendung getestet, dass die Verbindung mit der gleichen Verbindungszeichenfolge mit vollem Tisch holen mal absolut einwandfrei funktioniert von ungefähr 0,1 Sekunde.

jdbc:oracle:thin:@server:1521/myservicename 

habe ich von einem Ubuntu und Mac getestet und auch versucht, die Random-Quelle für Java-Einstellung wie andere Antworten als potenzielle Performance-Probleme hinweisen:

export DRILL_JAVA_OPTS="$DRILL_JAVA_OPTS -Djava.security.egd=file:/dev/./urandom" 

Was hier los? Ist das ein bekanntes Problem oder gibt es eine Problemumgehung?

Ich habe Drill-Embedded verwendet.

Answer 1

Ich konnte die Ursache für dieses Problem finden.

Das Problem ist keine langsame Abfrage, sondern eine nicht optimale Vorabrufstrategie in den Metadatenabfragen von Drill. In meinem Fall ist die Datenbank riesig und hat Tausende von Schemas (Oracle-Benutzer) mit jeweils hunderten von Tabellen. Und Oakles Standard-Fetchgröße ist 10, was zu Hunderten von DB-Roundtrips führt.

Jede Apache Drill JDBC-Abfrage untersucht die Metadaten.

Innen Apache Drill: JdbcStoragePlugin.java#L351:

java.sql.DatabaseMetaData.getSchemas() 

Innen Apache Calcite (Drill dependency): JdbcMeta.java#L323:

java.sql.DatabaseMetaData.getTables(...) 

Beide Teile außer Kraft setzen keine Standard FETCHSIZE und über wireshark kann ich buchstäblich sehen die Pakete für Schritt in Schritt fallen jeweils mit nur 10 Reihen. (Die Latenz zum DB-Server ist ziemlich hoch, da sie woanders liegt)

Ich habe Apache Drill bereits mit einem manuellen Aufruf von setFetchSize rekompiliert, was die Antwortzeiten stark verbessert hat. Ich habe Calcite bisher nicht gepatcht, aber das wird wahrscheinlich auch funktionieren. Normalerweise denke ich, dass beim Abrufen von Metadaten die regulären Schritte zum Schreiben von performantem JDBC-Code berücksichtigt werden sollten, da reale Szenarien leicht mit größeren Metadaten (zB mehr als 10 Tabellen oder Schemata) enden können Eine andere Idee wäre Caching, aber ich habe noch kein Metadaten-Caching in Drills JDBC-Speicher-Plugin gesehen.