Một nhập dữ liệu MySQL lớn trên SSD có thể làm hỏng nó không?

28

Tôi phải nhập khá nhiều dữ liệu (~ 100 triệu hàng, ~ 100 lần) vào cơ sở dữ liệu MySQL. Hiện tại, nó được lưu trữ trên ổ đĩa cứng của tôi và nút cổ chai trong quá trình nhập của tôi dường như là tốc độ ghi ổ đĩa cứng.

Tôi đã nghe nói rằng SSD không thích ghi liên tục lớn và nó có xu hướng làm hỏng chúng. Bạn nghĩ sao? Đây thực sự là một vấn đề trên SSD hiện đại?

— christophetd
nguồn

Miễn là bạn để lại (giả sử) 2-3 GB bên ngoài khu vực được phân vùng để cung cấp quá mức, tôi đoán bạn an toàn với nó. Tôi không thấy nhiều vấn đề với nó. Hầu hết các ổ SSD đã có một số phần của ổ đĩa mà hệ điều hành không thể truy cập được. Không gian đó được sử dụng để cân bằng hao mòn và để cung cấp quá mức, trong trường hợp ổ cứng quá đầy. Những GB thêm này sẽ cung cấp thêm chỗ cho SSD phân phối dữ liệu để tránh thiệt hại. Nếu bạn là người khó tính và muốn tiếp tục với điều này, bạn có thể tìm hiểu xem ssd của bạn có bao nhiêu chip nhớ và cung cấp 1GB cho chip. 10 chip là 10 GB không liên kết.

— Ismael Miguel

5

Đối với những gì nó có giá trị nhỏ, chúng tôi thường xuyên nhập dữ liệu xa, nhiều hơn nhiều so với điều này. Một trong những bảng của chúng tôi có nhiều dữ liệu hơn bạn đang nhập và chúng tôi có vài trăm bảng. Chúng tôi sử dụng SSD. Tôi hy vọng bạn sẽ ổn.

— ChrisInEd hôm

4

Ngày nay, SSD đủ thông minh để tự xử lý mức độ hao mòn ngay cả khi không có sự hỗ trợ của HĐH (mặc dù HĐH yêu cầu viết lại cùng một khối, nhưng bộ điều khiển của SSD ghi lại một khối khác nhau mỗi lần) vì vậy nó sẽ ổn.

7

Cá trích đỏ. Tỷ lệ thất bại của SSD không phải là điều đáng lo ngại - nó sẽ đủ dài để chúng vẫn tồn tại lâu hơn so với rỉ sét tương đương.

— Sobrique

2

Mọi người lo lắng quá nhiều về SSD của họ. Về cơ bản, bạn sẽ không bao giờ quản lý để "phá hủy" ổ SSD của mình một cách tình cờ và thậm chí việc thực hiện nó có chủ đích có thể cần hàng tuần hoặc hàng tháng để ghi liên tục. Ngay cả khi bạn "phá hủy" nó, nó vẫn sẽ cung cấp dữ liệu dưới dạng chỉ đọc. Đừng lo lắng và chỉ cần sử dụng nó. Bạn cũng có thể hỏi về cách đầu đọc / ghi của ổ cứng bị hao mòn do tăng tốc.

— mic_e

27

Nó thực sự không phải là một câu trả lời đơn giản cho điều này.

SSD không quan tâm đến việc ghi liên tục bao nhiêu lần bất kỳ khu vực cụ thể nào được ghi đè. Khi SSD lần đầu tiên xuất hiện, một cái gì đó như SQL là một từ tồi tệ vì hệ điều hành nói chung đối xử với ổ đĩa như một ổ cứng truyền thống và các lỗi rất thường xuyên.

Kể từ đó, các ổ đĩa đã trở nên lớn hơn, rẻ hơn, đáng tin cậy hơn, có nghĩa là để đọc / ghi nhiều hơn và các hệ điều hành đã trở nên thông minh hơn.

SSD trong SQL không chỉ phổ biến mà còn được khuyến khích. Hãy xem qua trang web chị em DBA .

