Java Persistence Framework Benchmarks

0

Próbuję znaleźć jakieś benchmarki porównujące Persistence Frameworks, ORMy , nie ORMy itp.
Zakładam, że JDBC będzie najszybsze.

np. porównanie Hibernate, JOOQ i MyBatis .

Czy ma ktoś takie porównanie?

0

Ale co mają porównywać? Szybkość wykonania SQLi, zajmowaną pamięć, czas przetworzenia żądania (SQL+mapowania)? To jest na tyle złożony problem, że trzeba by jakoś określić reguły i cele.

0

Głównie czas wykonania.

W zasadzie to chciałbym odpowiedzieć na pytanie czy zostawiając Hibernate za sobą to mógłbym zyskać na wydajności używając czegoś innego.

Ogólnie to dość szczęśliwie używało mi się zawsze Spring Data JPA.
Problemy z wydajnością jakoś mnie nigdy drastycznie nie dotknęły. Ale z tego co wyczytałem to niekiedy Hibernate był zamieniany na wywołania JDBC jeśli nie dawał rady.

0

ORM to jeden z elementów architektury systemu. Co do zasady zawsze będzie wprowadzał pewne opóźnienie bo jest warstwą pośrednią. Aby porównać te narzędzia/frameworki, powinieneś bardzo dokładnie ustalić warunki. W praktyce i tak tzw. "dobry ORM" (świadome uogólnienie), umożliwia dodatkowe operacje optymalizujące zapytanie jeśli realizowane normalną drogą będzie zbyt skomplikowane.
A tak na marginesie, nie jest to przypadkiem objaw przedwczesnej optymalizacji? :-) Wąskie gardło przetwarzania wychodzi dopiero po jakiś konkretnych pomiarach na danych zbliżonych do produkcyjnych :-)

0

Pytam tak ogólnie bez żadnego kontekstu.

Mi Spring Data JPA zawsze było wygodnie, z tym, że ponoć wygoda to nie wszystko ;)

3

Spring Data JPA domyślnie używa Hibernate jako implementacji JPA, zatem nie tędy droga. Zresztą wymiana implementacji na nap. EclipseLink nie da za wiele jeżeli jeden z modeli, relacyjny albo obiektowy, jest słabo zaprojektowany. Oczywiście jeżeli usuniemy JPA i użyjemy np. Spring JDBC Template, to będziemy mieć większą kontrolę nad zapytaniami. Jednocześnie jednak utracimy automatyzację leniwego ładowani i tym samym częściej:

  • będziemy mieli problem N+1, albo
  • będziemy musieli samodzielnie napisać skomplikowane mapery.

W obu przypadkach możemy ostatecznie wylądować z kodem mniej wydajnym albo co gorsza znanie trudniejszym w utrzymaniu. Należy też pamiętać, że JPA daje nam możliwości wykorzystywania SQLa za pośrednictwem NativeQuery. Pozwala, to na dokonanie optymalizacji zapytań tylko tam gdzie rzeczywiście zdiagnozujemy problem.

A jak diagnozować problemy?

Po pierwsze można włączyć statystyki JPA. Przy czym obciąża to system i najlepiej jest to robić na wydzielonej maszynie testowej.
Po drugie analiza generowanych zapytań i ich planów. Bardzo często można ulepszyć zapytania wymuszając na JPA użycie hintów.
Po trzecie analiza modelu relacyjnego. O tym zapomina wielu programistów. Sprawdzić indeksy, użycie pamięci, strukturę. Często jest tak, że model obiektowy jest przenoszony do bazy danych jeden do jednego, co w efekcie prowadzi do nieoptymalnego modelu relacyjnego.
Po czwarte analiza modelu obiektowego. Czy aby na pewno jest on prawidłowo mapowany i optymalny z punktu widzenia Javy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1