Откопали какой-то пыльный скелет в старом шкафу, археологи.

Гаджимурадов РустамДело в том, что кому вообще нафиг нужны эти многофайловые БД сегодня.В том виде в каком оно есть - никому.
arniТеоретически можно разнести на разные носители и поднять i/o (правда ценой снижения надежности системы).Для этого разносить надо на очень много кусочков, что окончательно сольет доступность системы в сторону плинтуса. И то результат будет рэндомным, ибо нет возможности зарулить что и куда класть. Железный рэйд контроллер все зарулит куда лучше, причем с гарантиями скорости и отказоустойчивости.

Гаджимурадов РустамС чего это вдруг?С того, что дисковый IO будет гарантированно размазан по всем накопителям, плюс кэширование в ОЗУ рйэда (и/или специально обученной флешке при рэйде). В случае многофайловой БД такой гарантии нет. Вся "активная" часть может угодить на один накопитель и, соответственно, никакого ускорения не будет.
Гаджимурадов РустамКак раз по этой части железный рэйд ничего не зарулит и ничем не поможет.Если взять СХД классом повыше лоулевела, хотя бы мидрэйнж, то оно именно и зарулит активную часть на самую быструю рэйд группу и будет по максимуму держать оную часть в своем кэше.

Гаджимурадов РустамА нужно не размазывание, а неравномерное распределение.Рустам, ты говоришь загадками, ну как минимум я тебя сейчас не понял.

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

Не может чисто технологически многовайловая БД на N одиночных дисках работать быстрее, чем та же БД на тех же дисках, но собранных в рэйд10 на вменяемом современном контроллере.

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

Гаджимурадов РустамВо-вторых, само по себе "БД работает быстрее"Термин можно и перефразировать. :)

Гаджимурадов РустамНа SSD я кидаю OLTP-часть,
которая нужна всем и постоянно, а на 5400 кидаю ту,
что нужна раз в неделю, только одному отделу для
отчётов и её скорость некритична, могут и подождать.Само по себе это решение не очень технологично, т.к. требует наличия в сервере дисков как минимум двух типоразмеров, и для достижения желаемого эффекта их надо разнести по контроллерам, т.е. 2 контроллера. Диски надо как минимум зазеркалить и добавить по однуму хотспаре под каждый типоразмер, ага, привет накладным расходам.

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

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

Как резюме, куда более технологично будет выглядить 2 типовых взаимозаменяемых сервера на репликации, один для ОЛТП, один для ОЛАП.

Гаджимурадов РустамМы не технологичность обсуждаем, а производительность.Ага, давай замутим рэйд0 или разложим базу на 4 одиночных диска? Производительность будет зашибись. Как админ я такое предложение заверну, просто без объяснений. Вариант без резервирования дисков для продакшн сервера я не рассматриваю по определению, ибо дохлые диски не единожды держал в руках. Пока с твоей строны другого предложения не было, поэтому нет предмета обсуждения.

Гаджимурадов РустамОпять ты со своими витаниями в облаках, спустись на землю.Сдается мне ситуация ровно обратная. Я исхожу из простых вводных: все дисковые накопители сдохнут, кто-то раньше, кто-то позже.