Suy nghĩ của tôi là làm điều đó, giả sử máy chủ SQL được xây dựng đúng cách với các đĩa dự phòng. Nếu không, sau đó mong đợi một thất bại cuối cùng.

— Austin T Pháp
nguồn

5

"Nếu không, sau đó mong đợi một thất bại cuối cùng." Nếu máy chủ không sử dụng đĩa dự phòng, vẫn chắc chắn sẽ xảy ra lỗi tại một số điểm và lập kế hoạch cho nó. Chỉ là với sự dư thừa tại chỗ, một lỗi thiết bị lưu trữ có xác suất dẫn đến thời gian ngừng hoạt động của hệ thống thấp hơn nhiều.

— một CVn

@ MichaelKjorling có, chính xác. Trong tâm trí của tôi, "được xây dựng đúng cách" cũng giả định các bản sao lưu của cơ sở dữ liệu trong trường hợp thất bại ... Nhưng đôi khi ngay cả điều đó cũng không sao nếu không cần phải nói, cảm ơn.

— Austin T Pháp

19

Đọc là tốt, và SSD có thể có bit của họ đọc mà không có bất kỳ tác động bất lợi nào.

Viết là một vấn đề khác. Xóa một chút ảnh hưởng đến tính toàn vẹn của bit và sau rất nhiều lần ghi tuần tự, bit sẽ ngừng chấp nhận ghi hoàn toàn mới. Tuy nhiên nó vẫn có thể được đọc.

Hãy để tôi nói rằng giới hạn ghi trên ổ đĩa doanh nghiệp mới là rất lớn. Hãy dùng 845DC Pro mới của Samsung. Nó là tốt cho 10 ổ đĩa ghi mỗi ngày trong 5 năm về bảo hành. Tôi sẽ tưởng tượng nó sẽ làm gấp đôi số đó. Để đưa con số đó vào, con số 14.600 TB được viết trong 5 năm trên model 800 GB.
Hoặc 2920 TB mỗi năm,
Hoặc 8 TB mỗi ngày, trong năm năm .

Chỉ cho tôi một ổ cứng có bảo hành bao gồm nhiều sử dụng. Tôi thậm chí không chắc bạn có thể ghi 8 TB vào ổ cứng mỗi ngày: - (thông lượng trung bình 50 MB / giây * 60 (giây) * 60 (phút) * 24 (giờ) = 4.320.000 MB / ngày = 4.32 TB / ngày) Hóa ra bạn không thể (trên một ổ đĩa trung bình).

Miễn là bạn sử dụng một ổ đĩa như thế này, dựa trên V-NAND (hoặc SLC có độ bền tương đương), không phải là ổ đĩa dựa trên TLC hoặc flash MLC xấu, bạn sẽ ổn. Và dù sao, RAID 10 và các bản sao lưu là bạn của bạn vì một lý do. Và ít nhất nếu giới hạn ghi SSD trở thành vấn đề, bạn vẫn có thể đọc dữ liệu được lưu trữ trong các bit bị lỗi.

SSD cũng rẻ hơn để chạy, mát hơn, yên tĩnh hơn và các mô hình doanh nghiệp đặc biệt chống lại các vấn đề về điện. Không còn lo ngại về sự cố và tất nhiên, hiệu suất tăng rất lớn cho nhu cầu truy cập cơ sở dữ liệu của bạn.

— Ctrl-alt-dlt
nguồn

12

Tôi có thể hỏi tại sao downvote?

— Ctrl-alt-dlt

Bạn có thể hỏi, nhưng rõ ràng bạn sẽ không nhận được.

— Vụ kiện của Quỹ Monica

12

Ghi vào SSD không hẳn là xấu. Đó là cách viết và viết lại một khối duy nhất tệ. Có nghĩa là nếu bạn viết một tập tin hãy xóa nó sau đó viết lại hoặc thực hiện một số lượng nhỏ các thay đổi cho một tập tin nhiều lần. Điều này gây ra sự hao mòn trên ổ SSD. Cơ sở dữ liệu chắc chắn sẽ phù hợp với thể loại này.

Tuy nhiên, theo bài viết này , petabyte dữ liệu đã được ghi vào ổ SSD và vẫn có thể hoạt động. Điều này có lẽ là do những tiến bộ để mặc san lấp mặt bằng :

