Размещение журнала транзакций на отдельном томе [в твердом состоянии]?


12

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

(Извините за наивную интерпретацию. Просто пытаюсь разобраться в том, что я прочитал.)

Имея это в виду ... Мне приходит в голову, что твердотельные накопители не имеют маленьких игл и пластин и тому подобного, движущихся внутри них. Если моя база данных и журнал транзакций расположены на одном RAID 5 из восьми твердотельных дисков, есть ли смысл переместить журнал транзакций на отдельный том? Если предполагаемое повышение эффективности основано на предпосылке последовательных записей, сокращающих расстояние, на которое перемещаются иглы, и вращаются пластины, а твердотельный накопитель не имеет ни одной из этих движущихся частей, что я получу, изолировав бревно?


У вас все еще есть автобусы и буферы для рассмотрения. Я бы держал их отдельно из-за различий в шаблонах ввода / вывода. Если ваши приложения не очень транзакционные, вы вряд ли узнаете разницу, если стоимость является проблемой.
Эрик Хиггинс,

Когда вы используете термин «шина» ... вы имеете в виду путь, по которому данные переходят с материнской платы на карту RAID?
Чад Декер

2
"действительно ли есть какая-то польза от перемещения журнала транзакций на отдельный том?" почти наверняка нет, но на самом деле скорость переноса массива на RAID10 повышается, а надежность повышается за счет избыточного выделения ресурсов (т. е. недостаточного разделения)
говорит Джек, попробуйте topanswers.xyz

Ответы:


10

Короткий ответ, используйте один массив, вряд ли будет какой-либо выигрыш в производительности при отделении журналов от данных на 8 SSD-дисках. См. SQL на SSD: Hot and Crazy Love для более подробного (и занимательного) комментария к SSD. Обратите особое внимание на заметки о взаимосвязанных сбоях твердотельных накопителей.

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

Комментарии относительно пропускной способности шины не имеют значения. Если вам нужно сместить столько IO, у вас есть более серьезные проблемы, о которых нужно беспокоиться.


-4

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

Поэтому для них я хочу спросить: «если нет проблемы спора, то почему именно RAID 10? Больше нет необходимости в разборке! Так что одного зеркалирования будет достаточно, и, конечно, нет необходимости в 8 дисках, 2х базе данных размера должно хватить!

Однако реальность такова, что если что-то требует RAID 10, это файл журнала!

Это не только из-за проблемы последовательного и случайного (см. Ресурсы ниже), но это на самом деле очень важно, когда вы понимаете, как работают SSD-диски.

Короче говоря (более подробное описание см. Http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/ ), SSD-накопитель очень эффективен при чтении и записи нулей, однако записать их не так эффективно, так как необходимо стереть весь раздел, чтобы записать даже один!

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

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

СТАРЫЙ ОТВЕТ

Ответ - да, по трем причинам. 1) Случайные и последовательные. Хотя очевидно, что твердотельные накопители резко повысили производительность при случайных записях, проблема случайных и последовательных операций остается, как видно из следующих статей и ссылок:

2) Надежность. Существует большая вероятность того, что все SSD-диски выйдут из строя одновременно, и в этом случае RAID не является защитой, однако, поскольку SSD-диск, используемый исключительно для последовательного подключения, имеет другой срок службы, это может быть вашим спасителем

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

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

Фактически, для журналов вы можете использовать обычные жесткие диски в качестве официального документа Dell по адресу http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf.

РЕДАКТИРОВАТЬ

Microsoft рекомендует размещать tempdb в своем собственном массиве для вращающихся дисков, см.

и многие другие, и это общепринятое понятие в Sql Server, хотя никто не выразил проблемы с разбиением массива.

Более того, команда разработчиков SQL Server создала концепции разделения на группы и разделы файлов с единственной целью перенести их в отдельный массив.

И на самом деле MSDN по адресу http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) рекомендует выиграть в производительности от разделения некластеризованного индекса на свой собственный массив (хотя это не должно восприниматься как общий совет для каждой ситуации, только для определенных рабочих нагрузок, см. дополнительную информацию на http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx ).

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

Хотя может случиться так, что некоторые люди не согласятся с этим советом и считают, что нет никакой пользы от помещения tempdb и его собственного тома (как Джек Дуглас), и вы можете даже утверждать, что нет никакой выгоды от разделения файлов журналов (как Марк Стори) -Smith), и вместо этого утверждают, что разделение массива гораздо хуже, все же не забывайте, что это новый подход, идущий вразрез с общепринятым подходом, предложенным Microsoft и сообществом, и до сих пор никто не предоставил ссылки на какие-либо эталонные тесты, чтобы поддержать это.

Таким образом, я хочу сказать всем новичкам: очень неэтично опровергать сообщение только потому, что оно отличается от вашего, особенно когда 1) ваше мнение противоречит общепринятой теории 2) и против поставщиков (Microsoft ) собственная документация 3) и вы не предоставили никаких доказательств, только мнение.

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

Скажем, кто-то решает, что RAID - это теория старой школы, и отрицает все посты, рекомендующие его, как это имеет смысл?


Комментарии не для расширенного обсуждения; этот разговор был перенесен в чат .
Пол Уайт 9
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.