Чтобы повысить производительность SQL, почему бы просто не разместить много оперативной памяти, а не иметь более быстрые жесткие диски?


31

Люди постоянно говорят мне, что для повышения производительности SQL-сервера покупайте самые быстрые жесткие диски с RAID 5 и т. Д.

Поэтому я подумал, что вместо того, чтобы тратить все деньги на RAID 5 и супер-быстрые жесткие диски (что, кстати, не дешево), почему бы просто не получить тонны оперативной памяти? Мы знаем, что SQL-сервер загружает базу данных в память. Память гораздо быстрее любых жестких дисков.

Почему бы не разместить около 100 ГБ ОЗУ на сервере? Тогда просто используйте обычный жесткий диск SCSI с RAID 1. Разве это не будет намного дешевле и быстрее?


33
Кто бы ни говорил вам RAID 5, понятия не имеет. Если вы действительно заботитесь о производительности, используйте RAID 10
MDMarra

5
Что означает D в ACID? В конце концов, вам нужно будет записать материал.
Адам Муш

Ответы:


51

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

  1. Не каждый может позволить себе достаточно памяти; если у вас есть несколько терабайт данных, вы должны поместить их на диск некоторое время. Если у вас мало данных, все достаточно быстро.

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

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

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


1
Обычные пользователи всегда жалуются на проблемы с чтением. Редко по вопросам записи
user1034912

2
@ user1034912 - зависит от варианта использования и пользователей. Как правило, проблемы с производительностью записи труднее решить, и в конечном итоге они накладывают большие ограничения на общую производительность системы, а это означает, что когда вы решаете проблему чтения, они начинают жаловаться на проблему записи ...
Даниэль Питтман,

2
@ user1034912, пользователи обычно не видят задержек записи, поэтому не знают о них. Большая часть того, что пользователи видят как задержки чтения, связана с медленными запросами, а не с медленными дисками.
Джон Гарденерс

Отличный ответ! @ user1034912 они могут жаловаться на проблемы с чтением, которые, конечно, могут быть косвенным эффектом низкой производительности записи (и плохого масштабирования кода параллелизма).
Алекс

RAID5 в реляционных базах данных: en.wikipedia.org/wiki/… - Я не говорю, что вы не правы, но общепринятая мудрость может основываться на старой информации. Лично я больше не использую RAID5; Я использую RAID6, если он не слишком медленный.
gWaldo

11

Краткая версия: рассмотрим размер рабочего набора. Длинная версия: насколько велики ваши данные? Если он может уместиться в памяти современного сервера, да, вы абсолютно правы. К сожалению, самый большой Xeon может адресовать 2 ТБ ОЗУ прямо сейчас, и это уже не так уж много для набора данных. Если вы не можете купить машину, достаточно большую, чтобы разместить весь свой рабочий набор в оперативной памяти, вы вынуждены решать проблемы с помощью своего мозга, а не своего кошелька.


+1 за последнее предложение, чрезвычайно цитируемое. : D
pkoch

8

Если вы хотите скорость:

  • Увеличьте объем ОЗУ, чтобы по крайней мере часто используемые индексы могли полностью помещаться в ОЗУ (например, в системе, на которой я работаю, 32 ГБ ОЗУ достаточно для базы данных на 350 ГБ, потому что индексы - это то, что вам нужно в ОЗУ, а не необработанные данные)
  • Используйте RAID10 с любыми дисками (более быстрые диски лучше)
  • Избегайте RAID5
  • Разбить mdf, ldf и temp DB на отдельные наборы шпинделей (пример: tempdb в своем собственном наборе RAID1, ldf в своем собственном наборе шпинделов RAID1 или RAID10, mdf на наборе RAID 10 с минимум четырьмя дисками)

Выполните эти шаги, и SQL Server будет летать.

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


2

RAM - новый диск, диск - новая лента.