Mặc các nỗ lực cân bằng để khắc phục những hạn chế này bằng cách sắp xếp dữ liệu sao cho việc xóa và viết lại được phân phối đều trên phương tiện. Theo cách này, không có khối xóa đơn nào bị hỏng sớm do nồng độ cao của chu kỳ ghi.

Trong tình huống cụ thể của bạn, tôi sẽ có cơ sở dữ liệu nằm trên SSD để tăng tốc, nhưng được sao lưu hàng ngày. Bạn cũng có thể xem xét nhận hai ổ SSD trong một mảng RAID 1 . Khả năng hai ổ SSD bị lỗi cùng một lúc là thấp.

Lưu ý: mảng RAID KHÔNG phải là bản sao lưu !!!! Không có vấn đề nếu bạn sử dụng một mảng RAID hay không, có một bản sao lưu. Bất kể bạn có sử dụng SSD hay không, hãy có một bản sao lưu.

— James Mertz
nguồn

1

RAID1 sẽ làm rất ít cho loại thiệt hại mà bạn đang nói đến. Mức độ hao mòn có khả năng mang tính quyết định, điều đó có nghĩa là chúng sẽ mặc với tốc độ và cách chính xác như nhau, gây ra lỗi xảy ra gần như chính xác ở cùng một nơi.

— Aron

từ bài viết được liên kết: "các thiết bị điện tử trong SSD sẽ bị hỏng từ lâu trước khi NAND bị hao mòn" ... chờ đã, cái gì?

— Michael

4

Giả sử việc nhập của bạn không liên quan đến cập nhật và không xóa. Vì vậy, bạn đang làm tất cả các chèn. Điều này chỉ nên ghi dữ liệu mới vào nhật ký giao dịch.

Điều này có nghĩa là khi dữ liệu được thêm vào, nó luôn được ghi vào một khu vực mới. Có thể có một số bộ đệm / trao đổi được khuấy / viết thành nhiều lần, nhưng bỏ qua điều đó, tất cả các phần chèn đó về mặt lý thuyết sẽ dẫn đến không quá một lần viết cho mỗi khu vực . Tùy thuộc vào cách triển khai MySQL và loại chèn hàng loạt mà bạn đang thực hiện, bạn có thể tạo một tập hợp ghi thứ hai sau khi nhật ký giao dịch được tích hợp vào tệp dữ liệu chính (Tôi sẽ hiểu về các công cụ DB khác nhau và giả sử MySQL có phần giống nhau về cách ghi nhật ký giao dịch).

Vấn đề là, bạn không "khuấy động" SSD. Đó là, bạn không thực hiện nhiều sửa đổi / di chuyển / xóa / v.v. điều đó có khả năng viết lại trên cùng một lĩnh vực nhiều lần. Vì vậy, về cơ bản bạn sẽ chỉ tạo ra một số lượng ghi rất nhỏ cho mỗi lĩnh vực và đó là điều thực sự quan trọng.

Giả sử bạn không lấp đầy hoàn toàn SSD, cần có đủ không gian trống cho các điểm nóng đó (chẳng hạn như bộ đệm / trao đổi) đang bị đảo lộn để giảm thiểu hao mòn thông qua thuật toán cân bằng hao mòn.

(Các chỉ mục có thể là một vấn đề khác. Vì các chỉ mục được nhóm trong nhiều DB liên quan đến rất nhiều sửa đổi khi dữ liệu được chèn vào. Thông thường khi thực hiện các kết quả lớn trong môi trường kho dữ liệu, bạn tắt các chỉ mục trong quá trình nhập hàng loạt sau đó cập nhật chúng sau.)

— AaronLS
nguồn

3

Đây không phải là vấn đề.

Trước hết, SSD đã được cải thiện rất nhiều trong những năm qua. Việc cung cấp quá mức và hao mòn (và với một lượng nhỏ, lệnh TRIM, mặc dù không áp dụng trong trường hợp của bạn) đã khiến chúng khá phù hợp như các đĩa đa năng, đa năng. Tôi không sử dụng bất cứ thứ gì ngoại trừ SSD trên PC phát triển của mình (thường xuyên biên dịch rất nhiều) mà thậm chí không đến bất kỳ nơi nào gần số đếm chu kỳ xóa.

