Вопрос железячникам и БД админам (+)

[aldep]

Есть такая ситуация. Вся база состоит из 4 таблиц, каждая имеет около 1000 столбцов и 12 млн записей. Полный размер базы около 500 ГБ.
Все таблицы имеют один числовой Primary Key.
Базы не обнавляются после создания. Все запросы только на чтение.
Запросы выдаются в основном пачками по 4, по одному к каждой таблице и могут исполняться параллельно. Запросы выполняют аггрегацию данных по критерию налагаемому на Primary Key (путем join c другой таблицей).
Возможна ситуация, когда 2-4 таких пачек запрашивается одновременно.
Один из важнейших параметров это скорость выполнения.
С точки зрения запросов оптимизировать, похоже нечего. А как насчет железа?
Кто-то может подсказать какую железную конфигурацию лучше всего использовать для этой задачи? Опции, которые я вижу RAID 0/5, internal/external SCSI array?
Стоит ли разбить базу на несколько: каждая на отдельном диске/контроллере?
Что здесь будет узким местом: контроллер, диск?

Спасибо!

[Zy]

Недостаточно информации.

Какая СУДБ, во-первых. Например, оракл может разбивать одну таблицу по разным дискам в зависимости от значения первичного ключа.

Во-вторых, какие запросы? Есть какая-то система, или запросы безсистемные? Если база статическая и есть система, по которой строятся запросы, то тогда о чем-то можно говорить. А если нет, то просто размазывать по дискам (raid или просто много дисков) да и все. IMHO.

[aldep]

СУБД - СКЛ сервер, он может делать patitioned tables, и мы это попробуем.

База статическая. Запросы в упрощенной форме такие:
Есть вспомогательная таблица с ID, там может быть от 1 до 12 млн записей.
Надо найти сумму значений во всех столбцах всех 4-х больших таблиц записей с ID из вспомогательной таблицы.
[/quote]

[Zy]

Т.е. запрос идет по primary key по каждой из таблиц. Т.е. если каждая таблица будет разбита по максимальному количеству дисков по признаку primary key, ты и получишь независимую работу отдельных дисков при параллельных запросах.

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

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

[aldep]

В том смысле, что есть конференции по БД, может, лучше там спросить?

Одно другому не мешает. Там я тоже спросил

Спасибо!

[папа Карло]

РАИД 10. набить чем больше дисков тем лучше. 15К оборотов. дисками короткими (т.е. 18-36гиг) они быстрее.если за раз вычитывается большой объем данных то 2 гига памяти на 1 проц, если запросы "короткие", то 1 Гиг на проц.

Удачи!

[Yuri Dimant]

aldep,а сеичас -то у тебя что за железо стоит?
1000 столбцов гооворишь, а не многовато ли?
Почему ты решил что запосы уже нельзя оптимизировать? Показал бы нам?

Я согласен с папои по поводу raid10 ,но прежде чем "лезть" в железо,может сначала с запрсом поработать

[aldep]

aldep,а сеичас -то у тебя что за железо стоит?
1000 столбцов гооворишь, а не многовато ли?
Почему ты решил что запосы уже нельзя оптимизировать? Показал бы нам?

4-CPU DELL with 4GB и ЭТО http://www.nexsan.com/products/products ... aboy2.html
Вопрос как ЭТО оптимально сконфигурить.

Я согласен с папои по поводу raid10 ,но прежде чем "лезть" в железо,может сначала с запрсом поработать

Запрос простой, так:
Select avg(t.col1), ... avg(t.col1000) FROM MyBigTable t, #MyIDs m
where m.id=t.id

Таблица #MyIDs временная и зависит от запроса, может содержать от 1 до всех 12 млн. id
id это primary clustered key в MyBigTable
Вроде тут оптимизировать нечего. И есть?

[aldep]

РАИД 10. набить чем больше дисков тем лучше. 15К оборотов. дисками короткими (т.е. 18-36гиг) они быстрее.

Так и сделаем.

если за раз вычитывается большой объем данных то 2 гига памяти на 1 проц, если запросы "короткие", то 1 Гиг на проц.

Удачи!

У нас так и стоит.

Спасибо!

[Yuri Dimant]

adep
AWE открыто или \3ГБ в ини фаиле?
http://support.microsoft.com/default.as ... 50&sd=tech

Первое
Select avg(t.col1), ... avg(t.col1000) FROM MyBigTable t INNER JOIN #MyIDs m ON m.id=t.id

Второе
Рассмотри создание an indexed view (заменить #т на перманент таблицу)

И еще ,ты выполняешь агрегацию без WHERE condition ,просто тал на всю таблицу?

[aldep]

Вроде определились с конфигурацией.
при числе одновременных запросов больше 10 лучше всего RAID 10, при меньшем числе RAID 5.

Спасиб.