SQL 성능을 향상시키기 위해 하드 디스크 속도가 빠르지 않고 많은 양의 RAM을 배치해야하는 이유는 무엇입니까?

사람들은 SQL 서버의 성능을 향상시키기 위해 RAID 5로 가능한 가장 빠른 하드 디스크 등을 구매한다고 계속 말합니다.

그래서 RAID 5와 초고속 고속 하드 디스크 (비용이 많이 들지 않음)에 돈을 쓰지 않고 왜 많은 양의 RAM을 가져 가지 않습니까? 우리는 SQL 서버가 데이터베이스를 메모리에로드한다는 것을 알고 있습니다. 메모리는 하드 디스크보다 훨씬 빠릅니다.

서버에 100GB의 RAM을 넣는 것은 어떻습니까? 그런 다음 RAID 1과 함께 일반 SCSI 하드 디스크를 사용하십시오. 훨씬 저렴하고 빠르지 않습니까?

분석 결과는 어느 정도 빨라질 것입니다. 그래도 다음과 같은 몇 가지 다른 문제를 고려해야합니다.

1. 모든 사람이 충분한 메모리를 확보 할 수있는 것은 아닙니다. 테라 바이트 단위의 데이터가있는 경우 디스크에 일정 시간 동안 저장해야합니다. 데이터가 많지 않으면 속도가 빠릅니다.

2. 데이터베이스의 쓰기 성능은 여전히 ​​디스크에 의해 제한되므로 데이터가 실제로 저장되었다는 약속을 유지할 수 있습니다.

작은 데이터 세트가 있거나 디스크에이를 유지할 필요가 없다면 아이디어에 아무런 문제가 없습니다. VoltDB 와 같은 툴 은 RDBMS 구현에서 오래된 가정이 순수한 인 메모리 성능을 제한하는 오버 헤드를 줄이기 위해 노력하고 있습니다.

(제외 적으로, 데이터베이스 성능을 위해 RAID-5를 사용하라고 말하는 사람들은 아마도 최고의 선택이 아니기 때문에 주제에 대해 듣기에 좋은 사람들이 아닐 것입니다. 읽기 성능은 좋지만 쓰기 성능은 좋지 않습니다. 대부분의 읽기 성능 문제를 해결하기 위해 RAM을 캐싱에 넣을 수 있기 때문에 거의 항상 프로덕션 제약 조건입니다.)

짧은 버전 : 작업 세트 크기를 고려하십시오. 긴 버전 : 데이터가 얼마나 큽니까? 최신 서버의 메모리에 맞을 수 있다면 그렇습니다. 불행히도 가장 큰 Xeon은 현재 2TB의 RAM을 처리 할 수 ​​있으며 더 이상 큰 데이터 세트가 아닙니다. RAM에 전체 작업 세트를 수용 할만큼 큰 기계를 구입할 수 없다면 지갑이 아닌 두뇌 문제를 해결해야합니다.

속도를 원한다면 :

• RAM을 늘리면 최소한 자주 사용하는 인덱스가 RAM에 완전히 들어갈 수 있습니다 (예를 들어, 내가 작업하는 시스템에서 32GB RAM은 350GB 데이터베이스에 충분합니다. 인덱스는 원시 데이터가 아니라 RAM에 필요하기 때문입니다)
• 모든 디스크에 RAID10을 사용하십시오 (더 빠른 디스크가 좋습니다).
• RAID5를 피하십시오
• mdf, ldf 및 temp DB를 이산 스핀들 세트로 분할 (예 : 자체 RAID1 세트의 tempdb, 자체 RAID1 또는 RAID10 스핀들 세트의 ldf, 총 디스크가 4 개 이상인 RAID 10 세트의 경우 mdf)

이 단계를 수행하면 SQL Server가 시작됩니다.

그런 다음 원하는 경우 RAM을 더 추가하십시오 ...하지만 위의 작업을 먼저 수행하면 완료되었음을 알 수 있습니다.

RAM은 새 디스크이고 디스크는 새 테이프입니다.

에서 http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . 6 년 전이었습니다. 예, 우리는 디스크가 크기가 더 느리기 때문에 디스크를 사용하는 것보다 전체 데이터 세트를 RAM으로 유지하고 여러 머신에 샤드하는 데이터베이스 시스템을 가지고 있습니다. 데이터 세트를 디스크에 기록해야하지만 위의 모토에서와 같이 온라인 작업보다 백그라운드 백업 작업과 유사합니다. 내구성은이 데이터베이스에 로그 만 추가하여 달성됩니다 (MongoDB와 Redis는 생각하지만 톤이 더 많습니다).