Hơn nữa, tuyên bố này:

SSD không thích ghi liên tục lớn và nó có xu hướng làm hỏng chúng

là hoàn toàn sai. Ngược lại là trường hợp, ghi nhỏ thường xuyên , nếu có bất cứ điều gì, có thể gây ra thiệt hại cho SSD.

Không giống như các đĩa cứng truyền thống, SSD (hay đúng hơn là đèn flash dựa trên NAND bên trong) được tổ chức vật lý trong các khối lớn chứa một số logic. Kích thước khối thông thường là 512kB trong khi các ngành (là đơn vị mà hệ thống tập tin sử dụng) theo truyền thống là 1kB (có thể có các giá trị khác nhau, hai thập kỷ trước 512B là phổ biến).
Ba điều có thể được thực hiện với khối 512kB. Nó có thể được đọc từ, một phần của nó hoặc tất cả có thể được lập trình (= viết thành) và toàn bộ nó có thể bị xóa. Xóa là vấn đề có vấn đề vì số lượng chu kỳ xóa bị hạn chế và bạn chỉ có thể xóa một khối hoàn chỉnh.

Do đó, ghi lớn rất thân thiện với SSD trong khi ghi nhỏ thì không.

Trong trường hợp ghi nhỏ, bộ điều khiển phải đọc một khối trong, sửa đổi bản sao, xóa một khối khác và lập trình nó. Nếu không có bộ nhớ đệm, trong trường hợp xấu nhất có thể, bạn sẽ cần xóa 512.000 khối để ghi 512 kilobyte. Trong trường hợp tốt nhất có thể (viết lớn, viết liên tục), bạn cần thực hiện chính xác 1 lần xóa.

Thực hiện nhập vào cơ sở dữ liệu MySQL khác với thực hiện nhiều truy vấn chèn riêng biệt. Công cụ có thể thu gọn rất nhiều ghi (cả dữ liệu và chỉ mục) với nhau và không cần đồng bộ giữa mỗi cặp chèn. Điều này tương đương với kiểu ghi thân thiện với SSD hơn nhiều.

— Damon
nguồn

2

Các ngành truyền thống là 1 KiB? Xin trích dẫn. Trên các ổ đĩa quay, hai kích thước cung là phổ biến: 512 byte (truyền thống, như trên ổ cứng 4 TB của tôi, trong các máy tính tương thích của IBM có từ khoảng năm 1981 trở đi) và 4096 byte ("Định dạng nâng cao"). Các đơn vị phân bổ cấp hệ thống tệp có thể khác nhau về kích thước, nhưng đó là một vấn đề hoàn toàn khác và hoàn toàn là một hệ thống tệp xây dựng để giữ phân bổ theo dõi cấu trúc dữ liệu ở kích thước hợp lý trong các hệ thống tệp không phát triển chúng một cách linh hoạt trên cơ sở cần thiết ; Ngoài ra, tôi nghi ngờ kích thước khối 1 KiB cố định là rất phổ biến trong thực tế.

— một CVn

@ MichaelKjorling: Cảm ơn bạn cho đầu vào rất có giá trị của bạn. Tất nhiên bạn đã đọc và hiểu câu trả lời, phải không? Một thực tế có liên quan là SSD có kích thước khối vật lý lớn hơn nhiều, bất kể kích thước khu vực logic (mà tôi đã thấy ở bất kỳ đâu từ 500 đến 4096 byte, thậm chí cả hai kích cỡ không có công suất). Không cần trích dẫn.

— Damon

1

SSD không thích nó. Nếu bạn giữ tốc độ ghi tối đa tăng lên trong 5-10 năm (24 giờ mỗi ngày, 7 ngày mỗi tuần) thì bạn có thể sẽ bị hỏng ổ SSD.

Tất nhiên Sau 5 năm, hầu hết các máy chủ đã đạt đến kết thúc kinh tế.

