Paromshick
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
igor me v2
Цитата:| Ну, так и разговор о том, что шина и "мозги" контроллёра быстрее в несколько раз механики дисков. И при распараллеливании запросов, |
Ну что вы за упертые люди. Что вы с этой прараллелью? Я понимаю, слово красивое, в пантеоне программистких богов присутствующее. Сам люблю "параллелить". Но не тот случай/
Два дика в зеркале! Два! Как вы распараллелите запись? Условие ОБЯЗАТЕЛЬНОЕ:
Пока. Один. Бит. НЕ. Будет. Записан. На. КАЖДЫЙ (КАЖДЫЙ!!!) Диск.
То есть дважды. Один бит - записывается дважды. На каждый диск по одному разу. Получается -ДВАЖДЫ! UNDERSTAND???
Так вот, спокойнЕе уже... Пока бит не будет записан на каждый диск контроллер рейда считает, что операция записи не закончена. И ждет от каждого диска подтверждения, что бит записан. В идеальном случае, когда идет потоковая запись одного, но великого файла, головки дисков работают синхронно и быстродействие массива из двух НЖМД строго равно (=) равно
БЫСТРОДЕЙСТВИЮ ОДНОГО (ОДНОГО!!!) ОТДЕЛЬНОГО ДИСКА.
Итог = В идеальных условиях, скорость RAID1 равно скорости записи одного отдельно стоящего диска. Это - аксиома. Или доказанная вам на пальцах теорема, как хотите. Заучите уже. Сумма квадратов катетов равна квадрату гипотенузы 
Далее. Real life
Любая операция чтения обслуживается одной из головок, что сразу вносит асинхронность в их работу. Сразу же. Одна пишет сектор, другая читает десять секторов. Но пока вторая читает десять секторов, запись считается не завершенной, ибо один сектор не записан на ОБА диска. Скорость записи падает. Сразу же. На столько, на сколько массив занят чтением.
Поняли?
И вот тут уже вступают в работу алгоритмы контроллера, который может, пользуясь тем, что чтение идет в два раза быстрее "распараллелить" работу чтения - записи. Но он не знает, какие данные придут по шине, и спекулятивно (знакомое слово?) произвести запись абы чего не может. А вот считать - да. Предположив 50\50, что за сектором 1234 будет команда считать сектор 1235 он может этим воспользоваться. Как и кучей всего другого, что бы снизить потери. Потому я и написал, что можно обсуждать модель контроллера, размер кэша (кэш же записи, нафиг он по вашему нужен вообще???) и... то, что на писал. Но, с разработчиками.
В сухом
1 - Скорость записи RAID1 не может быть выше, чем у отдельного диска по причинам описанным выше
2 - В нагруженных ссистемах, когда идет параллельное считывание и запись большого объема информации в десятки фрагментированных файлов, а это типично для диска, обслуживающего журналы, общая скорость проведения транзакции на RAID1 обычо принимается за 50% от скорости отдельного диска.
Сама цифра обсуждаемая. Но НИЧЕГО более.
Поэтому, бывает, что под транзакционный журнал используется один, но скоростной диск. И бывает даже такой, что при емкости в 100Г может стоить 3 ляма. Вы их не найдете в магазах. Товар штучный, применяется в высоконагруженных базах, где сотни тысяч транзакций в минуту - это норма. Закрытые файлы журнала в плановом порядке делают shipping куда-нибудь. Риск потерять данный в несколько секунд, но при этом увеличить скорость проведения транзакций в разы нивелируется чем-нибудь. Чем угодно.
Мы что здесь обсуждаем? Первый скуль контрафака или архитектуру датацентров страховых компаний, ведущих онлайн торговлю по всему миру?
Всё. Хватит. Баста.
Кто еще скажет мне, что RAID1 записывает быстрее одного диска из-за распараллеливания, тот пойдет в игнор. Отлучён будет от общения Ибо отъедаете по 30-40 минут, демоны. Это академический час, между прочим. Вот где вас прараллелить учили, там и спрашивайте, а ко мне не суйтесь.
Ничего личного, времени жалко.
|
Но так иногда легко идёт, особенно, когда не особо вникаешь... Чтение, запись... Параллельно. 
по этому скорее обойдемся 2я уровнями - Hyper-V неделю один раз и SQL базы - каждый день, как написали выше 
