HikariCP Es ist schneller. Hi·ka·ri [hi·ka·'lē] ( Herkunft: Japanisch ): Licht; Strahl.Schnell, einfach, zuverlässig. HikariCP ist ein produktionsbereiter JDBC-Verbindungspool ohne Overhead. Mit etwa 165 KB ist die Bibliothek sehr leicht. Lesen Sie hier, wie wir das machen.
„Einfachheit ist Voraussetzung für Zuverlässigkeit.“
- Dr. Edsger Dijkstra
Wichtig
Um den seltenen Fall zu vermeiden, dass der Pool auf Null geht und sich nicht erholt, muss TCP-Keepalive konfiguriert werden. Einige JDBC-Treiber unterstützen dies über Eigenschaften, zum Beispiel tcpKeepAlive=true bei PostgreSQL, es kann aber in jedem Fall auch auf Betriebssystemebene konfiguriert werden. Für ein besseres PostgreSQL-Erlebnis siehe Festlegen von OS TCP Keepalive und/oder TCP Keepalive.
Java 11+ Maven-Artefakt:
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >6.2.1</ version >
</ dependency >Java 8 Maven-Artefakt ( Wartungsmodus ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP</ artifactId >
< version >4.0.3</ version >
</ dependency >Java 7 Maven-Artefakt ( Wartungsmodus ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java7</ artifactId >
< version >2.4.13</ version >
</ dependency >Java 6 Maven-Artefakt ( Wartungsmodus ):
< dependency >
< groupId >com.zaxxer</ groupId >
< artifactId >HikariCP-java6</ artifactId >
< version >2.3.13</ version >
</ dependency >Oder hier herunterladen.
Mikrobenchmarks wurden erstellt, um den Overhead von Pools mithilfe des JMH-Mikrobenchmark-Frameworks zu isolieren und zu messen. Sie können sich das HikariCP-Benchmark-Projekt für Details ansehen und die Benchmarks selbst überprüfen/durchführen.
DataSource.getConnection() / Connection.close() definiert.Connection.prepareStatement() , Statement.execute() , Statement.close() definiert.
Analyse von HikariCP v2.6 im Vergleich zu anderen Pools in Bezug auf eine einzigartige „Spike-Demand“-Last.
Die Umgebung des Kunden verursachte hohe Kosten für den Erwerb neuer Verbindungen und erforderte einen Pool mit dynamischer Größe, erforderte aber dennoch eine Reaktionsfähigkeit auf Anforderungsspitzen. Lesen Sie hier mehr über den Umgang mit Nachfragespitzen.
Auch bekannt als „Was Sie wahrscheinlich nicht über die Dimensionierung von Verbindungspools wussten“ . Sehen Sie sich ein Video der Oracle Real-world Performance-Gruppe an und erfahren Sie, warum Datenbankverbindungen nicht so zahlreich sein müssen, wie es oft der Fall ist. Tatsächlich wirken sich zu viele Verbindungen eindeutig und nachweisbar negativ auf die Leistung aus; ein 50-facher Unterschied im Fall der Oracle-Demonstration. Lesen Sie weiter, um es herauszufinden.
Wir möchten den Jungs von WIX für den unaufgeforderten und ausführlichen Bericht über HikariCP in ihrem Engineering-Blog danken. Schauen Sie doch mal vorbei, wenn Sie Zeit haben.
Lesen Sie unsere interessante Pool-Challenge „Datenbank ausgefallen“.
Open-Source-Software wie HikariCP konkurriert wie jedes andere Produkt auf dem freien Markt. Wir verstehen es. Wir verstehen, dass Produktentwicklungen, sobald sie veröffentlicht werden, oft kooptiert werden. Und wir verstehen, dass Ideen aus dem Zeitgeist entstehen können; gleichzeitig und unabhängig voneinander. Aber auch der Zeitplan für Innovationen, insbesondere bei Open-Source-Projekten, ist klar und wir möchten, dass unsere Benutzer die Richtung des Innovationsflusses in unserem Bereich verstehen. Es könnte demoralisierend sein, zu sehen, wie das Ergebnis von Hunderten Stunden Nachdenken und Forschung so einfach kooptiert wird, und vielleicht ist das Teil eines freien Marktes, aber wir sind nicht demoralisiert. Wir sind motiviert; um die Kluft zu vergrößern.
HikariCP verfügt über vernünftige Standardeinstellungen, die in den meisten Bereitstellungen ohne zusätzliche Optimierungen gut funktionieren. Jede Eigenschaft ist optional, mit Ausnahme der unten markierten „Wesensmerkmale“.
? HikariCP verwendet Millisekunden für alle Zeitwerte.
HikariCP verlässt sich hinsichtlich Leistung und Zuverlässigkeit auf genaue Timer. Es ist unbedingt erforderlich , dass Ihr Server mit einer Zeitquelle wie einem NTP-Server synchronisiert ist. Vor allem, wenn Ihr Server in einer virtuellen Maschine läuft. Warum? Lesen Sie hier mehr. Verlassen Sie sich nicht auf Hypervisor-Einstellungen, um die Uhr der virtuellen Maschine zu „synchronisieren“. Konfigurieren Sie die Zeitquellensynchronisierung innerhalb der virtuellen Maschine. Wenn Sie um Unterstützung zu einem Problem bitten, das auf mangelnde Zeitsynchronisierung zurückzuführen ist, werden Sie auf Twitter öffentlich verspottet.
? dataSourceClassName
Dies ist der Name der vom JDBC-Treiber bereitgestellten DataSource Klasse. Informationen zu diesem Klassennamen finden Sie in der Dokumentation Ihres spezifischen JDBC-Treibers oder in der Tabelle unten. Hinweis: XA-Datenquellen werden nicht unterstützt. XA erfordert einen echten Transaktionsmanager wie Bitronix. Beachten Sie, dass Sie diese Eigenschaft nicht benötigen, wenn Sie jdbcUrl für die DriverManager-basierte JDBC-Treiberkonfiguration der „alten Schule“ verwenden. Standard: keine
- oder -
? jdbcUrl
Diese Eigenschaft weist HikariCP an, eine „DriverManager-basierte“ Konfiguration zu verwenden. Wir sind der Meinung, dass die DataSource-basierte Konfiguration (oben) aus verschiedenen Gründen überlegen ist (siehe unten), bei vielen Bereitstellungen gibt es jedoch kaum einen signifikanten Unterschied. Wenn Sie diese Eigenschaft mit „alten“ Treibern verwenden, müssen Sie möglicherweise auch die Eigenschaft driverClassName festlegen, versuchen Sie es jedoch zunächst ohne. Beachten Sie, dass Sie bei Verwendung dieser Eigenschaft weiterhin DataSource -Eigenschaften zum Konfigurieren Ihres Treibers verwenden können. Dies wird tatsächlich gegenüber den in der URL selbst angegebenen Treiberparametern empfohlen. Standard: keine
? username
Diese Eigenschaft legt den Standard-Authentifizierungsbenutzernamen fest, der beim Abrufen von Verbindungen vom zugrunde liegenden Treiber verwendet wird. Beachten Sie, dass dies für DataSources sehr deterministisch funktioniert, indem DataSource.getConnection(*username*, password) für die zugrunde liegende DataSource aufgerufen wird. Bei treiberbasierten Konfigurationen ist jedoch jeder Treiber anders. Im Fall von Treiberbasiert verwendet HikariCP diese username , um eine user in den Properties festzulegen, die an den DriverManager.getConnection(jdbcUrl, props) -Aufruf des Treibers übergeben werden. Wenn Sie dies nicht benötigen, überspringen Sie diese Methode vollständig und rufen Sie beispielsweise addDataSourceProperty("username", ...) auf. Standard: keine
? password
Diese Eigenschaft legt das Standardauthentifizierungskennwort fest, das beim Abrufen von Verbindungen vom zugrunde liegenden Treiber verwendet wird. Beachten Sie, dass dies für DataSources sehr deterministisch funktioniert, indem DataSource.getConnection(username, *password*) für die zugrunde liegende DataSource aufgerufen wird. Bei treiberbasierten Konfigurationen ist jedoch jeder Treiber anders. Im Fall von Treiberbasiert verwendet HikariCP diese password , um eine password in den Properties festzulegen, die an den DriverManager.getConnection(jdbcUrl, props) -Aufruf des Treibers übergeben werden. Wenn Sie dies nicht benötigen, überspringen Sie diese Methode vollständig und rufen Sie beispielsweise addDataSourceProperty("pass", ...) auf. Standard: keine
✅ autoCommit
Diese Eigenschaft steuert das standardmäßige Auto-Commit-Verhalten von Verbindungen, die vom Pool zurückgegeben werden. Es ist ein boolescher Wert. Standard: wahr
⏳Verbindungs- connectionTimeout
Diese Eigenschaft steuert die maximale Anzahl von Millisekunden, die ein Client (das sind Sie) auf eine Verbindung aus dem Pool wartet. Wird diese Zeit überschritten, ohne dass eine Verbindung verfügbar wird, wird eine SQLException geworfen. Das niedrigste akzeptable Verbindungszeitlimit beträgt 250 ms. Standard: 30000 (30 Sekunden)
⏳ idleTimeout
Diese Eigenschaft steuert die maximale Zeitspanne, die eine Verbindung im Pool im Leerlauf bleiben darf. Diese Einstellung gilt nur, wenn minimumIdle als kleiner als maximumPoolSize definiert ist. Leerlaufverbindungen werden nicht zurückgezogen, sobald der Pool minimumIdle Leerlaufverbindungen erreicht. Ob eine Verbindung als inaktiv eingestellt wird oder nicht, unterliegt einer maximalen Schwankung von +30 Sekunden und einer durchschnittlichen Schwankung von +15 Sekunden. Vor diesem Timeout wird eine Verbindung nie als inaktiv zurückgezogen. Ein Wert von 0 bedeutet, dass inaktive Verbindungen niemals aus dem Pool entfernt werden. Der minimal zulässige Wert beträgt 10000 ms (10 Sekunden). Standard: 600000 (10 Minuten)
⏳ keepaliveTime
Diese Eigenschaft steuert, wie oft HikariCP versucht, eine Verbindung aufrechtzuerhalten, um zu verhindern, dass es durch die Datenbank oder die Netzwerkinfrastruktur zu einer Zeitüberschreitung kommt. Dieser Wert muss kleiner als der maxLifetime -Wert sein. Ein „Keepalive“ erfolgt nur bei einer inaktiven Verbindung. Wenn die Zeit für ein „Keepalive“ für eine bestimmte Verbindung gekommen ist, wird diese Verbindung aus dem Pool entfernt, „angepingt“ und dann an den Pool zurückgegeben. Der „Ping“ ist entweder ein Aufruf der JDBC4-Methode isValid() oder die Ausführung von „ connectionTestQuery . Typischerweise sollte die Dauer außerhalb des Pools im einstelligen Millisekundenbereich oder sogar im Submillisekundenbereich gemessen werden und sollte daher kaum oder gar keine spürbaren Auswirkungen auf die Leistung haben. Der minimal zulässige Wert beträgt 30.000 ms (30 Sekunden), am wünschenswertesten ist jedoch ein Wert im Minutenbereich. Standard: 120000 (2 Minuten)
⏳ maxLifetime
Diese Eigenschaft steuert die maximale Lebensdauer einer Verbindung im Pool. Eine genutzte Verbindung wird nie außer Betrieb genommen, sondern erst dann entfernt, wenn sie geschlossen wird. Bei jeder Verbindung wird eine geringfügige negative Dämpfung angewendet, um ein Massensterben im Pool zu verhindern. Wir empfehlen dringend, diesen Wert festzulegen. Er sollte einige Sekunden kürzer sein als ein von der Datenbank oder der Infrastruktur auferlegtes Verbindungszeitlimit. Ein Wert von 0 gibt an, dass es keine maximale Lebensdauer (unendliche Lebensdauer) gibt, natürlich vorbehaltlich der Einstellung idleTimeout . Der minimal zulässige Wert beträgt 30000 ms (30 Sekunden). Standard: 1800000 (30 Minuten)
? connectionTestQuery
Wenn Ihr Treiber JDBC4 unterstützt, empfehlen wir dringend, diese Eigenschaft nicht festzulegen. Dies gilt für „ältere“ Treiber, die die JDBC4 Connection.isValid() API nicht unterstützen. Dies ist die Abfrage, die ausgeführt wird, unmittelbar bevor Ihnen eine Verbindung vom Pool bereitgestellt wird, um zu überprüfen, ob die Verbindung zur Datenbank noch aktiv ist. Versuchen Sie erneut, den Pool ohne diese Eigenschaft auszuführen. HikariCP protokolliert einen Fehler, wenn Ihr Treiber nicht JDBC4-kompatibel ist, um Sie darüber zu informieren. Standard: keine
? minimumIdle
Diese Eigenschaft steuert die Mindestanzahl inaktiver Verbindungen , die HikariCP im Pool aufrechtzuerhalten versucht. Wenn die Anzahl der inaktiven Verbindungen unter diesen Wert sinkt und die Gesamtzahl der Verbindungen im Pool unter maximumPoolSize liegt, wird HikariCP sein Bestes tun, um schnell und effizient zusätzliche Verbindungen hinzuzufügen. Für maximale Leistung und Reaktionsfähigkeit auf Spitzenanforderungen empfehlen wir jedoch, diesen Wert nicht festzulegen und HikariCP stattdessen als Verbindungspool fester Größe fungieren zu lassen. Standard: wie MaximumPoolSize
? maximumPoolSize
Diese Eigenschaft steuert die maximale Größe, die der Pool erreichen darf, einschließlich inaktiver und verwendeter Verbindungen. Grundsätzlich bestimmt dieser Wert die maximale Anzahl tatsächlicher Verbindungen zum Datenbank-Backend. Ein angemessener Wert hierfür lässt sich am besten durch Ihre Ausführungsumgebung ermitteln. Wenn der Pool diese Größe erreicht und keine inaktiven Verbindungen verfügbar sind, werden Aufrufe von getConnection() bis zu connectionTimeout Millisekunden blockiert, bevor es zu einer Zeitüberschreitung kommt. Bitte lesen Sie die Informationen zur Poolgröße. Standard: 10
? metricRegistry
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie eine Instanz einer Codahale/Dropwizard MetricRegistry angeben, die vom Pool zum Aufzeichnen verschiedener Metriken verwendet werden soll. Weitere Informationen finden Sie auf der Wiki-Seite „Metriken“. Standard: keine
? healthCheckRegistry
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie eine Instanz einer Codahale/Dropwizard HealthCheckRegistry angeben, die vom Pool zum Melden aktueller Gesundheitsinformationen verwendet werden soll. Weitere Informationen finden Sie auf der Wiki-Seite „Health Checks“. Standard: keine
? poolName
Diese Eigenschaft stellt einen benutzerdefinierten Namen für den Verbindungspool dar und erscheint hauptsächlich in Protokollierungs- und JMX-Verwaltungskonsolen, um Pools und Poolkonfigurationen zu identifizieren. Standard: automatisch generiert
⏳ initializationFailTimeout
Diese Eigenschaft steuert, ob der Pool „schnell ausfällt“, wenn der Pool nicht erfolgreich mit einer ersten Verbindung geseed werden kann. Jede positive Zahl wird als die Anzahl der Millisekunden angenommen, die benötigt werden, um zu versuchen, eine erste Verbindung herzustellen. Der Anwendungsthread wird während dieses Zeitraums blockiert. Wenn vor Ablauf dieses Zeitlimits keine Verbindung hergestellt werden kann, wird eine Ausnahme ausgelöst. Dieses Timeout wird nach dem connectionTimeout -Zeitraum angewendet. Wenn der Wert Null (0) ist, versucht HikariCP, eine Verbindung herzustellen und zu validieren. Wenn eine Verbindung hergestellt wird, die Validierung jedoch fehlschlägt, wird eine Ausnahme ausgelöst und der Pool wird nicht gestartet. Wenn jedoch keine Verbindung hergestellt werden kann, wird der Pool gestartet. Spätere Versuche, eine Verbindung herzustellen, können jedoch fehlschlagen. Ein Wert kleiner als Null umgeht jeden ersten Verbindungsversuch und der Pool wird sofort gestartet, während er im Hintergrund versucht, Verbindungen herzustellen. Folglich können spätere Versuche, eine Verbindung herzustellen, scheitern. Standard: 1
❎ isolateInternalQueries
Diese Eigenschaft bestimmt, ob HikariCP interne Poolabfragen, wie z. B. den Verbindungs-Alive-Test, in seiner eigenen Transaktion isoliert. Da es sich in der Regel um schreibgeschützte Abfragen handelt, ist es selten erforderlich, sie in einer eigenen Transaktion zu kapseln. Diese Eigenschaft gilt nur, wenn autoCommit deaktiviert ist. Standard: false
allowPoolSuspension
Diese Eigenschaft steuert, ob der Pool über JMX angehalten und fortgesetzt werden kann. Dies ist für bestimmte Failover-Automatisierungsszenarien nützlich. Wenn der Pool angehalten wird, kommt es bei Aufrufen von getConnection() nicht zu einer Zeitüberschreitung und sie werden angehalten, bis der Pool wieder aufgenommen wird. Standard: false
❎ readOnly
Diese Eigenschaft steuert, ob aus dem Pool abgerufene Verbindungen standardmäßig im schreibgeschützten Modus sind. Beachten Sie, dass einige Datenbanken das Konzept des schreibgeschützten Modus nicht unterstützen, während andere Abfrageoptimierungen bereitstellen, wenn die Verbindung auf schreibgeschützt eingestellt ist. Ob Sie diese Eigenschaft benötigen oder nicht, hängt weitgehend von Ihrer Anwendung und Datenbank ab. Standard: false
❎ registerMbeans
Diese Eigenschaft steuert, ob JMX Management Beans („MBeans“) registriert sind oder nicht. Standard: false
? catalog
Diese Eigenschaft legt den Standardkatalog für Datenbanken fest, die das Konzept von Katalogen unterstützen. Wenn diese Eigenschaft nicht angegeben ist, wird der vom JDBC-Treiber definierte Standardkatalog verwendet. Standard: Treiberstandard
? connectionInitSql
Diese Eigenschaft legt eine SQL-Anweisung fest, die nach jeder neuen Verbindungserstellung ausgeführt wird, bevor sie dem Pool hinzugefügt wird. Wenn diese SQL ungültig ist oder eine Ausnahme auslöst, wird sie als Verbindungsfehler behandelt und die Standardwiederholungslogik wird befolgt. Standard: keine
? driverClassName
HikariCP versucht, einen Treiber über den DriverManager ausschließlich auf der Grundlage von jdbcUrl aufzulösen. Bei einigen älteren Treibern muss jedoch auch der driverClassName angegeben werden. Lassen Sie diese Eigenschaft weg, es sei denn, Sie erhalten eine offensichtliche Fehlermeldung, die darauf hinweist, dass der Treiber nicht gefunden wurde. Standard: keine
? transactionIsolation
Diese Eigenschaft steuert die standardmäßige Transaktionsisolationsstufe der vom Pool zurückgegebenen Verbindungen. Wenn diese Eigenschaft nicht angegeben ist, wird die vom JDBC-Treiber definierte Standard-Transaktionsisolationsstufe verwendet. Verwenden Sie diese Eigenschaft nur, wenn Sie bestimmte Isolationsanforderungen haben, die für alle Abfragen gelten. Der Wert dieser Eigenschaft ist der Konstantenname aus der Connection -Klasse, z. B. TRANSACTION_READ_COMMITTED , TRANSACTION_REPEATABLE_READ usw. Standard: Treiberstandard
⏳ validationTimeout
Diese Eigenschaft steuert die maximale Zeitspanne, die eine Verbindung auf Lebensfähigkeit getestet wird. Dieser Wert muss kleiner als connectionTimeout sein. Das niedrigste akzeptable Validierungs-Timeout beträgt 250 ms. Standard: 5000
⏳ leakDetectionThreshold
Diese Eigenschaft steuert die Zeitspanne, die eine Verbindung außerhalb des Pools sein kann, bevor eine Meldung protokolliert wird, die auf ein mögliches Verbindungsleck hinweist. Ein Wert von 0 bedeutet, dass die Leckerkennung deaktiviert ist. Der niedrigste akzeptable Wert zum Aktivieren der Leckerkennung ist 2000 (2 Sekunden). Standard: 0
➡ dataSource
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie die Instanz der DataSource direkt so festlegen, dass sie vom Pool umschlossen wird, anstatt sie von HikariCP über Reflektion erstellen zu lassen. Dies kann in einigen Dependency-Injection-Frameworks nützlich sein. Wenn diese Eigenschaft angegeben ist, werden die dataSourceClassName Eigenschaft und alle DataSource-spezifischen Eigenschaften ignoriert. Standard: keine
? schema
Diese Eigenschaft legt das Standardschema für Datenbanken fest, die das Schemakonzept unterstützen. Wenn diese Eigenschaft nicht angegeben ist, wird das vom JDBC-Treiber definierte Standardschema verwendet. Standard: Treiberstandard
➡ threadFactory
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie die Instanz von java.util.concurrent.ThreadFactory festlegen, die zum Erstellen aller vom Pool verwendeten Threads verwendet wird. Es wird in einigen eingeschränkten Ausführungsumgebungen benötigt, in denen Threads nur über eine ThreadFactory erstellt werden können, die vom Anwendungscontainer bereitgestellt wird. Standard: keine
➡ scheduledExecutor
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie die Instanz von java.util.concurrent.ScheduledExecutorService festlegen, die für verschiedene intern geplante Aufgaben verwendet wird. Wenn HikariCP mit einer ScheduledThreadPoolExecutor -Instanz bereitgestellt wird, wird empfohlen, setRemoveOnCancelPolicy(true) zu verwenden. Standard: keine
➡ exceptionOverride
Diese Eigenschaft ist nur über die programmgesteuerte Konfiguration oder den IoC-Container verfügbar. Mit dieser Eigenschaft können Sie eine Instanz einer Klasse festlegen, die die Schnittstelle com.zaxxer.hikari.SQLExceptionOverride implementiert und aufgerufen wird, bevor eine Verbindung aufgrund bestimmter Ausnahmebedingungen aus dem Pool entfernt wird. Wenn eine SQLException ausgelöst wird, werden Verbindungen normalerweise aus dem Pool entfernt, wenn bestimmte SQLStates oder ErrorCodes vorhanden sind. Die adjudicate() Methode wird für die SQLExceptionOverride Instanz aufgerufen, die möglicherweise Folgendes zurückgibt: Override.CONTINUE_EVICT . Override.DO_NOT_EVICT oder Override.MUST_EVICT . Außer in ganz bestimmten Fällen sollte Override.CONTINUE_EVICT zurückgegeben werden, damit die standardmäßige Evict/No-Evict-Logik ausgeführt werden kann. Standard: keine
? exceptionOverrideClassName
Mit dieser Eigenschaft können Sie den Namen einer vom Benutzer bereitgestellten Klasse angeben, die die Schnittstelle com.zaxxer.hikari.SQLExceptionOverride implementiert. Eine Instanz der Klasse wird vom Pool instanziiert, um über Verbindungsräumungen zu entscheiden. Eine vollständige Beschreibung finden Sie in der obigen Eigenschaft exceptionOverride . Standard: keine
HikariCP hat viele „Knöpfe“, an denen man drehen kann, wie Sie oben sehen können, aber vergleichsweise weniger als einige andere Pools. Dies ist eine Designphilosophie. Die Designästhetik von HikariCP ist Minimalismus. Im Einklang mit der Designphilosophie „Einfaches ist besser oder weniger ist mehr“ wurden einige Konfigurationsachsen absichtlich weggelassen.
Viele Verbindungspools, darunter Apache DBCP, Vibur, c3p0 und andere, bieten PreparedStatement Caching an. HikariCP nicht. Warum?
Auf der Verbindungspoolebene können PreparedStatements nur pro Verbindung zwischengespeichert werden. Wenn Ihre Anwendung über 250 häufig ausgeführte Abfragen und einen Pool von 20 Verbindungen verfügt, fordern Sie Ihre Datenbank auf, 5.000 Abfrageausführungspläne beizubehalten – und ebenso muss der Pool so viele PreparedStatements und die zugehörigen Objektdiagramme zwischenspeichern.
Die meisten großen Datenbank-JDBC-Treiber verfügen bereits über einen konfigurierbaren Statement-Cache, darunter PostgreSQL, Oracle, Derby, MySQL, DB2 und viele andere. JDBC-Treiber sind in der einzigartigen Lage, datenbankspezifische Funktionen zu nutzen, und fast alle Caching-Implementierungen sind in der Lage, Ausführungspläne über Verbindungen hinweg gemeinsam zu nutzen. Das bedeutet, dass Ihre 250 häufig ausgeführten Abfragen anstelle von 5000 Anweisungen im Speicher und zugehörigen Ausführungsplänen genau 250 Ausführungspläne in der Datenbank ergeben. Clevere Implementierungen behalten auf Treiberebene nicht einmal PreparedStatement Objekte im Speicher bei, sondern hängen lediglich neue Instanzen an vorhandene Plan-IDs an.
Die Verwendung eines Anweisungscache auf der Pooling-Ebene stellt ein Anti-Pattern dar und wirkt sich im Vergleich zu vom Treiber bereitgestellten Caches negativ auf die Leistung Ihrer Anwendung aus.
Ebenso wie das Statement-Caching unterstützen die meisten großen Datenbankanbieter die Statement-Protokollierung über die Eigenschaften ihrer eigenen Treiber. Dazu gehören Oracle, MySQL, Derby, MSSQL und andere. Einige unterstützen sogar die langsame Abfrageprotokollierung. Für die wenigen Datenbanken, die dies nicht unterstützen, stehen mehrere Optionen zur Verfügung. Wir haben einen Bericht erhalten, dass p6spy gut funktioniert, und stellen außerdem fest, dass log4jdbc und jdbcdslog-exp verfügbar sind.
Weitere Informationen zur Konfiguration Ihres Treibers und Systems für eine ordnungsgemäße Wiederherstellung nach einem Datenbankneustart und Netzwerkpartitionsereignissen finden Sie im Rapid Recovery Guide.
Sie können die HikariConfig -Klasse wie folgt verwenden:
HikariConfig config = new HikariConfig ();
config . setJdbcUrl ( "jdbc:mysql://localhost:3306/simpsons" );
config . setUsername ( "bart" );
config . setPassword ( "51mp50n" );
config . addDataSourceProperty ( "cachePrepStmts" , "true" );
config . addDataSourceProperty ( "prepStmtCacheSize" , "250" );
config . addDataSourceProperty ( "prepStmtCacheSqlLimit" , "2048" );
HikariDataSource ds = new HikariDataSource ( config );1 MySQL-spezifisches Beispiel, NICHT VERBATIM KOPIEREN.
oder instanziieren Sie direkt eine HikariDataSource wie folgt:
HikariDataSource ds = new HikariDataSource ();
ds . setJdbcUrl ( "jdbc:mysql://localhost:3306/simpsons" );
ds . setUsername ( "bart" );
ds . setPassword ( "51mp50n" );
...oder Eigenschaftendatei basierend:
// Examines both filesystem and classpath for .properties file
HikariConfig config = new HikariConfig ( "/some/path/hikari.properties" );
HikariDataSource ds = new HikariDataSource ( config );Beispiel einer Eigenschaftendatei:
dataSourceClassName =org.postgresql.ds.PGSimpleDataSource
dataSource.user =test
dataSource.password =test
dataSource.databaseName =mydb
dataSource.portNumber =5432
dataSource.serverName =localhost oder java.util.Properties basierend auf:
Properties props = new Properties ();
props . setProperty ( "dataSourceClassName" , "org.postgresql.ds.PGSimpleDataSource" );
props . setProperty ( "dataSource.user" , "test" );
props . setProperty ( "dataSource.password" , "test" );
props . setProperty ( "dataSource.databaseName" , "mydb" );
props . put ( "dataSource.logWriter" , new PrintWriter ( System . out ));
HikariConfig config = new HikariConfig ( props );
HikariDataSource ds = new HikariDataSource ( config ); Es ist auch eine Systemeigenschaft verfügbar, hikaricp.configurationFile , mit der der Speicherort einer Eigenschaftendatei angegeben werden kann. Wenn Sie diese Option verwenden möchten, erstellen Sie eine HikariConfig oder HikariDataSource -Instanz mit dem Standardkonstruktor und die Eigenschaftendatei wird geladen.
Tipps zur MySQL-Leistung
Wir empfehlen die Verwendung dataSourceClassName anstelle von jdbcUrl , aber beides ist akzeptabel. Wir sagen es noch einmal: Beides ist akzeptabel .
Hinweis: Benutzer der Spring Boot-Autokonfiguration müssen jdbcUrl -basierte Konfiguration verwenden.
Es ist bekannt, dass die MySQL-Datenquelle im Hinblick auf die Unterstützung von Netzwerk-Timeouts fehlerhaft ist. Verwenden Sie stattdessen jdbcUrl -Konfiguration.
Hier ist eine Liste der JDBC DataSource -Klassen für gängige Datenbanken:
| Datenbank | Treiber | DataSource- Klasse |
|---|---|---|
| Apache Derby | Derby | org.apache.derby.jdbc.ClientDataSource |
| Feuervogel | Jaybird | org.firebirdsql.ds.FBSimpleDataSource |
| Google-Schlüssel | Schlüssel | com.google.cloud.spanner.jdbc.JdbcDriver |
| H2 | H2 | org.h2.jdbcx.JdbcDataSource |
| HSQLDB | HSQLDB | org.hsqldb.jdbc.JDBCDataSource |
| IBM DB2 | IBM JCC | com.ibm.db2.jcc.DB2SimpleDataSource |
| IBM Informix | IBM Informix | com.informix.jdbcx.IfxDataSource |
| MS SQL Server | Microsoft | com.microsoft.sqlserver.jdbc.SQLServerDataSource |
| Stecker/J | ||
| MariaDB | MariaDB | org.mariadb.jdbc.MariaDbDataSource |
| Orakel | Orakel | oracle.jdbc.pool.OracleDataSource |
| OrientDB | OrientDB | com.orientechnologies.orient.jdbc.OrientDataSource |
| PostgreSQL | pgjdbc-ng | com.impossibl.postgres.jdbc.PGDataSource |
| PostgreSQL | PostgreSQL | org.postgresql.ds.PGSimpleDataSource |
| SAP MaxDB | SAFT | com.sap.dbtech.jdbc.DriverSapDB |
| SQLite | xerial | org.sqlite.SQLiteDataSource |
| SyBase | jConnect | com.sybase.jdbc4.jdbc.SybDataSource |
Hinweis: Play 2.4 verwendet jetzt standardmäßig HikariCP. Für das Play-Framework ist ein neues Plugin erschienen. play-hikaricp. Wenn Sie das hervorragende Play-Framework verwenden, verdient Ihre Anwendung HikariCP. Vielen Dank an das Edulify-Team!
Ein neuer Clojure-Wrapper wurde von tomekw erstellt und kann hier gefunden werden.
Ein neuer JRuby-Wrapper wurde von tomekw erstellt und kann hier gefunden werden.
Google-Diskussionsgruppe HikariCP hier, wachsende FAQ.
Vergessen Sie nicht das Wiki für zusätzliche Informationen wie:
⇒ Java 8+ (Java 6/7-Artefakte befinden sich im Wartungsmodus)
⇒ slf4j-Bibliothek
Hochleistungsprojekte können nie genug Werkzeuge haben! Wir bedanken uns bei folgenden Unternehmen:
Vielen Dank an ej-technologies für ihren hervorragenden All-in-One-Profiler JProfiler.
YourKit unterstützt Open-Source-Projekte mit seinem voll ausgestatteten Java Profiler. Klicken Sie unten auf das YourKit-Logo, um mehr zu erfahren. 
Bitte führen Sie Änderungen durch und senden Sie Pull-Anfragen vom dev -Branch statt vom master . Bitte stellen Sie Ihren Editor so ein, dass er Leerzeichen anstelle von Tabulatoren verwendet, und halten Sie sich an den scheinbaren Stil des Codes, den Sie bearbeiten. Der dev ist immer „aktueller“ als der master , wenn Sie ein Leben am Rande leben möchten.