Tuyên bố miễn trừ trách nhiệm:
Đừng thử điều này với thế hệ SSD đầu tiên. Những nơi kém mạnh mẽ.

— Hennes
nguồn

Tôi nhận thức rõ rằng việc sử dụng bất kỳ ổ đĩa nào với dung lượng tối đa 7/24 sẽ làm hỏng nó ... Câu hỏi của tôi là liệu nó có an toàn trong một khoảng thời gian giới hạn không (giả sử vài lần 2-3 giờ)

— christophetd

@christophetd - Nó phụ thuộc. Cập nhật câu hỏi của bạn để ước tính lượng dữ liệu. Nó nhiều hơn về tỷ lệ phần trăm của ổ đĩa. Viết 20 GB một giờ trên SSD 80 GB là tồi tệ nhất sau đó làm 20 GB một giờ trên SSD 1TB.

— Ramhound

Cùng một lưu ý: Có một ổ đĩa trống hầu hết có nghĩa là nhiều ô flash 'trống' được sử dụng trong việc cân bằng hao mòn. (và một ổ đĩa lớn hơn với cùng một lượng dữ liệu là% emtier).

— Hennes

1

Nếu bạn thực sự quan tâm đến việc tìm ra các chi tiết thì bạn sẽ cần câu hỏi sau đây được trả lời:

Trung bình có bao nhiêu byte trong mỗi hàng?

Nếu bạn có thể nói với tôi rằng có 10 cột, mỗi cột là varchar (100) và mã hóa là UTF-8 thì tôi có thể đoán trong trường hợp xấu nhất là bạn có dữ liệu trị giá 4.000 byte mỗi hàng và thêm một số byte cho siêu dữ liệu cho phép nói 4.200 byte?

SQL tra tấn của bạn tính toán 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesdữ liệu ghi vào đĩa

42.000.000.000.000 / 1000 = 42.000.000.000 KB

42.000.000.000 / 1000 = 42.000.000 MB

42.000.000 / 1000 = 42.000 GB

42.000 / 1000 = 42 TB

Ở trường hợp xấu nhất về mặt lý thuyết này, bạn sẽ ghi 42 TB vào đĩa

Theo bài viết này , được cung cấp bởi @KronoS, bạn sẽ tốt hơn cho khoảng 25 vòng SQL tra tấn của mình.

— Khỉ
nguồn

-2

Như poster của bài viết này trên SSD đã nói, những gì thực sự có hại là hết lần này đến lần khác viết những khối dữ liệu nhỏ.

bit được lưu trữ vào các ô {1,2,3}. Những có tuổi thọ hạn chế.
các ô được nhóm thành [2-16] trang KB (đơn vị ghi nhỏ nhất)
các trang được nhóm thành các khối (128-256 trang-) (đơn vị xóa nhỏ nhất)
để một trang được viết lại, nó --- và toàn bộ khối của nó --- cần phải được xóa trước

Đó là lý do tại sao nên

không bao giờ viết ít hơn một trang cùng một lúc
đệm nhỏ ghi, và
yêu cầu đọc và viết riêng biệt
"Một văn bản đơn luồng lớn tốt hơn nhiều ghi đồng thời nhỏ"

Vì vậy, một số tiền thực sự lớn cùng một lúc có vẻ tốt hơn.

— người phục vụ
nguồn

2

Câu trả lời này không thực sự cung cấp bất kỳ thông tin liên quan nào chưa được nói, bên cạnh đó, về cơ bản nó là một bình luận với một liên kết có trong đó.

— Ramhound

@Ramhound: bạn có đồng ý với nhận xét của bạn không (cảm ơn bạn, btw), và điều này cũng vậy, để được gắn thẻ lỗi thời? Hay bạn vẫn xem xét thông tin đã nói / không liên quan?

— phục vụ

Mặc dù nó không còn là một liên kết, nhưng thật ra, thông tin kỹ thuật, không thực sự áp dụng cho câu hỏi của người dùng liên quan đến việc chạy cơ sở dữ liệu trên SSD I

— Ramhound

@Ramhound: với tôi dường như là về việc nhập khẩu chứ không phải chạy. Đánh giá từ các downvote, có vẻ như bạn đúng

— phục vụ