A Comparative Performance Evaluation of SQL and NoSQL Databases Under Different Indexing and Cache Conditions
이 연구는 다양한 데이터 세트 크기, 인덱싱 전략 및 캐시 조건에 걸쳐 MySQL 8.0.46과 MongoDB 8.0.32를 벤치마킹하여, MongoDB가 대량 쓰기에서 탁월한 성능을 보이는 반면 두 시스템 모두 조회를 위한 인덱싱으로부터 상당한 이득을 얻는다는 점을 밝혀냈으며, 궁극적으로 데이터베이스 성능은 어느 한 모델에 대해 보편적으로 우월하기보다는 매우 맥락 의존적임을 입증한다.
원본 논문은 CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
디지털 세상에서 거의 모든 행동은 흔적을 남깁니다. 구매, 로그인, 메시지 전송 등 각각의 사건은 거대한 전자식 서류함인 데이터베이스에 저장되어 현대 삶의 기억을 간직합니다. 이러한 시스템을 원활하게 운영하기 위해 엔지니어들은 두 가지 주요 유형의 파일링 시스템 중 하나를 선택해야 합니다. 한 유형은 관계형(relational)으로 알려져 있으며, 전통적인 스프레드시트처럼 엄격한 행과 열을 가진 경직된 테이블로 데이터를 구성합니다. 다른 하나는 NoSQL이라 불리며, 형태와 크기가 다양할 수 있는 유연하고 독립적인 문서 형태로 정보를 저장합니다. 수년 동안 어떤 시스템이 더 빠르거나 더 나은지에 대한 논쟁이 지속되어 왔습니다. 그러나 그 답은 결코 단순하지 않은데, 왜냐하면 속도는 전적으로 당신이 시스템에 무엇을 요청하는지, 그리고 시스템이 얼마나 많은 데이터를 검색해야 하는지에 달려 있기 때문입니다.
최근 한 연구는 이론이 아닌 통제된 실험을 통해 이 질문에 대한 답을 내놓고자 했습니다. 연구자 아미르 칸(Amir Khan), 사와이라 굴(Sawaira Gull), 아루즈 샤다디(Arooj Shahzadi)는 두 인기 시스템인 MySQL과 MongoDB가 동일한 조건에서 어떻게 작동하는지 확인하기 위해 단일 컴퓨터 위에 테스트 환경을 구축했습니다. 그들은 단순히 어느 것이 더 빠른지를 묻지 않았습니다. 대신 데이터의 양이 작은 더미에서 거대한 산으로 늘어날 때 속도가 어떻게 변하는지, 그리고 정보를 빠르게 찾도록 돕는 특수 지름길인 인덱스(index)의 사용이 결과를 어떻게 바꾸는지 물었습니다. 그들은 세 가지 특정 작업에 대해 테스트했습니다: 대량의 새로운 데이터를 시스템에 쏟아붓는 것, 특정 이름을 기반으로 단일 레코드를 찾는 것, 그리고 많은 레코드를 그룹화하여 합계를 계산하는 것입니다.
연구진은 합성 트랜잭션 기록을 생성하여 만 개, 십만 개, 백만 개의 항목을 포함하는 세 개의 별도 데이터셋을 만들었습니다. 이 기록들을 두 데이터베이스 시스템에 로드하고 각 작업을 완료하는 데 걸리는 시간을 측정했습니다. 한 번에 모든 데이터를 시스템에 쓰는 과정을 포함하는 첫 번째 테스트에서, 문서 기반 시스템인 MongoDB가 일관되게 더 빠른 것으로 나타났습니다. 백만 개의 레코드를 처리할 때, 관계형 시스템인 MySQL은 거의 30초가 걸린 반면, MongoDB는 약 12.5초 만에 작업을 마쳤습니다. 이러한 차이는 데이터셋이 작든 크든 동일하게 유지되었으며, 이는 순수한 데이터 주입(ingestion)의 경우 문서 기반 접근 방식이 이 특정 설정에서 명확한 우위를 점하고 있음을 시사합니다.
두 번째 테스트는 특정 고객 ID를 찾는 것과 유사하게 단일 레코드를 찾는 데 초점을 맞추었습니다. 여기서 연구진은 도움 없이 찾을 때와 인덱스의 도움을 받아 찾을 때의 시간을 측정했습니다. 인덱스가 없으면 시스템은 일치하는 항목을 찾기 위해 모든 레코드를 훑어야 합니다. 데이터가 백만 개로 늘어남에 따라 이 검색은 매우 느려져 두 시스템 모두 0.5초 이상이 소요되었습니다. 그러나 연구진이 단일 필드 인덱스(각 ID의 위치를 직접 가리키는 간단한 목록)를 추가하자 결과는 극적으로 변했습니다. 레코드를 찾는 시간은 두 시스템 모두 1밀리초 남짓으로 급감했습니다. 99%를 초과하는 이 감소는 단순 조회(lookup)의 경우, 데이터베이스의 종류보다 검색을 안내할 좋은 지도가 있는지 여부가 훨씬 더 중요하다는 것을 보여주었습니다.
세 번째 테스트는 필터링된 집계(filtered aggregation)를 포함하는 더 복잡한 작업이었습니다. 연구진은 시스템에 특정 카테고리의 모든 트랜잭션을 찾아 상태별로 그룹화하고 총액을 합산하도록 요청했습니다. 이 작업은 단순히 데이터를 찾는 것을 넘어 분류와 계산까지 필요하기 때문에 더 어렵습니다. 이 시나리오에서는 결과가 덜 균일했습니다. 작은 데이터셋의 경우 관계형 시스템이 때때로 더 빨랐지만, 데이터가 백만 개로 늘어나자 문서 기반 시스템이 크게 앞서 나갔습니다. 문서 시스템은 약 300밀리초 만에 작업을 완료한 반면, 관계형 시스템은 1초 이상이 걸렸습니다.
아마도 가장 놀라운 발견은 이 세 번째 테스트의 가장 큰 데이터셋에서 나타났습니다. 연구진이 관계형 시스템의 속도를 높이기 위해 카테고리 필드에 인덱스를 사용했을 때, 작업은 인덱스가 없을 때보다 오히려 더 느려졌습니다. 인덱스를 사용했을 때 시스템은 1초 이상이 걸린 반면, 인덱스가 없을 때는 약 700밀리초가 걸렸습니다. 이 역설적인 결과는 오류가 아니었습니다. 연구진은 독립적으로 테스트를 반복하여 인덱스가 실제로 이 특정 구성에서 지연을 일으키고 있음을 확인했습니다. 이 특정 유형의 복잡한 계산에서는 인덱스를 사용하는 오버헤드가 그 이점을 상쇄하는 것으로 보이며, 이는 단순히 "어느 쪽이 더 빠르다"라는 결론으로는 놓칠 수 있는 미묘한 차이입니다.
연구는 또한 시스템이 이미 "웜(warm)" 상태, 즉 최근에 유사한 요청을 처리하여 데이터를 메모리에 준비해 둔 상태일 때 어떻게 작동하는지도 조사했습니다. 이러한 조건에서 두 시스템 모두 빨라졌지만, 개선 정도는 달랐습니다. 문서 시스템은 집계 속도에서 상당한 향상을 보인 반면, 관계형 시스템은 더 완만한 이득을 보였습니다. 이러한 발견은 성능이 소프트웨어 자체의 고정된 속성이 아니라, 데이터 크기, 쿼리의 유형, 인덱스의 존재, 그리고 시스템 메모리의 현재 상태 사이의 상호작용에 따른 유동적인 결과임을 뒷받침합니다.
결론적으로, 이 연구는 보편적인 승자는 없다고 결론짓습니다. 이 두 가지 데이터베이스 모델 사이의 선택은 단 하나의 속도 테스트만으로 결정될 수 없습니다. 만약 목표가 방대한 양의 새로운 데이터를 빠르게 주입하는 것이라면, 문서 기반 시스템이 뚜렷한 우위를 보였습니다. 만약 목표가 단일 레코드를 검색하는 것이라면, 적절한 인덱스가 있는 한 두 시스템 모두 잘 작동합니다. 하지만 대량의 데이터를 포함한 복잡한 계산의 경우, 데이터가 어떻게 구조화되고 인덱싱되는지에 따라 성능이 크게 달라질 수 있습니다. 이 연구는 데이터의 세계에서 적절한 도구는 전적으로 수행하려는 특정 작업에 달려 있으며, 가장 효율적인 길은 브랜드를 선택하는 것이 아니라 수행할 작업의 고유한 형태를 이해함으로써 발견된다는 점을 상기시켜 줍니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.