Может ли массивный импорт данных MySQL на SSD повредить его?

Мне нужно импортировать довольно много данных (~ 100 миллионов строк, ~ 100 раз) в базу данных MySQL. В настоящее время он хранится на моем жестком диске, и узким местом моего импорта является скорость записи на жесткий диск.

Я слышал, что твердотельные накопители не любят массовых непрерывных операций записи, и это может привести к их повреждению. Что вы думаете? Это действительно проблема современных SSD?

Это действительно не простой ответ на это.

SSD не заботятся о непрерывной записи столько, сколько сколько-нибудь конкретный сектор перезаписывается. Когда впервые появились SSD, что-то вроде SQL было плохим словом, поскольку операционная система в целом относилась к диску как к традиционному жесткому диску, и сбои были очень частыми.

С тех пор диски стали больше, дешевле, надежнее, предназначены для большего числа операций чтения / записи, а операционные системы стали более интеллектуальными.

SSD в SQL не только распространены, но и часто поощряются. Не стесняйтесь просматривать дочерний сайт DBA .

Я думаю сделать это, предполагая, что сервер SQL построен правильно с избыточными дисками. Если нет, то в любом случае ожидайте сбой.

Считывания в порядке, и биты SSD могут считываться без какого-либо вредного воздействия.

Пишет другое дело. Очистка бита влияет на целостность бита, и после большого количества последовательных записей бит прекратит принимать новые записи вообще. Однако это все еще можно прочитать.

Позвольте мне просто сказать, что ограничения на запись для новых корпоративных дисков огромны. Возьмите новый Samsung 845DC Pro. Это хорошо для 10 приводов в день в течение 5 лет по гарантии. Я предполагаю, что это сделает вдвое больше. Чтобы выразить это в цифрах, это 14 600 ТБ, написанных за 5 лет на модели 800 ГБ.
Или 2920 ТБ в год,
или 8 ТБ в день, на пять лет .

Покажите мне жесткий диск с гарантией, которая распространяется на такое большое использование. Я даже не уверен, что вы могли бы записать 8 ТБ на жесткий диск в день: - (средняя пропускная способность 50 МБ / с * 60 (секунд) * 60 (минут) * 24 (часов) = 4 320 000 МБ / день = 4,32 ТБ / день) Оказывается, вы не можете (на среднем диске).

Пока вы используете такой диск, основанный на V-NAND (или одинаково надежный SLC), а не тот, который основан на TLC или плохой флэш-памяти MLC, у вас все будет в порядке. И в любом случае, RAID 10 и резервные копии - ваш друг по определенной причине. И, по крайней мере, если ограничение записи SSD действительно становится проблемой, вы все равно можете прочитать данные, хранящиеся в неисправных битах.

SSD также дешевле в эксплуатации, кулер, тише и корпоративные модели особенно устойчивы к проблемам с питанием. Больше нет опасений, связанных с падением головы, и, конечно, огромным увеличением производительности для ваших потребностей в доступе к базе данных.

Запись на SSD не обязательно плохая. Это написание и перезапись одного блока, это плохо. Это означает, что если вы пишете файл, удалите его, а затем запишите его снова или внесите небольшие изменения в файл снова и снова. Это вызывает износ SSD. Базы данных определенно вписываются в эту категорию.

Однако, согласно этой статье , петабайты данных были записаны на SSD и все еще работоспособны. Вероятно, это связано с достижениями выравнивания износа :

Выравнивание износа пытается обойти эти ограничения путем упорядочения данных таким образом, чтобы стирания и перезаписи распределялись равномерно по всему носителю. Таким образом, ни один блок стирания не выходит из строя преждевременно из-за высокой концентрации циклов записи.

В вашей конкретной ситуации я хотел бы, чтобы базы данных постоянно находились на SSD, но ежедневно создавали резервные копии. Вы также можете рассмотреть возможность получения двух SSD в массив RAID 1 . Вероятность выхода из строя двух SSD одновременно низкая.

Примечание: RAID-массивы НЕ являются резервными копиями !!!! Независимо от того, используете ли вы RAID-массив или нет, создайте резервную копию. Независимо от того, используете вы SSD или нет, создайте резервную копию.

Давайте предположим, что ваш импорт не содержит обновлений и удалений. Итак, вы делаете все вставки. Это должно только записывать новые данные в журнал транзакций.

Это означает, что при добавлении данных они всегда записываются в новый сектор. Могут быть некоторые буферы / свопы, которые многократно перезаписываются / записываются, но игнорируя это, все эти вставки теоретически приводят к не более чем одной записи на сектор . В зависимости от того, как реализован MySQL, и какой тип массовой вставки вы выполняете, вы можете создать второй набор записей позже, когда журнал транзакций интегрирован в основной файл данных (я ухожу от понимания различных механизмов БД и предполагая, что MySQL несколько похож в том, как очищаются журналы транзакций).

