SSD를 사용할 때 DB 디자인의 클러스터형 인덱스 개념이 의미가 있습니까?

SQL Server 데이터 스키마 및 후속 쿼리, sprocs, 뷰 등을 디자인 할 때 클러스터형 인덱스 및 디스크의 데이터 순서 개념은 SSD 플랫폼에 명시 적 으로 배포되도록 만들어진 DB 디자인에 대해 고려하는 것이 합리적 입니까?

http://msdn.microsoft.com/en-us/library/aa933131(v=sql.80).aspx
"클러스터형 인덱스는 테이블에서 데이터의 물리적 순서를 결정합니다."

실제 디스크 플랫폼에서 "순차적"행을 검색하기위한 데이터의 실제 스캔이 테이블을 통한 탐색보다 성능이 우수하므로이를 고려하여 설계하는 것이 좋습니다.
SSD 플랫폼에서 모든 데이터 읽기 액세스는 동일한 탐색을 사용합니다. "물리적 순서"라는 개념은 없으며 비트가 동일한 실리콘 조각에 저장된다는 점에서 데이터 읽기는 "순차적"이 아닙니다.

따라서 응용 프로그램 데이터베이스 를 설계하는 과정 에서 클러스터 된 인덱스 고려 사항이이 플랫폼과 관련이 있습니까?

저의 초기 생각은 "순서화 된 데이터"라는 아이디어가 SSD 스토리지 및 탐색 / 복구 최적화에 적용 되지 않기 때문 이 아니라는 것입니다.

편집 : SQL Server 가 하나 를 만들 것이라는 것을 알고 있습니다. 디자인 / 최적화 중에 SQL Server 를 생각하는 것이 합리적인지에 대해 철학적입니다.

다른 질문 : 전체 데이터베이스가 메모리에 있고 디스크를 건드릴 필요가없는 경우 데이터를 정렬 된 B- 트리에 저장하거나 데이터를 정렬되지 않은 힙에 저장하려고합니까?

이 질문에 대한 답변은 액세스 패턴에 따라 다릅니다. 대부분의 경우 액세스에는 단일 행 조회 (예 : 탐색) 및 범위 스캔이 필요합니다. 이러한 액세스 패턴에는 B- 트리가 필요합니다. 그렇지 않으면 비효율적입니다. DW 및 OLAP에서 일반적으로 사용되는 일부 다른 액세스 패턴은 항상 전체 테이블에 대해 항상 집계를 수행하며 범위 스캔의 이점이 없습니다. 추가로 드릴 할 때 힙에 대한 삽입 및 할당 속도와 같은 다른 요구 사항이 밝혀지면 B-Tree는 거대한 ETL 전송 작업에 중요한 역할을 할 수 있습니다. 그러나 대부분의 경우 답변은 실제로 하나의 질문으로 귀결됩니다. 압도적 인 대답은 YES입니다. 따라서 설계에 클러스터 된 인덱스가 필요한 횟수가 압도적입니다.

즉, 무작위 순서로 디스크에서 읽는 것이 저렴하기 때문에 64GB RAM 스캔 보난자에서 TLB 및 L2 라인을 휴지통에 버릴 수 있음을 의미하지는 않습니다.

잘 선택된 클러스터형 인덱스를 사용하면 더 적은 수의 데이터 페이지에서 필요한 모든 관련 데이터를 얻을 수 있습니다. 즉, 필요한 데이터를 적은 메모리에 보관할 수 있습니다. 회전 디스크를 사용하든 SSD를 사용하든 관계없이 이점이 있습니다.

그러나 많은 디스크 검색 대신 관련 데이터를 순차적으로 읽고 쓰는 클러스터 된 인덱스의 다른 이점이 SSD에 큰 이점이 아니라는 점에서 그렇습니다. 검색은 그렇게 큰 성능 오버 헤드가 아닙니다. 회전하는 디스크가 있습니다.

@Matthew PK의 코멘트를 다시.

물론 RAM의 위치 A는 RAM의 위치 B만큼 빠릅니다. 요점은 그것이 아니다. 데이터가 여러 페이지에 흩어져있는 경우 필요한 모든 데이터가 RAM에 맞지 않는 경우에 대해 이야기하고 있습니다. 특정 페이지에는 관심있는 데이터가 소량 만 포함될 수 있습니다. 따라서 RDBMS는 A, B 및 기타 행에 액세스 할 때 페이지를 계속로드하고 제거해야합니다. 그곳에서 성능 저하가 발생합니다.

모든 후속 행 요청이 RAM의 페이지에서 제공 되기를 바랍니다 . 클러스터 된 인덱스를 사용하면 데이터를 더 적은 페이지로 그룹화 할 수 있습니다.

예, 그것은 여전히 ​​타당합니다. 접근 방식이 너무 낮습니다. (A의 SQL 서버 매우 매우 간단하게 설명) 저장은 B 트리 구조의 데이터를 클러스터. 이를 통해 클러스터 된 인덱스 키 값을 기반으로 빠른 데이터 검색이 가능합니다.

힙 (클러스터형 인덱스 없음)에는 순차적 데이터 순서가 없습니다. 여기에서 고려해야 할 가장 중요한 것은 데이터 페이지가 링크 된 목록에 링크되어 있지 않은 것 입니다.

따라서 대답은 그렇습니다. SSD에서도 테이블에 클러스터형 인덱스를 만드는 것이 좋습니다. 결과 데이터를 얻기 위해 SQL Server가 선별해야하는 데이터 양을 기반으로합니다. 클러스터형 인덱스 검색을 사용하면 최소화됩니다.

참조 : http://msdn.microsoft.com/en-us/library/ms189051.aspx