ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как физически лучше разместить БД.
18 сообщений из 18, страница 1 из 1
Как физически лучше разместить БД.
    #33307503
aldep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aldep
Гость
Есть такая ситуация. Вся база состоит из 4 таблиц, каждая имеет около 1000 столбцов и 12 млн записей. Полный размер базы около 500 ГБ.
Все таблицы имеют один числовой Primary Key.
Базы не обнавляются после создания. Все запросы только на чтение.
Запросы выдаются в основном пачками по 4, по одному к каждой таблице и могут исполняться параллельно. Запросы выполняют аггрегацию данных по критерию налагаемому на Primary Key (путем join c другой таблицей).
Возможна ситуация, когда 2-4 таких пачек запрашивается одновременно.
Один из важнейших параметров это скорость выполнения.
С точки зрения запросов оптимизировать, похоже нечего. А как насчет железа?
Кто-то может подсказать какую железную конфигурацию лучше всего использовать для этой задачи? Опции, которые я вижу RAID 0/5, internal/external SCSI array?
Стоит ли разбить базу на несколько: каждая на отдельном диске/контроллере?
Что здесь будет узким местом: контроллер, диск?

Спасибо!
...
Рейтинг: 0 / 0
05.10.2005, 20:10
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33307529
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
я правильно понял, что все четыре таблицы связаны один к одному между собой?
Очень смущает количество полей... Какова доля заполнения таблиц данными?

Каково количество реально выбираемых записей за один запрос?
Каково распределение выбранных данных по таблицам (ближе к началу/концу/равномерно и т.п.)?
Какая СУБД? возможно, может смена СУБД или даже переход на плоские файлы.
Каково железо и быстродействие сейчас и насколько высокого прироста быстродействия нужно достичь?
Под скоростью выполнения понимается количество запросов в секунду или время выполения запроса?

Вполне возможно, что достаточно будет увеличить оперативную память (желательно, чтобы индексы полностью умещались в памяти)
...
Рейтинг: 0 / 0
05.10.2005, 20:33
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33307551
aldep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aldep
Гость
miksoftя правильно понял, что все четыре таблицы связаны один к одному между собой?

Да.
miksoft
Очень смущает количество полей... Какова доля заполнения таблиц данными?

Пустых значений нет. Все поля заполнены
miksoft
Каково количество реально выбираемых записей за один запрос?

Зависит от запроса. Выборка может быть из 10 записей, а может быть из всех 12 млн. Т.е. запрос выдает 1-5 записей, но данные в этих записях аггрегируют значения из 12 млн.

miksoft
Каково распределение выбранных данных по таблицам (ближе к началу/концу/равномерно и т.п.)?

Равномерно, но скорее всего один запрос будет обрабатывать только непрерывнолежащие записи.

miksoft
Какая СУБД? возможно, может смена СУБД или даже переход на плоские файлы.

MS SQL 2005, мы сначало использовали 2000-й, но Юкон оказался на 30% быстрее в этой задаче.

miksoft
Каково железо и быстродействие сейчас и насколько высокого прироста быстродействия нужно достичь?

Сейчас используется вот это http://www.nexsan.com/products/products/ataboy2/ataboy2.html
Сейчас на запрос уходит по 19 минут. Надо в несколько раз быстрее.
miksoft
Под скоростью выполнения понимается количество запросов в секунду или время выполения запроса?

Время выполнения запроса.

miksoft
Вполне возможно, что достаточно будет увеличить оперативную память (желательно, чтобы индексы полностью умещались в памяти)

Память сейчас 4 GB.
...
Рейтинг: 0 / 0
05.10.2005, 20:49
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33307571
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
guest_20040621
Гость
> С точки зрения запросов оптимизировать, похоже нечего.

Т. е. структура данных уже денормализована?

> Опции, которые я вижу RAID 0/5, internal/external SCSI array?

Есть FC, почему обязательно SCSI? Зависит от бюджета и требований.

