SSD에서 대량의 MySQL 데이터를 가져올 경우 손상 될 수 있습니까?

MySQL 데이터베이스에 많은 양의 데이터 (~ 1 억 행, ~ 100 배)를 가져와야합니다. 현재 내 하드 디스크 드라이브에 저장되어 있으며 가져 오기의 병목 현상이 하드 디스크 드라이브 쓰기 속도 인 것 같습니다.

SSD는 대량의 연속 쓰기를 좋아하지 않으며 SSD가 손상되는 경향이 있다고 들었습니다. 어떻게 생각해? 이것이 현대 SSD에서 실제로 문제입니까?

실제로 이것에 대한 직접적인 대답은 아닙니다.

SSD는 특정 섹터를 여러 번 덮어 쓰는 것만 큼 연속 쓰기에 신경 쓰지 않습니다. SSD가 처음 나왔을 때 일반적으로 운영 체제가 드라이브를 기존 HDD처럼 취급하고 오류가 매우 빈번하게 발생했기 때문에 SQL과 같은 것은 나쁜 단어였습니다.

그 이후로, 드라이브는 더 크고 저렴하며 신뢰성이 높아졌으며 더 많은 읽기 / 쓰기를 의미하며 운영 체제는 더 똑똑해졌습니다.

SQL의 SSD는 일반적 일뿐만 아니라 권장되는 경우가 많습니다. DBA 자매 사이트를 자유롭게 사용 하십시오 .

SQL 서버가 중복 디스크로 올바르게 구축되었다고 가정하면 그렇게 생각합니다. 그렇지 않다면 어쨌든 실패를 예상하십시오.

읽기는 괜찮으며 SSD는 아무런 영향을 미치지 않고 비트를 읽을 수 있습니다.

글은 또 다른 문제입니다. 비트를 지우면 비트의 무결성에 영향을 미치고 많은 순차적 쓰기 후에 비트는 새로운 쓰기를 완전히받지 않습니다. 그러나 여전히 읽을 수 있습니다.

새 엔터프라이즈 드라이브에 대한 쓰기 제한이 크다고 말하겠습니다. 삼성의 새로운 845DC Pro를 사용하십시오. 5 년 동안 하루에 10 번의 드라이브 쓰기를 보증합니다. 나는 그 숫자의 두 배를 할 것이라고 상상할 것입니다. 이를 수치로 표현하면 800GB 모델에 5 년 동안 14,600TB가 기록됩니다.
또는 5 년 동안 1 년에 2920TB,
또는 하루에 8TB .

많은 사용을 보증하는 보증서가있는 하드 드라이브를 보여주십시오. 하루에 8TB를 HDD에 쓸 수 있는지 확실하지 않습니다 .- (50MB / s 평균 처리량 * 60 (초) * 60 (분) * 24 (시간) = 4,320,000MB / 일 = 4.32TB / 하루) 당신이 할 수없는 것으로 밝혀졌습니다 (일반 드라이브).

TLC 또는 불량 MLC 플래시를 기반으로 한 것이 아니라 V-NAND (또는 동일한 내구성의 SLC)를 기반으로하는 이와 같은 드라이브를 사용하는 한 괜찮습니다. 어쨌든, RAID 10 과 백업은 당신의 친구입니다. 그리고 적어도 SSD 쓰기 제한이 문제가된다면 여전히 결함이있는 비트에 저장된 데이터를 읽을 수 있습니다.

SSD는 또한 운영 비용이 저렴하고, 차갑고, 조용하며, 엔터프라이즈 모델은 특히 전력 문제에 강합니다. 더 이상 머리 충돌의 두려움없고, 물론, 거대한 데이터베이스 액세스 요구에 대한 성능 향상.

SSD에 쓰는 것이 반드시 나쁘지는 않습니다. 나쁜 하나의 블록을 쓰고 다시 쓰는 것입니다. 파일을 쓰는 경우 파일을 삭제 한 다음 다시 쓰거나 파일을 반복해서 약간 변경합니다. 이로 인해 SSD가 마모됩니다. 데이터베이스는 확실히이 범주에 적합합니다.

