노드나 스프링 같은 서버에서 데이터 처리하는 것보다 sql로 함수 짜는 게 낫다는 주장이 있더라고요.
그 이유가 엄청난 양의 데이터를 네트워크 태우는 데에 드는 부하라는데
근데 엄청난 데이터를 처리하는 빅테크 기업에서도 sql로 함수를 작성하는 대신에 노드나 스프링 같은 기술을 사용하잖아요.
그러면 네트워크 비용은 신경써야 할 만큼의 크기가 아닌 거 아닌가요?
유의미한 시간 차이가 난다면 빅테크에서도 sql로 함수를 작성할 것 같거든요.
그 이유가 엄청난 양의 데이터를 네트워크 태우는 데에 드는 부하라는데
근데 엄청난 데이터를 처리하는 빅테크 기업에서도 sql로 함수를 작성하는 대신에 노드나 스프링 같은 기술을 사용하잖아요.
그러면 네트워크 비용은 신경써야 할 만큼의 크기가 아닌 거 아닌가요?
유의미한 시간 차이가 난다면 빅테크에서도 sql로 함수를 작성할 것 같거든요.
데이터베이스에서 기능구현하는 미친놈들이 주장하는 헛소리... - dc App
Db에 기능 구현하는 게 성능면에서 더 안좋다면 그 이유를 좀 더 자세히 알 수 있을까요?
성능은 벤치해봐야 알겠지만 아마도 그냥 서버에서 처리하는게 빠를꺼같고 당장 생각나는거는 세션 유지시간하고 트랜잭션의 길이 같은 문제 단일 지점의 장애가 서비스의 모든 장애와 동일하게 되고 유지보수 및 이슈 추적의 난해함 + 등등등등 이있을것 같네 - dc App
그리고 클라이언트로 데이커 서빙하는 과정에서 어처피 백서버 필요하고 만약에 클라이언트가 직접 DB로 붙는 미친 아키텍처로 설계한다면 보안은 개나준 미친회사 되는거지 - dc App
*데이터 서빙 - dc App
네트워크 비용은 신경 써야하는 비용이지만 db에서 로직 돌리는게 비용이 훨씬 크니까.. 시간이든 유지보수든 성능이든 뭐든 싹다
내가 관리하는 DB중에 하나가 복잡도 높은 비즈니스 로직이 가득한데 다 DB에 프로시저로 구현되어 있고 내부에서 스케줄링 돌면서 동작하는 서비스 있는데 진짜 Joat임 - dc App
DDD(DB Driven Design) 라네요~
걍 왠만하면 그냩 데이터 가져와서 서버에서 가공하는게 나아요? - dc App
웬만하면도 아니고 그냥 DB에 로직구현하는게 나은경우는 거의 없을꺼임 - dc App
*아예 - dc App
프로그래밍기능도 지원하고 변수, 임시테이블하고 쿼리도 이리저리 돌리면 로직구현은 됨 ㅇㅇ - dc App
놀랍게도 오키가면 프로시저 좋아하는 양반들 많다
프로시저가 문제가아니라 프로시저안에 온갖 해괴한짓을 해놓는게... - dc App
순수 성능에선 db에서 치는게 빠를수도 있음. 근데 요즘은 k8s, 중간 캐시 레이어,배치 처리 같은게 대중화되면서 굳이 확장하기 힘든 자원인 db에 부하를 줄 이유가 없지
득보다 실이 너무 많지
좀만 ㅈ같이 만들어두면 제일 먼저 뻗는게 디비임ㅋㅋ