이 질문은 지난 5-10 년 동안 데이터베이스 아키텍처에서 많은 연구와 개발을 이끌어 낸 기본 질문과 유사합니다. 많은 사용 사례를 위해 전체 데이터베이스를 RAM에 저장하는 것이 가능해 졌기 때문에 데이터베이스는 단순히 기존 상속 아키텍처를 RAM 기반 스토리지에 적용하는 대신 RAM 작업을 중심으로 설계해야합니다.

최근 몇 년 동안 더 작고 더 많은 특수 목적 언어가 널리 채택 된 것처럼, 우리는 더 많은 특수 목적 데이터베이스가 필요한 시대에 접어 들고 있습니다.

이 주제에 대한 자세한 내용은 학술지 The End of a Architectural Era (완전히 다시 작성해야 할 시점)를 참조하십시오 . 읽기 어려운 책은 아닙니다.

이 질문이 SQL Server에 관한 것인지 확실하지 않습니다. 원본 포스터가이를 명확히해야합니다.

Daniel Pittman은 다음과 같이 썼습니다.

작은 데이터 세트가 있거나 디스크에이를 유지할 필요가 없다면 아이디어에 아무런 문제가 없습니다. VoltDB와 같은 툴은 RDBMS 구현에서 오래된 가정이 순수한 인 메모리 성능을 제한하는 오버 헤드를 줄이기 위해 노력하고 있습니다.

RDBMS 구현에서 이전 가정에서 발생하는 오버 헤드를 줄이는 것은 VoltDB 의 설계 목표 였지만 데이터 크기에 대한 아키텍처 제한없이 수평으로 확장되며 스냅 샷 및 명령 로깅을 사용하여 디스크에 지속성을 유지할 수 있습니다.

최소한 데이터 집합의 가장 중요한 부분을 저장할 수있는 충분한 RAM이있는 서버를 확보 할 수 있다면 문제가 없습니다. 또한 RAID 1과 5는 데이터를 정리하는 가장 빠른 방법은 아닙니다. RAID 0이 빠르지 만 데이터베이스를 지우는 파일 시스템 오류 가능성이 높아야합니다. . 충분한 드라이브와 컨트롤러가있는 경우 RAID 0 어레이를 RAID 1 또는 RAID 5로 구성 할 수 있습니다.

여기에서 복제 작업을 수행 할 수도 있습니다. 복잡한 쿼리를 실행하는 하나 이상의 메모리가 많은 서버에 복제하는 디스크가 많은 서버에 대한 쓰기 작업을 수행하십시오.

안타깝게도 RDBMS는 큰 영역에있는 것으로 보이며 수평 적으로 성장하기가 쉽지 않습니다.

이것은 "당신이하는 일에 달려 있습니다"의 경우입니다. 아마도 "올바른"조언은 SQL을 완전히 피하고 memcache / redis / etc를 사용하는 것입니다!

특히 RAM의 전체 작업 세트를 읽을 수있는 경우 추가 RAM이 많은 도움이 될 것입니다. 그렇습니다. 여전히 데이터를 써야하지만 대부분 읽은 경우 쓰기는 디스크 I / O에 대한 경합이 없습니다.

그러나 디스크 성능은 종종 SQL 서버에서 병목 현상이 발생하며 RAM과 같은 다른 요소보다 나중에 업그레이드하기가 어렵습니다 (DIMM으로 완전히 채워지지 않은 서버가있는 경우).

RAID5가 느리다는 것에 대한 의견이 많았지 만 이것이 항상 그런 것은 아니라고 말하고 있으므로 진술을 작성하기 전에주의하십시오. 빠른 RAID 카드와 많은 BBWC를 갖춘 고급 서버는 때때로 RAID10보다 RAID5 (또는 디스크가 4 이상인 RAID50)에서 훨씬 빠릅니다.

수년 동안 개인적으로 느린 RAID5 어레이를 경험했지만 ~ 2009 년에 4 개의 146G SAS 디스크로 DL360 G5를 벤치마킹 한 후 테스트를 다시 확인해야했습니다. 실제로 어레이는 거의 모든 테스트에서 RAID5보다 RAID10보다 빠릅니다. BBWC와 빠른 패리티 계산을 통해 서버는 4 개의 디스크를 RAID10보다 RAID5 어레이로 훨씬 더 효과적으로 사용할 수있었습니다. 일부 테스트에서는 RAID5의 처리량이 50 % 향상되었으며 거의 ​​느리지 않았습니다. 더 느린 테스트는 5-10 % 할인되었습니다.