500 Гб и внутренним массивом можно набрать, это немного. Насколько критична остановка? Быстрее всего (но абсолютно ненадежно) райд 0 и шпинделей побольше. Если нужна надежность и скорость - райд 10 (опять же, шпинделей чем больше, тем лучше).

> Стоит ли разбить базу на несколько: каждая на отдельном диске/контроллере?

Вряд ли. Эффект будет только при достаточно большом количестве дисков.

> Что здесь будет узким местом: контроллер, диск?

При нормальном контроллере - дисковая подсистема, конечно.

Вообще - обратитесь к нормальному системному интегратору, он все и распишет. С точностью до цента. ;)
...
Рейтинг: 0 / 0
05.10.2005, 21:11
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33308312
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
aldep miksoftя правильно понял, что все четыре таблицы связаны один к одному между собой?

Да.Не пробовали все четыре таблицы объединить в одну?
miksoft
Каково количество реально выбираемых записей за один запрос?

Зависит от запроса. Выборка может быть из 10 записей, а может быть из всех 12 млн. Т.е. запрос выдает 1-5 записей, но данные в этих записях аггрегируют значения из 12 млн.агрегируют всегда или в некоторых запросах? по всем полям? если всегда и по всем, то получается огромный объем дискового чтения на один запрос...

Нет возможности хранить какие-то предрассчитанные значения? если не для всех запросов, то для большинства?
miksoft
Какая СУБД? возможно, может смена СУБД или даже переход на плоские файлы.

MS SQL 2005, мы сначало использовали 2000-й, но Юкон оказался на 30% быстрее в этой задаче.увы, в MSSQL я ни бум-бум.. неплохо бы поинтересоваться у специалистов по MSSQL-ю.
Если выполняемые запросы не очень сложные, то есть вариант попробовать на более простых базах. Не удивлюсь, если MySQL окажется быстрее.
miksoft
Каково железо и быстродействие сейчас и насколько высокого прироста быстродействия нужно достичь?

Сейчас используется вот это http://www.nexsan.com/products/products/ataboy2/ataboy2.html
Сейчас на запрос уходит по 19 минут. Надо в несколько раз быстрее.
Железо уже вполне серьезное... Есть смысл посмотреть на конфигурацию этого массива... Какой массив сейчас?

Какой ценой надо добиться ускорения? Точнее, каков бюджет?
...
Рейтинг: 0 / 0
06.10.2005, 11:24
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33308373
Dik76
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dik76
Участник
miksoft

m> Не удивлюсь, если MySQL окажется быстрее.

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

--
Dik76

Posted via ActualForum NNTP Server 1.3
...
Рейтинг: 0 / 0
06.10.2005, 11:35
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33308448
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
RAM-а вам нужно побольше. И вполне может быть, что MySql вас вполне устроит.
...
Рейтинг: 0 / 0
06.10.2005, 11:51
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33308764
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Тоже неплохая дурилка, судя по описанию, памяти поболее.
...
Рейтинг: 0 / 0
06.10.2005, 13:01
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33308766
Programmer_Ortodox
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Programmer_Ortodox
Участник
Programmer_OrtodoxТоже неплохая дурилка, судя по описанию, памяти поболее.
...
Рейтинг: 0 / 0
06.10.2005, 13:02
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33309624
Vovik@PB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vovik@PB
Гость
Разбейте БД на несколько файлов (в Primary filegroup) и разместите их на разных дисках массива.
Вынесите индексы в отдельную файловую группу на отдельный диск.
...
Рейтинг: 0 / 0
06.10.2005, 16:38
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33309993
aldep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aldep
Гость
miksoftНе пробовали все четыре таблицы объединить в одну?[quot ]
В MSSQL максимальное число столбцов 1000. В Оракле еще меньше
Кроме того, когда они храняться в разных таблицах можно их положить на разные сервера и делать запросы к ним.

[quot miksoft]
Нет возможности хранить какие-то предрассчитанные значения? если не для всех запросов, то для большинства?
[quot ]

Да так и собираемся сделать.

