Практическое правило: SATA для хранения и обслуживания статического контента, SSD/SAS для баз данных?

Практическое правило: SATA для хранения и обслуживания статического контента, SSD/SAS для баз данных?

Вопрос говорит сам за себя. Но правда ли это? Может кто-нибудь объяснить, в чем здесь дифференцирующий фактор (чем один тип диска лучше другого для определенной цели)?

(К вашему сведению, я пробовал искать, и мне показалось, что все в порядкеодна статья, который был написан примерно 3 года назад.)

решение1

Больше нет. Вы также можете вполне успешно запускать базы данных дисков SATA - WD Velociraptor вполне сопоставимы со многими дисками SAS, если только вы не хотите ДЕЙСТВИТЕЛЬНО высокой производительности (так что база данных != база данных).

Больший шаг — от 3,5" до 2,5" — вы экономите много денег (за гигабайт) при использовании больших и медленных 3,5-дюймовых дисков.

Факторы дифференциации:

  • Диски SAS обычно быстрее и поддерживают более длинные очереди команд, чем SATA (ограничение в 32 против НАМНОГО большего).
  • SSD — это уже другая история. Речь идет о 60.000 IOPS против 450.

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

решение2

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

Диски SATA обычно имеют меньшее среднее время до отказа, медленнее и хуже работают при случайном вводе-выводе. В результате их стоимость за ГБ ниже.

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

Это особенно актуально для веб-сайтов, где 90% представленных данных составляют 99% запросов.

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

Помните, что существует так много оттенков серого, что все не так просто и прямолинейно.

  • Может быть, ваша база данных используется нечасто?
  • Возможно, вы точно знаете, какие таблицы будут прочитаны и какова вероятность использования данных?
  • Может быть, записи в базу данных вообще не производятся?
  • Возможно, те же показатели времени отклика и параллелизма, которые вы ищете, можно эффективно достичь с помощью SATA?

Я бы не сказал, что есть «правило большого пальца». Вместо этого, почему бы не провести некоторые измерения ввода-вывода для вашего приложения сейчас и не узнать, что, по вашим прогнозам, может понадобиться через 2 года. Как вы думаете, подойдет ли SATA тогда? А как насчет SAS? Может быть, SSD еще лучше? Если вы говорите о 30 мс более быстром времени извлечения с SAS, действительно ли стоит тратить больше? Требуют ли ваши клиенты эту дополнительную скорость в 30 мс?

Для большинства моих работ цифры, которые генерируются в ходе нашей работы, на самом деле не гарантируют SAS. И - в любом случае, разница в производительности, которую вы получаете по сравнению со стоимостью за ГБ, не так уж и привлекательна для меня. Теперь, когда на рынке появились SSD, я еще меньше впечатлен предложениями SAS.

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

Связанный контент