В http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Обратите внимание, что это было шесть лет назад. Да, у нас есть системы баз данных, которые стараются (и очень стараются) хранить весь набор данных в ОЗУ и скорее разделять их на несколько машин, чем использовать диск, потому что диск все равно на несколько медленнее. Вам нужно записать набор данных на диск, но, как и в девизе выше, это больше похоже на фоновое задание резервного копирования, чем на оперативную операцию. Долговечность достигается за счет добавления только журналов с этими базами данных (я думаю, MongoDB и Redis, но их гораздо больше).


4
-1 потому что, как ни крути, этот материал не очень доступен и не подходит для большинства приложений или большинства из нас. Для данных объемом до 500 ГБ (или даже больше) все, что вам нужно, - это два SQL-сервера (основной и резервный), и вы действительно быстро используете обычные инструменты для сотен или тысяч пользователей. Очень немногим из нас требуется масштабирование до сотен тысяч одновременно работающих пользователей или нескольких центров обработки данных, поэтому сложность предложенного вами подхода значительно перевешивает пользу для большинства из нас. IOW: вертикальное масштабирование легко, дешево и эффективно для всех, кто не является Facebook или Google.
Jonesome Восстановить Монику

1

Этот вопрос похож на основной вопрос, который привел к значительным исследованиям и разработкам в области архитектуры баз данных за последние 5-10 лет. Теперь, когда во многих случаях целесообразно хранить целую базу данных в ОЗУ, базу данных необходимо разрабатывать с учетом работы в ОЗУ, а не просто применять устаревшие унаследованные архитектуры к хранилищу на основе ОЗУ.

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

Для дальнейшего прочтения этой темы я рекомендую академическую статью «Конец архитектурной эры (время полной переписки)» . Это не сложно читать.

Неясно, был ли этот вопрос конкретно о SQL Server. Оригинальный плакат должен прояснить это.

Даниэль Питман написал:

Если у вас небольшой набор данных или вам не нужно сохранять его на диске, в вашей идее нет ничего плохого. Такие инструменты, как VoltDB, работают над тем, чтобы уменьшить накладные расходы, которые давали более старые предположения> в реализациях RDBMS, которые ограничивают чистую производительность в памяти.

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


0

Если вы можете получить сервер с достаточным объемом ОЗУ для размещения хотя бы горячей части вашего набора данных, у вас все будет хорошо. Кроме того, RAID 1 и 5 - не самый быстрый способ упорядочить ваши данные - RAID 0 быстрее, но тогда вам придется учитывать более высокие шансы сбоя файловой системы, который стирает вашу базу данных - это не очень хорошая вещь, чтобы это произошло , Вы можете использовать RAID 1 или RAID 5 в своем массиве RAID 0 при условии, что у вас достаточно дисков и контроллеров.

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

К сожалению, RDBMSs, кажется, находятся в большой железной сфере - их не так просто вырастить по горизонтали.


0

Это случай «это зависит от того, что вы делаете». Возможно, «правильный» совет - вообще избегать SQL и использовать memcache / redis / etc!

Я согласен с вами, что дополнительная ОЗУ очень поможет, особенно если вы сможете прочитать весь рабочий набор в ОЗУ. Да, ему все равно придется записывать данные, но если у вас есть в основном чтение, то записи не будут конфликтовать из-за дискового ввода-вывода.

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

Было несколько комментариев о том, что RAID5 работает медленно, но я бы сказал, что это не всегда так, поэтому будьте осторожны, прежде чем делать широкие заявления. Действительно высокопроизводительные серверы с быстрыми картами RAID и большим количеством BBWC иногда работают намного быстрее в RAID5 (или RAID50 с> 4 дисками), чем в RAID10 ...

На протяжении многих лет я лично испытывал медленные массивы RAID5, но после тестирования DL360 G5 с 4 дисками SAS 146G в 2009 году нам пришлось дважды проверять наши тесты. Действительно, массив работал быстрее с RAID5, чем RAID10 почти в каждом тесте. BBWC и быстрые вычисления четности позволили серверу гораздо эффективнее использовать 4 диска в качестве массива RAID5, чем RAID10. Некоторые из тестов показали на 50% лучшую пропускную способность с RAID5, и почти ни один не был медленнее. Тесты, которые были медленнее, были только 5-10%.

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


