SQL vs ORM ?

Backend 개발자로 데이터를 다루는 업무를 많이 해봤다면, 
한번쯤 고민해봤을 주제라 생각하는데요

"SQL vs ORM"

ORM 진영과 SQL 진영의 열띤 토론 배틀에 참여했었던 1인으로서, 개인적으로 2년 넘게 고민해온 주제였는데요, orm 과 sql 로 데이터를 조회했을 때, 걸리는 성능 비교와, 저하 원인에 대한 글을 써봤습니다.

글을 작성하면서, ORM 만이 가지는 '특별한 장점' 과, ORM 의 '성능개선 포인트' 에 대해서도 알게 되었는데, 해당 내용은 2편에서 이어지는데 한번 기웃 해주시면 감사하겠습니다 (꾸벅)

[사내 블로그]

https://onepredict.github.io/sql-orm/


[개인 블로그]

https://www.owl-dev.me/blog/66

SQL VS ORM

Onepredict

SQL VS ORM

더 많은 콘텐츠를 보고 싶다면?

또는

이미 회원이신가요?

2023년 4월 24일 오전 6:13

 • 

저장 340조회 25,917

댓글 5

  • Silver bullet이 없듯, 모든 기술은 trade-off가 존재합니다. 그러면 성능의 손해를 보는 ORM을 많이 사용하는 이유가 무엇일까? 이것을 장진수님은 단순히 한 트랜잭션에 쿼리를 모아서 처리한다라는 장점 하나를 드셨는데 이것 만으로 트레이드 오프의 가치가 있을까요? 너무 가볍게 접근하신 것 같습니다 파이썬이든, 스칼라든 코틀린이든 결국 oop 언어로 비지니스 어플리케이션을 설계하면 결국 객체지향 설계를 하게 됩니다. 그러면 이 객체를 관계형db에 저장을 해야 하죠 예로 CRUD를 ORM으로 안쓰고.. SI처럼.. SQL을 쓴다고 하면.. 고객의 요청으로 테이블에 필드 하나를 추가 한다고 하면 ORM은 클래스에 필드 하나만 추가 하면 되지만, SQL은 해당 테이블을 쓰는 모든 SQL을 찾아서 전부 수정을 해야 합니다 이러면 객체지향개발이 아니라 SQL의존적인 개발이 되어버립니다. 극단적인 SI의 예를 들면, DBA가 스펙을 보고 쿼리를 다 짜놓으면, 개발자는 객체를 DB 테이블에 맞춰서 모델링하는 경우도 허다합니다 이러면 처음 설계와 맞는 프로그램이 만들어질까요? ORM 정의로 검색해서 가장 많이 나오는 "패러다임 불일치"도 이유입니다 객체지향의 객체와 RDB는 상속,객체의 연관관계, 타입, 데이터 식별 방법 등 많은 부분에서 아예 다른 존재입니다. 한 예로, 파이썬의 객체는 자유롭게 객체들의 Graph를 탐색 가능합니다 (oop니까 당연하게도) A객체는 B에서 Z까지 객체 그래프로 접근이 가능하고 현재 서비스는 B, C는 필수로 필요로 하고 각 상태에 따라 선택적으로 D~Z의 일부분을 필요로 합니다 SQL은 처음실행에서 탐색 range가 fix됩니다. 처음에 조인 테이블에서 B,C,D를 가져와서 object를 생성하면 여기서 D접근이 안됩니다 (ORM이면 당연히 접근이 되죠) 그렇다고 B~Z를 전부 Join해서 가져온다는 것은 어마어마한 낭비가 됩니다. 결국 SI처럼 ㅎ B,C를 먼저 select가져오고 선택에 따라 다시 select하는 식으로 만들게 되는 DB에 맞춘 SQL 의존 개발이 이뤄지게 됩니다. 데이터 식별도 간단한 예로 들어봅시다 사용자 테이블의 id가 1인 정보를 가져오는 똑같은 sql 쿼리를 사용해서 user1, user2를 new로 생성하면 oop에서 user1과 user2는 equal이 false가 되어버립니다. 같은 사용자인데도 다른 객체로 인식하죠. (ORM이라면 equal이 되었겠죠) 결론적으로, OOP적으로 모델링을 할수록 SQL 쿼리와 Mapping작업들이 기하급수적으로 늘어나게 됩니다. 위의 문제를 현실적으로 해결해 주는 것이 현재 ORM 프레임워크라고 할 수 있겠습니다.

    @안근창 안녕하세요 근창님 저의 블로그에 관심있게 봐주셔서 감사해요!! 제가 놓친것도 있고 2편에 말하고 싶었던 ORM 의 장점의 맥락과 비슷한 부분을 잡아주신것도 있네요!. 'Clean Architecture' 책에서 나오는 설계에 의하면 비즈니스 로직을 DB SQL 같은 곳에 담는게 아닌, 코드에 녹이도록 가이드 하고 있지만, 저 방식은 사실 이러한 패러다임을 역행하는 느낌을 저도 지울 수는 없었어요. 어쩌면 제조업(MES) 의 특수성 일 것 같기도 하지만 복잡한 반도체 비즈니스 공정로직을 하나의 서비스에 코드로서 모두 심는것은 불가능하지 않을까 하던 고민을 한번 해봤었어요. 하나의 트랜잭션내에 많은 부하를 일으키지 않는 조그마한 CRUD 관점에서는 사실 성능 상에서도 말씀해주신 부분에서도 ORM이 더 좋은 merit 를 가져가고 저도 자주 사용합니다 ㅎㅎ 이번 글은 조회속도에 영향을 받는 OLAP 서비스에 좀 더 특화된 부분에서 , ORM 과 Raw SQL 의 실제 성능 차이가 어느정도로 발생하는지 한번 깊게 파본 내용이었습니다. Trade Off 관계를 생각하면 저도 승자는 없다고 생각해요. 다시한번 좋은 인사이트를 남겨주셔서 감사해요!!

    @장진수 안녕하세요 답변 감사합니다 저는 클린 아키텍처가 맞다고 생각하고 헥사고날 아키텍처를 지향합니다. 물론 작은 사이드 프로젝트에서는 오히려 배보다 배꼽이 큰 오버헤드로 일정이 길어지는 악영향이 있었지만 말씀하신대로 복잡한 비지니스 로직에서는 더더욱 필요로 합니다. 약간 오버엔지니어링이 아닌가 싶을 정도로 복잡해지지만... 사람이 적응의 동물이라.. 또 익숙해지더군요.. 복잡해지면 엔티티가 또 수십개가 되기 때문에 이렇게 큰 경우에는 도메인 주도 개발(DDD)로 개발까진 아니더라도 이벤트 스토밍을 하시고 도메인/어그리게이트/엔티티로 나눠놓으시면 각 도메인 별 서비스들의 조합으로 구성하실 수 있습니다. 다만 저도 대형 포탈과 커머스 경험 뿐이고 제조업의 경험은 없기 때문에 제조업의 특수성은 모른다는 전제로 말씀드립니다^^ 제가 다루는 서비스에서는 OLAP에서는 SELECT만 하게 되므로 트랜잭션을 read-only로 해놓는 것으로도 충분히 해결되었습니다. (레코드 갯수는 5천만~7천만 이쪽 저쪽) 현재 OLAP 트랜잭션이 read-only인지 한 번 확인 해주세요 그리고 OLTP의 경우라도... ORM으로 도저히 답이 안나오는 (일간 정산 배치 등;) 부분은 저도 결국 그냥 sql로 처리했습니다^^ 그래서 또 OLAP/OLTP 안에서도 또 case by case가 있는 것 같습니다

    @안근창 크.. 능력자이신것 같은 스멜이 물씬 풍기는분이군여. 저도 클린 아키텍처, 헥사고날 아키텍처를 지향하는 편이라 덕분에 좋은 인사이트 얻어갑니다 (꾸벅)

  • 궁금했던 내용인데 재밌게 읽어보겠습니다 고맙습니다 ~ ~