나는 담요 진술을하는 사람들에게 RAID5가 느리다는 것을 경고하고 모든 사람들이 온라인으로 말하지만 모든 경우에 사실이 아닙니다.

선택할 수있는 사탕 믹스 백이 있으며 실제로 원하는 맛에 달려 있습니다.

1. DB는 쿼리를 캐시하고이 캐시가있는 위치, 메모리 또는 하드 드라이브를 구성 할 수 있습니다.
2. RAID 5는 항상 가장 빠른 것은 아니지만 RAID 0 (JBOD)은 스트라이프이며 빠릅니다. RAID 5도 스트라이프이기 때문에 아이디어는 거의 같습니다.
3. RAID 1은 속도를 향상시키지 않으며 단지 거울 일뿐입니다.
4. SQL 성능은 인덱싱을 기반으로하며 가장 먼저 확인해야합니다. 관계형 데이터베이스에서 매우 중요합니다.
5. 모든 색인을 생성하지 마십시오. 색인을 초과하면 색인 생성 속도가 느려질 수 있습니다.
6. 때때로 SQL 조인을 사용하면 데이터베이스 속도가 느려집니다. 프로그래밍을 사용하여 최소한의 인덱스 결과 집합을 반복하면 속도가 향상됩니다.
7. 당신이 돈을 지불하지 않으면 가상 서버는 속도에 악몽입니다.

현금을 인출하기 전에 지식 (무료)에 투자하십시오. 1. 데이터베이스의 구성을 배우고 현재 구성을보고 최적화하십시오. 2. 프로그래밍 및 sql 문, 관련 작업을 모방하는 간단한 스크립트를 사용한 단위 테스트를 살펴보십시오. 문제가 있다고 생각하지 않을 수도 있습니다. 간단한 스크립트가 SQL 조인을 사용하여 시간이 걸리면 분할하고 프로그래밍 된 루프로 동일한 작업을 수행합니다. 이것은 메모리가 도움이 될 수있었습니다. 3. 호스팅 계획과 서버를보십시오. Linux 콘솔에서 ps aux를 사용하여 메모리와 프로세서를 빨아들이는 것이 있는지 확인하십시오.

절대 하드 드라이브는 속도를 향상 시키지만 가상 서버 공간에서는 사용자에게 달려 있지 않습니다. 메모리를 기간별로 구성하지 않으면 메모리 속도가 향상되지 않습니다. 빠른 버스가있는 스트라이프 RAID (0,5), RPM 및 동기 읽기 / 쓰기가 도움이됩니다. l1, l2, l3 캐시가 좋은 코어 프로세서는 병목 현상을 처리하는 데 도움이됩니다. 제온 소리가 들리나요?

전반적으로 크기와 확장 성을 염두에 두어야합니다. 작은 스토리지 요구로 시작하는 것처럼 보이지만 데이터는 매우 빠르게 기하 급수적으로 증가합니다. DB는 가장 작은 크기로 분류 된 데이터 인 원자 데이터를 사용하는 것이 가장 좋습니다. 크기가 작기 때문에 데이터웨어 하우스 내에서 더 빠르게 이동합니다. 그런 다음 DB 구조도 고려해야합니다. 앞으로는 외부 DB에 연결할 수 있으므로 구조도 중요합니다. 이 시나리오에서는 데이터의 절반이 데이터 마트 외부에있는 경우 쿼리에 거의 차이가 없습니다. 데이터를 쿼리 할 때 요점은 저장된 데이터를 RAM에 보관하지 않는 것입니다. 오히려 쿼리는 데이터에 빠르게 액세스하고 데이터를 반환해야합니다.

• 데이터에 항상 RAID 5를 사용하는 것은 아닙니다. 이전에 백업에 대해 언급 한 것 외에 데이터 및 그 중요성에 따라 다릅니다. RAID 1을 사용할 수 있습니다.
• 속도를 향상 시키려면 쿼리 범위 내의 모든 서버를 업그레이드해야합니다. 많은 데이터가 통제 범위를 벗어나므로 데이터 마트 외부의 병목 현상이 발생합니다. (자신의 업그레이드를하는 경우)