-1

У вас есть смешанный пакет конфет на выбор и зависит от того, какой вкус вы хотите.

  1. БД будут иметь конфигурацию для кеширования запросов и, где этот кеш существует, памяти или жесткого диска.
  2. RAID 5 не всегда самый быстрый, но RAID 0 (JBOD) является полосой и быстрым, поскольку RAID 5 также является полосой, идея почти такая же.
  3. RAID 1 не улучшит вашу скорость, это просто зеркало.
  4. Производительность SQL основана на индексировании и проверяется в первую очередь. Очень важно в реляционных базах данных.
  5. Не индексируйте все, переиндексация может также снизить скорость, потому что ваша индексация перегружена.
  6. Иногда с объединениями SQL база данных становится медленнее. Использование программирования для циклического набора минимальных индексированных результатов повышает скорость.
  7. Виртуальные серверы - это кошмар на скорости, если вы не платите доллары.

Проще говоря, вкладывайте деньги в знания (бесплатно), прежде чем раздавать деньги. 1. Изучите конфиги для вашей базы данных и посмотрите текущую конфигурацию для оптимизации. 2. Посмотрите на операторы программирования и sql, модульное тестирование с простыми сценариями, которые имитируют выполняемые операции, это может даже не быть тем, что вы считаете проблемой. Если простые сценарии занимают время с использованием объединений SQL, разделяют их и делают то же самое с запрограммированным циклом, чтобы сделать то же самое. Это где память может помочь 3. Посмотрите на план хостинга и сервер. Используйте ps aux в консоли linux и посмотрите, не загружает ли что-то вашу память и процессор.

Жесткий диск абсолютов повышает скорость, но не зависит от вас в виртуальном серверном пространстве. Память не улучшит скорость, если вы не настроите службы для нее, точка. Помогает это с чередованием RAID (0,5), RPM и синхронного чтения / записи с быстрой шиной. Процессорное ядро ​​с хорошим кешем l1, l2, l3 поможет устранить узкие места. могу ли я услышать это для Xeon!


2
RAID1 абсолютно улучшит скорость в ситуациях чтения. Большинство контроллеров достаточно умны, чтобы использовать несколько шпинделей для одновременного чтения из (идентичных) наборов данных. RAID0 - плохая идея, потому что вы ограничены шпинделем одновременно.
Брайан Бетчер

-4

В целом, вы должны помнить о размере и масштабируемости. Хотя может показаться, что вы начинаете с небольших потребностей в хранении, ваши данные будут расти очень быстро и в геометрической прогрессии. БД лучше всего использовать атомарные данные, которые разбиты до минимально возможного размера. Из-за небольшого размера он быстрее перемещается в хранилище данных. Затем вы также учитываете структуру БД. В будущем вы можете ссылаться на внешние БД, поэтому структура также имеет решающее значение. В этом случае для вашего запроса будет мало что изменить, если половина данных будет находиться за пределами вашей витрины. Когда данные запрашиваются, дело не в том, чтобы хранить сохраненные данные в ОЗУ; скорее, запрос должен быть быстрым в доступе и возврате данных.

  • Вы действительно не всегда используете RAID 5 для данных. Это зависит от данных и их важности, помимо того, что ранее упоминалось о резервных копиях. RAID 1 можно использовать и есть.
  • Вам нужно обновить все серверы в пределах вашего диапазона запросов, чтобы повысить скорость. Поскольку большая часть данных находится вне вашего контроля, это будет узким местом где-то за пределами вашей витрины данных. (В случае, если вы обновите свой собственный)

Вау, ты скопировал это из своего (неправильного понимания) учебника?
Адаптер

Тьфу. Сколько раз нужно говорить людям, что RAID не является решением для резервного копирования?
Cromulent
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.