트랜잭션 볼륨을 별도의 볼륨에 배치 [고체 상태]?


12

트랜잭션 로그는 종종 별도의 볼륨에 격리됩니다. 내가 이해하는 것처럼,이 관행의 근거는 트랜잭션 로그의 데이터가 순차적으로 기록되며 하드 드라이브는 랜덤이 아닌 훨씬 빠른 속도로 순차적으로 쓰기 작업을 수행 할 수 있다는 것입니다. 이는 무작위 쓰기와는 달리 순차적 데이터 블록을 쓸 때 드라이브 내부의 바늘이 적기 때문에 훨씬 더 짧은 거리를 이동해야하기 때문입니다.

(순진한 해석에 대해 죄송합니다. 내가 읽은 것을 이해하려고 노력하십시오.)

이것을 염두에두고… 솔리드 스테이트 드라이브에는 바늘과 플래터가 거의 없으며 내부에서 움직이는 물건이 없습니다. 내 데이터베이스와 트랜잭션 로그가 모두 8 개의 솔리드 스테이트 드라이브 중 하나의 RAID 5에있는 경우 트랜잭션 로그를 별도의 볼륨으로 옮기는 데 어떤 장점이 있습니까? 가정 된 효율 향상이 순차적 쓰기의 전제를 기반으로 바늘이 이동하고 플래터가 회전하는 거리를 줄이고 솔리드 스테이트 드라이브에 이러한 움직이는 부품이없는 경우 로그를 분리하여 얻을 수있는 것은 무엇입니까?


여전히 고려해야 할 버스와 버퍼가 있습니다. I / O 패턴 차이로 인해 개별적으로 유지합니다. 앱이 트랜잭션이 많지 않은 경우 비용이 문제인 경우 차이를 알지 못할 것입니다.
에릭 히긴스

"버스"라는 용어를 사용할 때 ... 마더 보드에서 RAID 카드로 데이터가 이동하는 경로를 가리 킵니까?
채드 데커

2
"트랜잭션 로그를 별도의 볼륨으로 옮기는 것의 장점이 있습니까?" 거의 확실하지,하지만 속도가 오버 프로비저닝 (즉, 아래 파티셔닝) SSD 제품에 거꾸로 RAID10 및 신뢰성에 전체 배열을 이동하는 거꾸로 정말이
잭 topanswers.xyz 시도라고

답변:


10

짧은 대답, 단일 어레이를 사용하면 8 개의 SSD 드라이브에서 데이터와 로그를 분리 할 때 성능이 향상되지 않을 수 있습니다. SSD 에 대한 자세한 설명 은 SSD의 SQL : Hot and Crazy Love 를 참조하십시오 . SSD의 관련 오류에 대한 참고 사항에 특히주의하십시오.

SSD의 데이터에서 로그를 분리하는 것이 성능 문제보다 RPO (복구 지점 목표)보다 높습니다. 데이터 배열이 실패 할 경우 로그 배열에 액세스 할 수 있도록 로그를 데이터에서 분리하여 RPO를 줄일 수 있다는 개념입니다. 주의해서 RPO가 중요한 경우 상관 된 장애 문제를 완화하기 위해 두 어레이 각각에서 서로 다른 드라이브 제조업체 / 모델을 고려할 것입니다.

버스 대역폭에 대한 의견은 관련이 없습니다. 많은 양의 IO를 전환해야하는 경우 더 큰 문제가 있습니다.


-4

HDD에서 분리하는 것이 유리할 것이라는 데 동의하는 그룹이 있으며, SSD 드라이브의 경우 더 이상 필요하지 않다고 주장합니다.

그래서 나는 그들에게 "경쟁의 문제가 없다면 왜 RAID 10? 크기가 충분해야합니다! "

그러나 실제로 RAID 10이 필요한 경우 로그 파일입니다!

이는 순차 vs 임의 (아래 리소스 참조) 문제 때문이 아니라 SSD 드라이브의 작동 방식을 이해하면 실제로 매우 중요합니다.

긴 이야기를 짧게 만들려면 (더 자세한 설명은 http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ 참조 ) SSD 드라이브는 읽기에서 매우 효율적이며, 0을 쓰면서도 쓸 수 있지만, 1을 쓰려면 전체 섹션을 지워 단일 드라이브를 작성하는 것만 큼 효율적이지 않습니다!

메모리에 버퍼링되고 페이지 경계에 기록되므로 일반적인 쓰기에는 문제가되지 않지만 로그 파일은 캐시를 우회하고 대신 SQL Server는 로그는 디스크에 기록됩니다. 즉, 각 쓰기마다 전체 섹션이 지워질 수 있습니다.

