Распределение базы по разным дисковым массивам

[ZVV]

Про Oracle, но всё-таки...

[SHiSHok]

Цитата:

Сообщение от ZVV

Про Oracle, но всё-таки...

Почерпнул знание о том что разнесение индексов с данными по разным массивам не принципиально для исполнения запроса, так как в транзакции индекс и данные читаются последовательно.
Считаю что разнесение имеет смысл только с целью оптимизации I/O с массива, так как индекс содержит гораздо меньше полей и одна запись индекса имеет гораздо меньший размер чем строка данных. Соответственно чтение одного диапазона индекса и данных породит разный объем I/O, поэтому имеет смысл индекс располагать на массиве с меньшей пропускной способностью (если таковой имеется).

Дальше, думаю, надо рассматривать схему данных акс, для оптимизации исполнения запросов. В первую очередь выносить на другой массив "подключаемые" таблицы, которые чаще участвуют в связках нежели самостоятельно:
1) Для торговли и логистики имеет место быть часто встречающаяся следующая связка: (*trans, *line) -> InventDim -> Invent*. Соответственно InventDim и (*line, *trans , invent*) разносятся по разным массивам.
2) можно разнести DocuRef с DocuValue.

есть еще идеи?

[Vadik]

Цитата:

Сообщение от SHiSHok

есть еще идеи?

Давайте сначала определимся с целью -
а) "распределение ради распределения". Тут число вариантов стремится к бесконечности
б) "отделить финансы от логистики". Да, можно. Только много ли операций в финансах, сильно напряшающих ХД? Знаю пару типа финансовых отчетов (с использованием корреспонденции), не более. Т.о., если просто "все поделить", половина ХД будет нагружена логистикой, половина - простаивать
в) "разнести ради производительности". Интересная тема. Хочу увидеть реально работающую схему. Хочу увидеть сравнение с цифрами "до и после". Еще больше хочу увидеть методику сравнения. Пока видел только теории

Цитата:

и пока склоняюсь к вынесению финансов на DATA2 (у меня сейчас все на DATA1). может фин деятельность в моменты построения отчетов не так сильно будет торговлю напрягать

Если мы знаем, что логистике нужно много IO, imho не очень логично насильно ее "зажимать"

Сам там, где возможно, стараюсь следовать принципу KISS principle

[SHiSHok]

Цитата:

Сообщение от Vadik

Давайте сначала определимся с целью -

Все гораздо прозаичнее - дисковый массив на котором данные уперся в потолок (RAID10: 6 дисков, база порядка 200Gb). т.о. часть данных надо перенести на другой массив (для начала будет 4 диска, потом добью до 6).
Т.е. цель: разнести данные. Можно конечно не заморачиваться - разделил и забыл, потери производительности не будет. Но хочется из необходимости разделения данных выжать максимум.
Методику сравнения вижу только в сравнении показательных запросов на холодном кэше.

[Vadik]

Цитата:

Сообщение от SHiSHok

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

Единственный на мой взгляд способ оптимально утилизировать весь ресурс (все шпиндели) - это как раз "не заморачиваться" и свалить все в одну файловую группу
Если кто-то сможет предложить схему разбиения, которая будет работать шустрее, чем одна файловая группа - welcome, только, по возможности - с цифрами
Если свободное место на сторадже поджимает, можно подумать насчет миграции на raid5. Если ХД относительно новая (выпущена в этом веке) - вполне может справиться, мы на примерно того же размера БД гоняем на CX300 без особых проблем

Цитата:

Методику сравнения вижу только в сравнении показательных запросов на холодном кэше

А транзакции в системе магическим образом возникают - т.е. OLTP нагрузка как таковая отсутствует ?

[SHiSHok]

Цитата:

Сообщение от Vadik

Единственный на мой взгляд способ оптимально утилизировать весь ресурс (все шпиндели) - это как раз "не заморачиваться" и свалить все в одну файловую группу

в одну не выйдет, как минимум 2 (на 1 массив и на другой). или предлагаешь JBOD-массив сделать виндовыми средствами? как по мне так лучше пусть 2 массива будет.

Цитата:

Сообщение от Vadik

Если кто-то сможет предложить схему разбиения, которая будет работать шустрее, чем одна файловая группа - welcome, только, по возможности - с цифрами
Если свободное место на сторадже поджимает, можно подумать насчет миграции на raid5. Если ХД относительно новая (выпущена в этом веке) - вполне может справиться, мы на примерно того же размера БД гоняем на CX300 без особых проблем

Боюсь что схема разбиения (имеется в виду потаблично) во многом будет зависеть от специфики работы Ax в конкретном предприятии. А 5-го рейда побаиваюсь на OLTP системе (я не знаю кто такой CX300).

Цитата:

Сообщение от Vadik

А транзакции в системе магическим образом возникают - т.е. OLTP нагрузка как таковая отсутствует ?

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

[Vadik]

Цитата:

Сообщение от SHiSHok

в одну не выйдет, как минимум 2 (на 1 массив и на другой). или предлагаешь JBOD-массив сделать виндовыми средствами? как по мне так лучше пусть 2 массива будет

Я бы конечно для единообразия слил все в один том (если СХД позволяет, такие фокусы можно на лету проделывать). Не получается слить - не страшно, добавляем в файлгруппу файл на новом массиве, аккуратно сайзим - voila

Цитата:

А 5-го рейда побаиваюсь на OLTP системе

Как я уже говорил, нормально на старичке CX300 (немолодой уже midrange от EMC) на raid5 живет БД тех же размеров

Цитата:

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

При такой постановке - наводящий вопрос можно? Если запускать поочередно "тяжелые" с т.зр. ввода-вывода запросы из логистики и финансов в двух конфигурациях - каждому из модулей отдана половина физических дисков или данные "размазаны" по всем - какая из конфигураций победит и за счет чего ?