Drastische Unterschiede können Sie erwarten, wenn Sie zwischenspeichern, was gut zwischengespeichert werden kann, und das Zwischenspeichern von Daten vermeiden, die überhaupt nicht zwischengespeichert werden sollten. Wie die Schönheit im Auge des Betrachters liegt, so verhält es sich auch mit der Performance. Hier sind einige Aspekte, die Sie beachten sollten, wenn Sie den Hibernate-AS-Second-Level-Cache-Anbieter verwenden:
Keine benutzerdefinierte Serialisierung – Speicherintensiv
Wenn Sie Second-Level-Caching verwenden, könnten Sie keine schnellen Serialisierungs-Frameworks wie Kryo verwenden und müssen sich an java serializable halten, was scheiße ist.
Darüber hinaus haben Sie für jeden Entitätstyp eine separate Region und innerhalb jeder Region haben Sie einen Eintrag für jeden Schlüssel jeder Entität. Im Hinblick auf die Speichereffizienz ist dies ineffizient.
Fehlt die Fähigkeit, umfangreiche Objekte zu speichern und zu verteilen
Die meisten modernen Caches bieten auch Computing-Grid-Funktionalität, da Ihre Objekte in viele kleine Stücke fragmentiert sind, was Ihre Fähigkeit verringert, verteilte Aufgaben mit garantierter Datenkolokation auszuführen. Das hängt ein wenig vom Grid-Provider ab, wäre aber für viele eine Einschränkung.
Suboptimale Leistung
Je nachdem, wie viel Leistung Sie benötigen und welche Art von Anwendung Sie verwenden, kann die Verwendung des Hibernate Second Level Cache eine gute oder eine schlechte Wahl sein. Gut in Bezug darauf, dass es Plug-and-Play ist ... "irgendwie ..." schlecht, weil Sie nie die Leistung herausquetschen werden, die Sie gewonnen hätten. Auch das Entwerfen umfangreicher Modelle bedeutet mehr Vorabarbeit und mehr OOP.
Eingeschränkte Abfragemöglichkeiten im Cache selbst
Das hängt vom Cache-Anbieter ab, aber einige der Anbieter sind wirklich nicht gut darin, JOINs mit einer anderen Where-Klausel als der ID auszuführen. Wenn Sie beispielsweise versuchen, einen Index für eine Abfrage auf Hazelcast im Speicher zu erstellen, werden Sie sehen, was ich meine.