따라서이를 최적화하기 위해 로그 파일에 대해 모든 추가 디스크 (데이터베이스 크기의 2 배, 스트리핑 필요 없음)를 전용으로 지정하는 것이 좋습니다. 이렇게하면 더 짧은 시간 내에 최대한 많은 수를 처리 할 수 ​​있습니다.

주문 답변

세 가지 이유로 대답이 그렇습니다. 1) Random vs Sequential-SSD가 랜덤 쓰기의 성능을 크게 향상 시켰음이 분명하지만, 다음 백서 및 링크에서 볼 수 있듯이 여전히 랜덤 vs 순차적 문제가 남아 있습니다.

2) 안정성-모든 SSD 드라이브가 동시에 실패 할 가능성이 높습니다.이 경우 RAID는 보호되지 않습니다. 그러나 순차 전용으로 사용 된 SSD 드라이브의 수명이 다르므로 수명이 단축 될 수 있습니다.

3) 쓰기 경합-로그를 자체 스핀들에 배치하는 이유는 임의 vs 순차적이기 때문이 아니라 쓰기 경합 때문입니다. 따라서 tempdb를 별도의 볼륨에 표시하는 것이 좋습니다. 여기서 문제는 쓰기 경합에 관한 것입니다.

그리고 로그에 쓰면 트랜잭션이 디스크 표면에 쓰여질 때까지 커밋 된 것으로 간주되지 않으므로 로그 파일에 더 많이 적용됩니다.

실제로 로그의 경우 http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf 에서 일반 HDD 드라이브를 Dell의 백서로 사용할 수 있습니다 .

편집하다

Microsoft는 디스크 회전을 위해 tempdb를 자체 어레이에 배치하는 것이 좋습니다.

그리고 다른 많은 것들과 그것은 Sql Server에서 일반적으로 받아 들여지는 개념이지만, 아무도 배열을 나누는 데 문제가 없었습니다.

또한 SQL Server 팀은 파일 그룹 및 파티셔닝 파티셔닝 개념을 별도의 배열로 이동할 수 있도록하기 위해 단독으로 개발했습니다.

그리고 실제로 http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) 의 MSDN 에서는 클러스터되지 않은 인덱스를 자체 배열에서 분리하면 성능상의 이점이있을 수 있다고 권장합니다. 이것은 모든 상황에 대한 일반적인 조언으로 간주되어서는 안되며 특정 워크로드에만 해당됩니다. http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA 에서 자세한 정보를 참조하십시오 -Monkey.aspx ).

따라서 회전하는 디스크의 분리 이유가 순차 vs 임의 읽기 문제와 관련이있는 것이 아니라 SSD에도 적용되는 일반적인 쓰기 경합과 관련이 있다는 것은 논리적 확장입니다.

일부 사람들은 그 조언에 동의하지 않고 tempdb와 자체 볼륨 (Jack Douglas와 같은)을 넣을 때 이점이 없다고 생각할 수도 있지만 로그 파일을 분리해도 이점이 없다고 주장 할 수도 있습니다 (Mark Storey). -Smith) 대신 배열을 나누는 것이 훨씬 더 나쁘다고 주장하지만, 이것이 Microsoft와 커뮤니티에서 제안한 일반적인 승인 된 접근 방식에 반대하는 새로운 접근 방식이라는 것을 잊지 마십시오. 이를 지원하기위한 벤치 마크 테스트.

따라서 모든 downvoters에 대한 나의 말은, 나는 당신의 의견이 당신과 다른 의견을 가지고 있기 때문에, 특히 1) 당신의 의견이 일반적으로 받아 들여지는 이론에 반하고 2) 그리고 벤더 (Microsoft ) 자신의 문서 3) 당신은 단지 의견에 대한 증거를 제공하지 않았습니다.

그러나이 경우 내 게시물 이이 이론의 논리적 확장에 지나지 않기 때문에이 말은 더 어리 석습니다. 따라서이 게시물을 침대 조언으로 간주하는 사람은 물론이 이론을 조언하는 모든 게시물로 돌아가서 공감해야합니다. .

누군가 RAID가 구식 이론이라고 결정하고 그것을 추천하는 모든 게시물을 공표한다고 말하면 어떻게됩니까?


의견은 긴 토론을위한 것이 아닙니다. 이 대화는 채팅 으로 이동 되었습니다 .
Paul White 9
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.