ISA //
[sql 연결이 많아 질 수록 네트워크 비용이 증가한다지만 sql에서 많은 처리를 할 수 록 전체적인 퍼포먼스가 떨어집니다. Sql서버에서 작동하는 방식이 서버처리 보다 느린편이라 그렇습니다]
이 부분은 좀 이상한 것 같네요. sql연결이 많아질 수록 네트워크 비용이 증가한다는 말은 이론적인 부분이고, 실제로는 영향도가 없다시피합니다.
DB서버에서 작동하는 방식은 애플리케이션서버보다 월등히 빠릅니다. 애초에 데이터를 다루기위한 소프트웨어인데, 애플리케이션보다 느릴 수가 없어요. 그래서 DB에서 일괄로 처리하는게 성능적인 측면에서도 좋습니다. 만약, 역설적으로 애플리케이션이 빠르다면, DB서버가 너무 느린게 아닌지 의심해볼 필요가 있습니다.
[ 실제 sql성능상에도 10만건에서 100만건 정도 row가진 데이터 조회하면 조건절 하나마다 성능이 급격히 떨어지는걸 경험한 입장에선 납득이 안갑니다]
이건 쿼리의 문제일 수 있습니다. 10만건에서 100만건이 되어서, 성능이 급격하게 떨어졌다는 건, 로우 한줄 한줄마다 비효율적인 작업이 들어간겁니다. 일반적으로는 데이터량이 많아졌다고해서 느려지지는 않습니다. 그리고 겨우 100만건이거든요. 데이터가 많아질 수록 느려진다는 것 자체가 대용량 집계성 쿼리로 배치가 아니면, 문제가 있는 쿼리입니다. 튜닝이 필요합니다.
[대부분이 흔히 where로 필요한 데이터만 가져오는게 효율적이라 말하지만 솔직히 서버 기억공간(성능) 잡아먹는 거에는 그게 맞을지
몰라도 단순 sql상에서는 오히려 where문을 거는게 더 시간이 오래걸리더군요. 서버에서 처리하는게 빠르고요]
이 부분도 말이 안됩니다. 당연히 where 절에서 필요한 데이터만 먼저 가져오는게 훨씬 더 빠릅니다. 테이블을 풀스캔으로 가져온 다음에 애플리케이션에서 필터로 제거한다는 말이... 네트워크 트래픽을 더 발생시킬뿐더러, DB의 필터 성능이 절대 애플리케이션보다 떨어질 수가 없기 때문입니다.
DB서버도 메모리에 자주 이용하는 데이터(블럭, 테이블)을 올려서 사용합니다. 하드디스크에 매번 읽고 쓰지 않고, 그냥 메모리에 통으로 올려서 사용합니다. 그리고 쓰기 작업도 매번 디스크에 쓰지 않고, 로그파일로 append 해놓고 배치성으로 기록하고요. 같은 스펙이라도 애플리케이션서버보다 월등한 성능을 보여줍니다.
그리고 페이징하는데 성능은 언급하셨는데, 페이징에 성능이 떨어진다면 그건 아직 페이징처리를 제대로 하지 않았기 때문이 아닐까 합니다. 단일 쿼리 기준으로 '마지막 페이지'만 아니면 페이지 성능이 떨어질 이유는 없습니다.