그러나이 기사 에 따르면 페타 바이트 규모의 데이터가 SSD에 기록되었으며 여전히 작동 가능합니다. 이것은 아마도 마모 레벨링의 발전 때문일 것입니다 .

웨어 레벨링은 삭제 및 재기록이 매체에 고르게 분산되도록 데이터를 배열하여 이러한 제한을 해결하려고합니다. 이러한 방식으로, 높은 쓰기 주기로 인해 단일 소거 블록이 조기에 실패하지 않습니다.

귀하의 특정 상황에서 나는 데이터베이스가 속도를 위해 SSD에 상주하지만 매일 백업됩니다. RAID 1 어레이 에 2 개의 SSD를 설치하는 것도 고려할 수 있습니다 . 두 개의 SSD가 동시에 고장날 가능성은 낮습니다.

참고 : RAID 어레이는 백업이 아닙니다 !!!! RAID 어레이 사용 여부에 관계없이 백업하십시오. SSD 사용 여부에 관계없이 백업하십시오.

가져 오기에 업데이트 및 삭제가 필요하지 않다고 가정 해 봅시다. 그래서 당신은 모든 삽입을하고 있습니다. 트랜잭션 로그에만 새 데이터를 작성해야합니다.

이는 데이터가 추가됨에 따라 항상 새로운 섹터에 기록됨을 의미합니다. 여러 번 버퍼링 / 스왑되는 버퍼 / 스왑이있을 수 있지만 이러한 인서트를 모두 무시할 경우 이론적으로 섹터 당 하나 이상의 쓰기가 발생 합니다. MySQL이 구현되는 방법과 수행하는 대량 삽입 유형에 따라 나중에 트랜잭션 로그가 기본 데이터 파일에 통합 될 때 두 번째 쓰기 세트를 생성 할 수 있습니다 (다른 DB 엔진에 대한 이해를 중단합니다) MySQL이 트랜잭션 로그를 플러시하는 방법이 다소 비슷하다고 가정합니다).

요컨대, 당신은 SSD를 "이탈"하지 않습니다. 즉, 많은 수정 / 이동 / 삭제 등을 수행하지 않습니다. 잠재적으로 동일한 섹터를 여러 번 다시 작성할 수 있습니다. 따라서 본질적으로 섹터 당 매우 적은 수의 쓰기 만 생성 할 것이므로 이것이 실제로 중요한 것입니다.

SSD를 완전히 채우지 않는다고 가정하면웨어 레벨링 알고리즘을 통해 마모를 최소화 할 수있는 핫스팟 (예 : 버퍼 / 스왑)을위한 충분한 여유 공간이 있어야합니다.

(인덱스가 또 다른 문제 일 수 있습니다. 많은 DB의 클러스터형 인덱스에는 데이터가 삽입 될 때 많은 수정이 필요합니다. 일반적으로 데이터웨어 하우스 환경에서 큰 문제를 수행하는 경우 대량 가져 오기 중에 인덱스를 끈 다음 업데이트합니다.)

이것은 문제가되지 않습니다.

우선, SSD는 지난 몇 년 동안 크게 향상되었습니다. 오버 프로비저닝 및웨어 레벨링 (및 소량의 경우 TRIM 명령은 귀하의 경우에는 적용되지 않음)으로 인해 범용 범용 디스크로 매우 적합합니다. 소거주기 수 근처에 오지 않고도 개발 PC에서 정기적으로 많은 컴파일을 수행하는 SSD 이외의 다른 것을 사용하지 않습니다.

또한이 진술 :

SSD는 대량의 연속 쓰기를 좋아하지 않으며 손상되는 경향이 있습니다.

완전히 잘못되었습니다. 반대로 작은 쓰기 작업이 자주 발생하면 SSD가 손상 될 수 있습니다.