[quot miksoft]
увы, в MSSQL я ни бум-бум.. неплохо бы поинтересоваться у специалистов по MSSQL-ю.
Если выполняемые запросы не очень сложные, то есть вариант попробовать на более простых базах. Не удивлюсь, если MySQL окажется быстрее.[quot ]
Попробуем, спасибо!

[quot miksoft]
Железо уже вполне серьезное... Есть смысл посмотреть на конфигурацию этого массива... Какой массив сейчас?

Какой ценой надо добиться ускорения? Точнее, каков бюджет?

На покупку 72-процессорного Сана точно не хватит, а вот на FC disk array вполне. Даже на парочку.
...
Рейтинг: 0 / 0
06.10.2005, 18:16
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33310008
aldep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aldep
Гость
miksoft
Не пробовали все четыре таблицы объединить в одну?


В MSSQL максимальное число столбцов 1000. В Оракле еще меньше
Кроме того, когда они храняться в разных таблицах можно их положить на разные сервера и делать запросы к ним.

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


Да так и собираемся сделать.

miksoft
увы, в MSSQL я ни бум-бум.. неплохо бы поинтересоваться у специалистов по MSSQL-ю.
Если выполняемые запросы не очень сложные, то есть вариант попробовать на более простых базах. Не удивлюсь, если MySQL окажется быстрее.

Попробуем, спасибо!

miksoft
Железо уже вполне серьезное... Есть смысл посмотреть на конфигурацию этого массива... Какой массив сейчас?

Какой ценой надо добиться ускорения? Точнее, каков бюджет?


На покупку 72-процессорного Сана точно не хватит, а вот на FC disk array вполне. Даже на парочку.
...
Рейтинг: 0 / 0
06.10.2005, 18:20
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33310013
aldep
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aldep
Гость
Vovik@PBРазбейте БД на несколько файлов (в Primary filegroup) и разместите их на разных дисках массива.
Вынесите индексы в отдельную файловую группу на отдельный диск.

Попробуем! Спасиб.
...
Рейтинг: 0 / 0
06.10.2005, 18:21
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33310106
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
aldep miksoft
Не пробовали все четыре таблицы объединить в одну?


В MSSQL максимальное число столбцов 1000. В Оракле еще меньше
в запросе нужны строго все поля? неужели агрегирование идет по всем полям?
никакие поля нельзя сократить, объединить и т.п.?

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

Кстати, возможно улучшит ситуацию перетасовать поля между таблицами.
...
Рейтинг: 0 / 0
06.10.2005, 18:58
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33310772
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Есть у меня подозрение что здесь нужен ОЛАП-сервер.

Насколько часто запросы повторяются? Каковы основные типы аггрегации?
...
Рейтинг: 0 / 0
07.10.2005, 10:06
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33311566
_hike_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_hike_
Участник
а по четырем таблицам вьюху нарисовать и по ней индекс построить не пробовали ?
...
Рейтинг: 0 / 0
07.10.2005, 13:51
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33311986
Фотография Old Nick
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Old Nick
Участник
Здесь однозначно нужен ОЛАП-сервер, поскольку налицо все предпосылки:

1. Данные не добавляются, значит только анализируются.
2. Даже когда выводят только 5 записей, то анализируют все равно все записи.

Видимо для анализа постоянно используют одни и те же агрегации. Задумайтесь, стоит ли для этого каждый раз выполнять агрегационные запросы?
...
Рейтинг: 0 / 0
07.10.2005, 15:35
| Ответить | Цитировать | Написать  
Как физически лучше разместить БД.
    #33312837
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Советую обратить внимание на последние выпуски рассылки SQL Server...
Там достаточно подробно расписывались выровненные индексы (Ваш случай), разбиение на файлы и партицирование в Юконе.

Если это еще не сделали, то возможно что-то окажется полезным.
...
Рейтинг: 0 / 0
08.10.2005, 03:01
| Ответить | Цитировать | Написать  
18 сообщений из 18, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Как физически лучше разместить БД.
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]