Мне все время говорят, что для повышения производительности SQL-сервера покупайте самые быстрые жесткие диски с RAID 5 и т. Д.
Поэтому я подумал, почему бы вместо того, чтобы тратить все деньги на RAID 5 и супер-быстрые жесткие диски (что, кстати, недешево), просто не получить тонны оперативной памяти? Мы знаем, что SQL-сервер загружает базу данных в память. Память намного быстрее, чем любые жесткие диски.
Почему бы не разместить на сервере 100 ГБ ОЗУ? Тогда просто используйте обычный жесткий диск SCSI с RAID 1. Разве это не было бы намного дешевле и быстрее?
Ваш анализ хорош - до определенной степени - в том смысле, что он действительно ускорит работу. Тем не менее, вам все еще нужно учитывать несколько других проблем:
Не каждый может позволить себе достаточно памяти; когда у вас есть несколько терабайт данных, вы должны какое-то время поместить их на диск. Если у вас мало данных, все будет достаточно быстро.
Производительность записи для вашей базы данных по-прежнему будет ограничиваться дисками, поэтому вы можете сдержать обещание, что данные действительно были сохранены.
Если у вас небольшой набор данных или нет необходимости сохранять его на диске, в вашей идее нет ничего плохого. Такие инструменты, как VoltDB работают над сокращением накладных расходов, которые делали старые предположения в реализациях РСУБД, которые ограничивают чистую производительность в памяти.
(Кстати, люди, которые говорят вам использовать RAID-5 для повышения производительности базы данных, вероятно, не лучшие люди, чтобы слушать по этому поводу, поскольку это почти никогда не лучший выбор - у него хорошая производительность чтения, но плохая производительность записи и записи почти всегда являются производственным ограничением, потому что вы можете использовать оперативную память для кэширования, чтобы решить большинство проблем с производительностью чтения.)
Краткая версия: учитывайте размер рабочего набора. Длинная версия: Насколько велики ваши данные? Если он умещается в памяти современного сервера, да, вы абсолютно правы. К сожалению, самый большой Xeon может адресовать 2 ТБ ОЗУ прямо сейчас, и это уже не так уж и большой набор данных. Если вы не можете купить машину, достаточно большую, чтобы вместить весь ваш рабочий набор в ОЗУ, вы вынуждены решать проблемы своим мозгом, а не кошельком.
Если вам нужна скорость:
Выполните эти шаги, и SQL Server взлетит.
Затем, если хотите, добавьте больше ОЗУ ... но сначала сделайте то, что описано выше, и вы вполне можете обнаружить, что все готово.
RAM - это новый диск, диск - это новая лента.
В http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Обратите внимание, это было шесть лет назад. Да, у нас есть системы баз данных, которые стараются (и очень стараются) хранить весь набор данных в ОЗУ и скорее сегментировать на несколько машин, чем использовать диск, потому что диск в любом случае намного медленнее. Вам нужно записать набор данных на диск, но, как указано в девизе выше, это больше похоже на фоновую задачу резервного копирования, чем на оперативную операцию. Надежность достигается за счет добавления только журналов к этим базам данных (я думаю, MongoDB и Redis, но их гораздо больше).
Этот вопрос похож на основной, который привел к многочисленным исследованиям и разработкам в области архитектур баз данных за последние 5-10 лет. Теперь, когда стало возможным хранить всю базу данных в ОЗУ для многих случаев использования, база данных должна быть спроектирована для работы в ОЗУ, а не просто применять старые унаследованные архитектуры к хранилищу на основе ОЗУ.
Так же, как в последние годы получили широкое распространение многие более мелкие и специализированные языки, мы вступаем в эпоху, когда потребуется больше специализированных баз данных.
Для дальнейшего чтения по этой теме я рекомендую научную статью Конец архитектурной эры (пришло время полностью переписать). Прочитать это не сложно.
Неясно, касался ли этот вопрос конкретно SQL Server. Оригинальный плакат должен прояснить это.
Дэниел Питтман писал:
Если у вас небольшой набор данных или нет необходимости сохранять его на диске, в вашей идее нет ничего плохого. Такие инструменты, как VoltDB, работают над уменьшением накладных расходов, связанных с более старыми предположениями> в реализациях СУБД, которые ограничивают чистую производительность в памяти.
Снижение накладных расходов от старых предположений в реализациях РСУБД было именно целью разработки. VoltDB, но он масштабируется по горизонтали без архитектурных ограничений на размер данных и может сохраняться на диске для обеспечения полной надежности с помощью моментальных снимков и ведения журнала команд.
Если вы можете получить сервер с достаточным объемом оперативной памяти, чтобы удерживать, по крайней мере, самую горячую часть вашего набора данных, все будет в порядке. Кроме того, RAID 1 и 5 - не самый быстрый способ упорядочить ваши данные - RAID 0 быстрее, но тогда вам придется учитывать более высокие шансы сбоя файловой системы, который уничтожит вашу базу данных - это нехорошо. . Вы можете использовать RAID 1 или RAID 5 в своем массиве RAID 0, если у вас достаточно дисков и контроллеров.
Здесь вы даже можете поиграть с репликацией - выполняйте запись на сервер с большим объемом памяти, который реплицируется на один или несколько серверов с тяжелым объемом памяти, где вы выполняете сложные запросы.
К сожалению, СУБД, похоже, относятся к сфере большого железа - их не так-то просто развивать по горизонтали.
Это случай, когда «это зависит от того, что вы делаете». Возможно, «правильный» совет - полностью отказаться от SQL и использовать memcache / redis / etc!
Я согласен с вами, что дополнительная оперативная память очень поможет, особенно если вы можете прочитать весь рабочий набор в оперативную память. Да, ему все равно придется записывать данные, но если у вас в основном операции чтения, то при записи не будет конкуренции за дисковый ввод-вывод.
Однако производительность дисков часто является узким местом на серверах SQL, и их сложнее, чем другие вещи, такие как ОЗУ, обновить позже (если у вас есть сервер, который не полностью заполнен модулями DIMM).
Было много комментариев о том, что RAID5 работает медленно, но я бы сказал, что это не всегда так, поэтому будьте осторожны, прежде чем делать резкие заявления. Действительно высокопроизводительные серверы с быстрыми картами RAID и большим количеством BBWC иногда работают намного быстрее в RAID5 (или RAID50 с> 4 дисками), чем в RAID10 ...
На протяжении многих лет я лично сталкивался с медленными массивами RAID5, но после тестирования DL360 G5 с 4 дисками 146G SAS в ~ 2009 году нам пришлось дважды проверить наши тесты. Действительно, почти во всех тестах массив работал быстрее с RAID5, чем с RAID10. BBWC и быстрые вычисления четности позволили серверу использовать 4 диска гораздо более эффективно в качестве массива RAID5, чем RAID10. Некоторые тесты показали на 50% лучшую пропускную способность с RAID5, и почти ни один из них не был медленнее. На более медленные тесты была скидка всего 5-10%.
Я хотел бы предостеречь людей, которые делают общие заявления, что RAID5 медленный, все говорят об этом в Интернете, но это просто не во всех случаях.
У вас есть набор конфет на выбор, и это действительно зависит от того, какой вкус вам нужен.
Просто вкладывайтесь в знания (бесплатно), прежде чем выкладывать деньги. 1. Изучите конфигурации для своей базы данных и посмотрите на текущую конфигурацию для оптимизации. 2. Посмотрите на программирование и операторы sql, модульный тест с простыми сценариями, которые имитируют задействованные операции, это может быть даже не то, что вы думаете, является проблемой. ЕСЛИ простые скрипты занимают время с использованием SQL-соединений, разделите их и сделайте то же самое с запрограммированным циклом, чтобы сделать то же самое. Здесь может помочь память. 3. Посмотрите на план хостинга и сервер. Используйте ps aux в консоли Linux и посмотрите, не забирает ли что-то вашу память и процессор.
Жесткий диск Absolutes увеличивает скорость, но это не зависит от вас в пространстве виртуального сервера. Память не увеличивает скорость, если вы не настроите для нее службы, точка. Чередующийся RAID (0,5), число оборотов в минуту и синхронное чтение / запись с быстрой шиной помогают в этом. Ядро процессора с хорошей кэш-памятью l1, l2, l3 поможет при обработке узких мест. могу я услышать это для Xeon!
В целом, вы должны помнить о размере и масштабируемости. Вам может показаться, что вначале требуется небольшое хранилище, но ваши данные будут расти очень быстро и экспоненциально. БД лучше всего использовать атомарные данные, которые представляют собой данные, разбитые до минимально возможного размера. Из-за своего небольшого размера он быстрее перемещается в хранилище данных. Затем вы также учитываете структуру БД. В будущем вы можете связываться с внешними базами данных, поэтому структура также имеет решающее значение. В этом сценарии для вашего запроса будет мало разницы, если половина данных находится за пределами вашего киоска данных. Когда запрашиваются данные, дело не в том, чтобы хранить данные в ОЗУ; скорее, запрос должен быстро получать доступ к данным и возвращать их.