기존의 하드 디스크와 달리 SSD (또는 내부의 NAND 기반 플래시)는 논리적으로 여러 섹터를 포함하는 큰 블록으로 물리적으로 구성됩니다. 일반적인 블록 크기는 512kB 인 반면 섹터 (파일 시스템이 사용하는 단위)는 전통적으로 1kB입니다 (20 년 전 512B가 일반적이었던 다른 값이 가능합니다).
512kB 블록으로 세 가지 작업을 수행 할 수 있습니다. 읽을 수 있으며, 일부 또는 전체를 프로그래밍 (= 쓰기) 할 수 있으며 전체를 지울 수 있습니다. 소거주기의 수가 제한되어 있기 때문에 소거가 문제가되고 완전한 블록 만 소거 할 수 있습니다.

따라서 큰 쓰기는 SSD에 매우 친숙하지만 작은 쓰기는 그렇지 않습니다.

작은 쓰기의 경우 컨트롤러는 블록을 읽고 사본을 수정하고 다른 블록을 지우고 프로그래밍해야합니다. 캐싱이 없으면 최악의 경우 512.000 블록을 삭제하여 512 킬로바이트를 작성해야합니다. 가장 좋은 경우 (대규모 연속 쓰기)에는 정확히 1 개의 지우기를 수행해야합니다.

MySQL 데이터베이스로 가져 오기를 수행하는 것은 많은 별도의 삽입 쿼리를 수행하는 것과 크게 다릅니다. 엔진은 많은 쓰기 (데이터 및 인덱스 모두)를 함께 축소 할 수 있으며 각 삽입 쌍간에 동기화 할 필요가 없습니다. 이는 훨씬 더 SSD 친화적 인 쓰기 패턴에 해당합니다.

SSD는 그것을 좋아하지 않습니다. 5-10 년 (1 일 24 시간, 주 7 일) 동안 최대 쓰기 속도를 유지하면 SSD가 손상 될 수 있습니다.

Ofc. 5 년 후 대부분의 서버는 경제적으로 수명이 다했습니다.

면책 조항 :
최초의 SSD로 이것을 시도하지 마십시오. 덜 견고한 곳.

세부 사항을 알아내는 데 정말로 관심이 있다면 다음 질문에 대한 답변이 필요합니다.

각 행에 평균 몇 바이트가 있습니까?

열이 10 개 있고 각 열이 varchar (100)이고 인코딩이 UTF-8이라고 말할 수 있다면 최악의 시나리오에서 행 당 4,000 바이트의 데이터가 있고 더 많은 바이트를 추가한다고 추측 할 수 있습니다 메타 데이터는 4,200 바이트라고 말할까요?

고문 SQL 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytes은 디스크에 기록 된 데이터를 계산합니다

42,000,000,000,000 / 1000 = 42,000,000,000KB

42,000,000,000 / 1000 = 42,000,000MB

42,000,000 / 1000 = 42,000GB

42,000 / 1000 = 42TB

이 이론상 최악의 시나리오에서는 42TB를 디스크에 기록합니다.

@KronoS에서 제공하는 이 기사 에 따르면 25 회 정도 더 고문 SQL을 진행해야합니다.

SSD에 대한이 글 의 포스터가 말했듯이, 실제로 유해한 것은 몇 번이고 작은 데이터 덩어리를 쓰는 것입니다.

• 비트는 {1,2,3} 비트 셀에 저장된다. 이들은 수명이 제한되어 있습니다.
• 셀은 [2-16] KB 페이지 (작은 쓰기 가능 단위)로 그룹화됩니다.
• 페이지는 (128-256 page-) 블록 (가장 작은 삭제 가능한 단위)으로 그룹화됩니다.
• 페이지를 다시 작성하려면 페이지 전체와 블록 전체를 먼저 지워야합니다.

그것이 추천하는 이유입니다

• 한 번에 한 페이지 미만을 쓰지 마십시오.
• 작은 쓰기 버퍼링
• 별도의 읽기 및 쓰기 요청
• "대규모 단일 스레드 쓰기는 다수의 소규모 동시 쓰기보다 낫습니다."

따라서 한 번에 실제로 많은 양이 더 좋아 보입니다.