Database
SQL
SQL Tuning
•
Spring&SpringBoot
Documentation
OpenAPI Specification(OAS)
Test
TDD
Test Lectures
DB
JPA
•
프로젝트 규모가 커질수록 JPA의 한계점이 더 명확해짐
성능 이슈 발생: PostgreSQL에서 대용량 데이터(1200만 행) 검색 시 JPA 쿼리 변환으로 인한 성능 저하 (100ms vs 10-20초)
결과적으로 복잡한 쿼리는 네이티브 쿼리를 사용하게 되며, JPA는 단순한 쿼리에만 사용하게 됨
결론: JPA가 나쁘진 않지만, SQL과 JPA/HQL 모두에 대한 이해가 필요하며 Hibernate나 Spring Data를 맹신해서는 안 됨
The bigger my projects, the bigger my understanding of JPA and the more I don't want to use it.
Performance issues is one of them. For example, and case ignore like search in postgres should be using an ilike combined with a trigrams index. Unfortunately, jpa decides to turn my query into an upper/upper query, which even with indexes doesn't perform well. (The difference being 100ms vs 10-20 seconds on a dataset of 12 million rows).
More and more of my queries are native queries now, and only my simplest queries are still jpa and spring data, and things get even worse when using Kotlin immutable data structures, which basically every collection in kotlin is.
I'm not saying it's bad, I've done many projects with spring data / hibernate. It's just that you need to know both sql and jpa or/and hql, any you can't trust hibernate or spring data to do the right thing for you.
Here's a hill I am willing to die on: for standard business applications, (unscientific) 90% of problems with ORMs just vanish if you just model proper aggregate boundaries with your persistent types. Most projects I see that struggle with ORMs have classes that connect entities to entities to entities to entities and blame the ORM that it produces tons of joins and loads too much data. Then they switch to lazy loading and things get worse. None of this has to happen if you define (persistent) aggregates according to your domain. Inter-aggregate relationships via IDs, everything but that eagerly loaded, relationships resolved via application code or via custom queries loading data into DTOs.
The success of the group chanting "Just switch to plain JDBC, JdbcTempalte, jOOQ!" does not necessarily come from the switch of technologies (don't get me wrong, those are just fine) but the fact that usually load way more focussed sets of data. You simply can't have both: a domain model that tries to refer to everything but the world and efficient data access. Moving to a lower-level abstraction simply makes these overreaching webs of objects harder to materialize, and thus lets developers not do that. But sure you can just throw that sea of interconnected entities to poor Hibernate and then blame it for not being able to turn that mess into a delicious cake.
So yes, you can build large applications using (Spring Data) JPA. The key is not the technology, but creating boundaries on different levels of abstraction. Your domain type structure is just one of those. If you fancy the lower-level abstractions, Spring Data JDBC provides a great alternative. It's not a general purpose JDBC-level API, but rather builds on the notion of aggregates and repositories. I.e. it nudges you into what I described above. Plus it integrates nicely with all the delicious JDBC stuff (jOOQ, MyBatis, Querydsl) that the Java world has to offer.
Regarding Jackson, I have less of a strong opinion. One thing I strongly value about it is that – as convoluted as the internals might look in the first place – I've hardly ever run into a situation in which I wasn't able to make it jump through hoops I wanted it to jump through, no matter how crazy those are. Other libs might work just fine as well, likely even more efficient in some cases, probably as they don't want or have to support some edge cases and thus avoid a bit of internal complexity. Keep in mind though that almost every issue you'll face with Jackson has been discussed on the internet already. Most often, the community around it is a library's greatest asset.
One thing I'd still strongly recommend – much stronger than on the persistence side of things – is to use dedicated types for the representations to provide to your clients. In contrast to the database, for which the development team often owns the target model (the table structure) these days and can thus modify both in sync, you won't be able to do that with API representations as you likely don't control the clients.
HTH