Суть в том, что вы не «сбиваете» SSD. То есть вы не делаете много изменений / перемещений / удалений / и т.д. это потенциально может переписать один и тот же сектор много раз. Таким образом, вы, по сути, собираетесь генерировать очень небольшое количество записей на сектор, и это то, что действительно имеет значение.

Предполагая, что вы не полностью заполняете твердотельный накопитель, должно быть достаточно свободного места для тех горячих точек (таких как буферы / замена), которые создаются для минимизации износа с помощью алгоритмов выравнивания износа.

(Индексы могут быть другим вопросом. Поскольку кластеризованные индексы во многих БД вносят множество изменений по мере вставки данных. Обычно при выполнении больших операций в среде хранилища данных вы отключаете индексы во время массового импорта, а затем обновляете их после.)

Это не проблема.

Прежде всего, SSD значительно улучшились за последние годы. Избыточное выделение и выравнивание износа (и, в небольшой степени, команда TRIM, хотя и не применимо в вашем случае) сделали их вполне пригодными в качестве сверхмощных дисков общего назначения. Я не использую ничего, кроме SSD, на своем компьютере для разработки (который регулярно выполняет большую часть компиляции), даже не приближаясь к количеству циклов стирания.

Далее это утверждение:

Твердотельные накопители не любят массовых непрерывных записей, и это может привести к их повреждению

это совершенно неправильно. Наоборот, частые небольшие записи , во всяком случае, могут привести к повреждению твердотельных накопителей.

В отличие от традиционных жестких дисков, твердотельные накопители (или, скорее, флэш-память на основе NAND) физически организованы в большие блоки, которые логически содержат несколько секторов. Типичный размер блока составляет 512 КБ, тогда как секторы (которые являются единицей, которую использует файловая система) традиционно составляют 1 КБ (возможны разные значения, два десятилетия назад 512 В были обычным явлением).
С 512kB-блоком можно сделать три вещи. Его можно прочитать, часть его или все можно запрограммировать (= записать), и все это можно стереть. Стирание - это то, что проблематично, потому что количество циклов стирания ограничено, и вы можете стереть только полный блок.

Поэтому большие записи очень удобны для SSD, а маленькие - нет.

В случае небольших записей контроллер должен прочитать блок, изменить копию, стереть другой блок и запрограммировать его. Без кеширования, в самом худшем случае, вам потребуется стереть 512 000 блоков, чтобы записать 512 килобайт. В лучшем случае (большая непрерывная запись) вам нужно сделать ровно 1 стирание.

Выполнение импорта в базу данных MySQL сильно отличается от выполнения множества отдельных запросов на вставку. Движок способен объединять множество записей (как данных, так и индексов) вместе и не нуждается в синхронизации между каждой парой вставок. Это составляет гораздо более дружественный для SSD шаблон записи.

SSD не нравятся. Если вы сохраняете максимальную скорость записи в течение 5-10 лет (24 часа в сутки, 7 дней в неделю), то у вас может получиться сломанный SSD.

Ofc. Через 5 лет большинство серверов достигли своего экономичного конца.

Отказ от ответственности:
не пытайтесь сделать это с самым первым поколением SSD. Те, где менее устойчивы.

Если вы действительно заинтересованы в выяснении деталей, то вам нужно ответить на следующий вопрос:

В среднем, сколько байтов в каждом ряду?

Если вы можете сказать мне, что есть 10 столбцов, каждый столбец - varchar (100), а кодировка - UTF-8, то в худшем случае я могу предположить, что у вас есть 4000 байтов данных на строку и добавьте еще несколько байтов для метаданные, так скажем, 4200 байт?

Ваш SQL пытки вычисляет до 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesданных, записанных на диск

42 000 000 000 000/1000 = 42 000 000 000 КБ

42 000 000 000/1000 = 42 000 000 МБ

42 000 000/1000 = 42 000 ГБ

42 000/1000 = 42 ТБ

В этом теоретическом наихудшем сценарии вы будете записывать 42 ТБ на диск

Согласно этой статье , предоставленной @KronoS, вы должны быть готовы еще к 25 раундам своего пыточного SQL.

Как сказал автор этой записи на твердотельных накопителях , то, что действительно вредно, это снова и снова записывать небольшие куски данных.

• биты сохраняются в {1,2,3} -битных ячейках. У них ограниченная продолжительность жизни.
• ячейки сгруппированы в страницы размером [2-16] КБ (наименьшая записываемая единица)
• страницы сгруппированы в (128-256 стр.) блоков (наименьший стираемый блок)
• для перезаписи страницы сначала необходимо удалить ее - и весь ее блок -

Вот почему рекомендуется

• никогда не пишите меньше страницы сразу,
• небольшие буферы записи и
• отдельные запросы на чтение и запись
• «Большая однопоточная запись лучше, чем многие параллельные записи»

Таким образом, действительно большое количество сразу кажется намного лучше.