Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Ggg_old
Guest
Дискуссия становится интересной. Задам вопросик параллельно с темой, особенно хотелось бы услышать мнение onstat. Есть БД, размер страницы 2к. Есть RAID 10 (по пять винтов на канале). ОС - Windows 2000AS. Какой размер страйпа будет предпочтительней - 4k, 16k, 32k, 64k? Как в этом случае нужно учитывать или выставлять размер кластера на NTFS. Режим работы БД - смешанный, но тюнить надо под OLTP. У меня есть возможность поэкспериментировать. Есть мысль - размер страйпа 4к (был 32), размер кластера по умолчанию оставить 4к.
10 авг 04, 11:04    [870646]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
EugeneS
Oracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01

4. Scalability in Real Application Clusters
Спасибо за инфо. А можно ссылку на документ или в почту сюда киньте. Хочется поподробнее почитать. Заранее спасибо :-).
10 авг 04, 11:07    [870658]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
автор

Во вторых а как быть с распаралеливанием ввода вывода, о котором мы говорили несколько постов назад. Мне неизвесны контролеры которые
могут выполнять паралельно операции ввода вывода в пределах одного массива. Будь то RAID5 RAID10 или RAID1.
Тоесть то что база данных пытается паралелить по вводу выводу
Ваш RAID сводит на нет(потому что очередь на операции ВВ в масиве одна).

Я думаю этих аргументов пока достаточно.

Я не имел ввиду индекснй поиск по блобам.

Одноpначно для OLTP многопользовательской базы 10 x RAID1 всегда быстрее
одного 1 x RAID10.

с уважением, onstat-


1. Про контроллеры и распараллеливание.
Для того чтобы нормально восспользоваться функцией распараллеливания надо выполнить несколько условий
- число параллельных процессов равно числу процессоров.
- число параллельных процессов равно числу дисковых volume и в свою очередь равно числу дисковых контроллеров.
- на каждом дисковом контроллере в свою очерель строится RAID10 ( в случае если используетя интесивная запись или RAID5 ). Это на сегодня самые распространненые уровни RAID. В случае если у вас есть RAID3 то можно его использовать для чтения , он лучше подходит для последовательного чтения , а RAID5 лучше для случайного чтения.

2.
автор
Одноpначно для OLTP многопользовательской базы 10 x RAID1 всегда быстрее
одного 1 x RAID10.

Откуда такое утверждение?
Вы сами то рельно пробовали такую конфигурациию?
Наверно нет.
Дело втом что заниматься балансировкой файлов по дисковым разделам очень не благодарное дело.
А кроме того RAID10 имеет одно очень полезное свойство.
При выходе диска из строя производительность практически не падает , чего я не скажу скжаем о RAID 5.

Например RAID10 на 12x72GB на железке типа HP DL380 c контроллером SA6404 на двух каналах дает примерно 150МБ на запись и примерно 100-120
на чтение.

Если очень интерестно почему.
http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf
10 авг 04, 11:08    [870661]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
EugeneS

Кроме того давайте определимсяся с цифрами , что такое VLDB

Тут скорее нужно по другому пути пойти: для какой платформы какая нагрузка будет считаться предельной.
Хотябы так:
(Количество процессоров, количество (и тип) дисковой подсистемы, RAM)=>(Размер БД в гигах, Кол-во сессий, кол-во OLTP транзакций, кол-во DSS запросов, кол-во записей в самой большой таблице)
Может кто еще критерии предложит?...
10 авг 04, 11:08    [870665]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Сергей Тихонов
EugeneS
Oracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01

4. Scalability in Real Application Clusters
Спасибо за инфо. А можно ссылку на документ или в почту сюда киньте. Хочется поподробнее почитать. Заранее спасибо :-).


автор
http://download-west.oracle.com/docs/cd/B10501_01/rac.920/a96597/psscadtl.htm#1798
10 авг 04, 11:13    [870671]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Ggg_old

Дискуссия становится интересной. Задам вопросик параллельно с темой, особенно хотелось бы услышать мнение onstat. Есть БД, размер страницы 2к. Есть RAID 10 (по пять винтов на канале). ОС - Windows 2000AS. Какой размер страйпа будет предпочтительней - 4k, 16k, 32k, 64k? Как в этом случае нужно учитывать или выставлять размер кластера на NTFS. Режим работы БД - смешанный, но тюнить надо под OLTP. У меня есть возможность поэкспериментировать. Есть мысль - размер страйпа 4к (был 32), размер кластера по умолчанию оставить 4к.


Самый лучший вариант максимальный размер страйпа.
Далеет размер кластера должен быть равен размеру страницы БД.
Размер страйпа должен быть кратен размеру кластера и размеру блокак БД.
Если есть возможность размер страйпа бложен быть равен размеру IO ОС.
Я когда-то слышал что для Win это 1МБ.
10 авг 04, 11:18    [870688]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Ggg_old
Guest
2 Eugene_S
Мне не очень понятно почему, размер страйпа должен быть как можно больше?
Если БД запрашивает страницу 2к, ОС читает кластер в 4к (типа примитивного read ahead), контроллер читает страйп блок - 32к, а винты читают в свой кэш даже не знаю сколько (все зависит от винтов). Теретически - лишние файловые операции. Практически - эти операции хорошо влияют на чтение последовательных блоков, но здесь все очень зависит от БД и характера ее запросов. А если данные итаются с разных не рядом стоящих блоков, то надо вроде делать наоборот - читать поменьше. Но это конечно все пока теоретические измышления...
10 авг 04, 11:38    [870767]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Ggg_old
2 Eugene_S
Мне не очень понятно почему, размер страйпа должен быть как можно больше?
Если БД запрашивает страницу 2к, ОС читает кластер в 4к (типа примитивного read ahead), контроллер читает страйп блок - 32к, а винты читают в свой кэш даже не знаю сколько (все зависит от винтов). Теретически - лишние файловые операции. Практически - эти операции хорошо влияют на чтение последовательных блоков, но здесь все очень зависит от БД и характера ее запросов. А если данные итаются с разных не рядом стоящих блоков, то надо вроде делать наоборот - читать поменьше. Но это конечно все пока теоретические измышления...


Насчет страйпа.
Я давал ссылку там выше. В ней все сказано.
Основная идея в том что позиционирование головки диска по времени больше чем время чтения дорожки, а учитывая большой размер кэша вероятность того что эта дорожка будет еще в кэше выше при большом размере кэша..


Вы не правы.
Серверный процесс запрашивает операцию чтения-записи у ОС.
Ядро ОС никогда не выполняет чтение одного блока, а всегда читает с учетом опережающего чтения за исключение случая прямого чтения из дискогово раздела мимо кэша ОС но это отдельная песня.
Значит на каждый запрос на чтение блока размером 2к или 32к со стороны СУБД ядро ОС будет выполнять чтение 1МБ.
10 авг 04, 12:27    [870981]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
nkulikov
Guest
Размер страйпа не должен быть равен странице БД. Он должен быть кратен extent'y DB, или наорот... Я приболел. Выйду на работу кину пару моментов по этому поводу.
10 авг 04, 13:14    [871134]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
По поводу размера страйпа
есть такая работа "Maximizing Performance in a Striped Disk Array" , Peter M. Chen ,David A. Patterson.
Там рассматривается вопрос определения оптимального размера страйпа для систем с разным количество одновременных обращений и разными объемам среднего ситаемого блока данных.
Там приведена зависимость примерно следующего вида: при увеличении размера страйпа при малом количестве пропускная способность падает и наоборот.
Более того, там указан оптимальный размер страйпа "на все случаи жизни" - 128к.
правда, работа достаточно старая, но можно проверить цифирки...
10 авг 04, 14:03    [871322]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Теперь про TERADATA.
Коллеги,
давайте будем реалистами.
Кто-нибудь работал с TERADATA?


Да.

На просторах бывшего CНГ есть представительство этой компании?


Да, компания называется NCR. Офис в Москве существует уже более 10 лет.
Teradata - это подразделение компании NCR.

Кто-нибудь с ней работал?


Да.

А теперь ключевой вопрос,
Вы верите в "чудо", что малоиспользуемый продукт вдруг окажется тем что именно вам надо?


По используемости для хранилищ данных больших объёмов - это №1. Это факт. Можно и не верить, если хотите проверить, могу предложить свою помощь.

Сомневаюсь однако.


Задавайте вопросы. Попробуем развеять Ваши сомнения.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 17:39    [872202]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Оп ля!
Ну если так и все это будет крутиться на одной железке, то того возникает вопрос "Управления ресурсами СУБД".
Для чего имеется Resource Manager в СУБД Oracle.

Пока из-того, что я знаю о конкурентах такой функциональности нет.


В СУБД Teradata то называется Teradata Priority Scheduler (почитать про него можно в документе Introduction to Teradata's Priority Scheduler). Существовал с самого начала СУБД Teradata (то есть уже около 20 лет).



С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 17:48    [872239]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
А что будет, если один и тот же блок понадобиться и в том и в другом инстансе? Как там насчет Interconnect?


Если данные, хранящиеся на одном узле нужны на другом (чаще на нескольких других узлах), то происходит перераспределение данных между узлами. Перераспределение данных между узлами чаще всего требуется при проведении операций соединения таблиц. Для этого, действительно, используется Interconnect.

В СУБД Teradata он называется BYNET. Его пропускная способность составляет до 752 мегабайт в секунду на один узел. BYNET является не шиной, а коммутатором, способным передавать данные по протоколу узел-узел или узел-все остальные узлы (broadcast). Соответственно, добавление каждого нового узла в систему приводит к приросту общей пропускной способности системы на 752 мегабайт в секундую Умножьте на количество узлов, которое теоретически поддерживает Teradata (в данный момент - это 512 узлов, таких больших систем в мире нет, самая большая имеет около 300 узлов) - получите теоретическую пропускную способность BYNET. Получается довольно большая цифирь. Соответственно, BYNET не является узким местом в системе.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 18:15    [872338]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Сергей Тихонов
... Дело все в том (помимо прочего), что межсерверные соединения гораздо медленнее, чем внутрисерверные шины. С учетом накладных расходов на обмен данными между узлами, получаем результат :-\\. Об этом, кстати, писали недавно в одном из номеров журнала "Byte Россия"...


А можно ссылочку?


Сергей Тихонов
В том же BOL для MSSQL говорится, что роутинг запросов должны организовывать разработчики. Потому как даже если у нас распределенное секционированное представление и СУБД будет обрабатывать только нужные таблицы на нужном сервере, "прокачка" данных через узел, на который пришел запрос, негативно влияет на производительность...



Проблема решается унификацией производительности узлов и высокоскоростным коммутатором. Система сама должна распределять нагрузку. Разработчики должны пить пиво пока система сама всё делает.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 18:28    [872381]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Нет, в статье говорится, что единственный плюс scale out - неограниченная возможность наращивать ресурсы системы. И это все при куче всяких но: администрирование, управление, обслуживание и т.д.


Из статьи я понял, что решение shared nothing от Microsoft ещё пока очень слабое. Отсутствие автоматического распределения нагрузки - первый сигнал того, что надо засомневаться в его работоспособности. Действительно, кроме scale out они ничего не предлагают.

Кстати, в статье не увидел ничего про speed up - возможность повышения скорости выполнения запросов путём добавления новых узлов. Есть небольшая глава про Response time, из которой неясно, возможно ли это в случае MS SQL.


В результате знакомства со "слегка недоделанным" решением от Microsoft у читателя создаётся неверное представление о возможностях архитектуры shared nothing в принципе.
Рекмендую поближе познакомиться с тем, как это выглядит в СУБД Teradata. Это снимет Ваши сомнения в возможностях shared nothing (или MPP).



С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 18:46    [872429]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
А можно ссылочку?
Запросто: Вертикальное и горизонтальное масштабирование систем

Если честно, про BYNET ничего не понял :-\\... Каким образом добавление узла увеличивает пропускную способность? Где почитать можно?
10 авг 04, 18:54    [872441]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
gardenman
Так по-моему в том и состоит суть архитектуры MPP чтобы сократить такую прокачку до минимума. В идеале на каждом узле д.б. обработаны только свои данные. Причем резутьтат - это не только SELECT, но и INSERT/UPDATE/DELETE.
Это называется межраздельным пареллелизмом.


В принципе, так, но эту прокачку не так легко свести до минимума. Операции JOIN всё "портят". Если данные, которые надо соединять, находятся на разных узлах, то их перераспределение неизбежно.
Естественно, это решается. Например, в СУБД Teradata для этого существуют hash-индексы, которые, фактически создают альтернативное перераспределение таблиц с тем, чтобы данные (точнее, индексы) соединяемых таблиц находились на одном узле. join-индексы являются аналогом materialized view и служат для материализации соединений. Ну, и, естественно, правильное аппаратное решение - коммутатор BYNET, способный быстро передавать данные между узлами, если это, всё-таки, необходимо.

С INSEERT проще - там не надо перераспределять данные между узлами, только вставка. UPDATE тоже может привести к переносу записи на другой узел. Единственный способ борьбы - скоростной коммутатор.
DELETE не требует перераспределения данных.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 18:55    [872443]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
killed
Возможно, я не совсем правильно выразился. Попробую обьяснить свою мысль. Если в архитектуре shared nothing каждый нод хранит лишь свои собственные данные, то синхронизации данных между нодами не нужна. Но в любом случае неизбежны проблемы с балансировкой нагрузки.


Эти проблемы решаются с помощью равномерного распределения данных между узлами. Наиболее продвинутый алгоритм - это хэширование.
Он используется в DB2 и в Teradata. Соответственно, критическое решение, которое сильно влияет на производительность - это выбор столбца (или нескольких столбцов) таблицы, по которым будет осуществляться хэширование для "размазывания" таблицы по узлам.
Поскольку алгоритм хэширования работает автоматически и (как правило) не зависит от администраторов, можно говорить об автоматическом рапределении нагрузки. Другие алгоритмы партишионинга срабатывают не так хорошо, как хэширование. Некоторые из них быстрее для определённых классов запросов, но в целом показывают себя не так хорошо.


killed
Администратора не будем рассматривать. Для серьезных продакшн систем, пытаться балансировать данные между нодами вручную - самоубийство.


Согласен на 100%.

killed
Остается как я понимаю один путь. Увеличивать кластер в тех нодах, которые выпадают по нагрузке. Фактически - это "деление пополам".


Как я уже сказал выше - лучший способ - равномерное распределение данных.
ИМХО.


С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 19:04    [872452]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
EugeneS


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


Не обязательно, бывают спящие процессы.

EugeneS


- число параллельных процессов равно числу дисковых volume и в свою очередь равно числу дисковых контроллеров.


Тоже не обязательно, один контроллер может держать несколько томов.
IHMO Оптимально 3-5 шт.

EugeneS


- на каждом дисковом контроллере в свою очерель строится RAID10 ( в случае если используетя интесивная запись или RAID5 ). Это на сегодня самые распространненые уровни RAID. В случае если у вас есть RAID3 то можно его использовать для чтения , он лучше подходит для последовательного чтения , а RAID5 лучше для случайного чтения.



Я RAID3 & RAID5 не счтаю достойным к рассмотрению в случае работы с OLTP системами. На них можно хранить фильмы или делать бэкапы.


EugeneS


Откуда такое утверждение?
Вы сами то рельно пробовали такую конфигурациию?
Наверно нет.



Да. пробовал.

EugeneS

Дело втом что заниматься балансировкой файлов по дисковым разделам очень
не благодарное дело.

А кроме того RAID10 имеет одно очень полезное свойство.
При выходе диска из строя производительность практически не падает , чего я не скажу скжаем о RAID 5.


Нужно заниваться не балансировкой файлов, а балансировкой нагрузки на ввод вывод между томами. И возможность этого тюнинга предвидеть заранее.
Я неисползую RAID5 для баз данных и не планирую.

EugeneS

Например RAID10 на 12x72GB на железке типа HP DL380 c контроллером SA6404 на двух каналах дает примерно 150МБ на запись и примерно 100-120
на чтение.


Я не верю в то что это работала база данных.
Или в это время производились полные сканирования таблиц.


Результаты того что пробовал я:

IBM FASTT 600 (12х HDD FC 146 Gb)
Обьем базы данных 500 Gb, самая большая таблица ~230 млн записей.
в 8 таблицах больше 100 млн записей.

Объем кеша контроллеров(2шт) 512Mb.
База данных Informix DS 9.4 OS Linux RH 7.2 ядро 2.6.5
Сервер (Какой был под руками) 2хIntel PIII 1GHz 1 Gb Ram

Пробовали размер страйпа 128К.
На построении индексов коэфициент использования кеша контролера 100%
Считай полное сканирование таблиц.
Пиковая скорость 80М/с
Работа OLTP приложения(100 % индкесный поиск), 8 пользовательских сесий.
Кеш контроллера используется на 3-5 %.
Пиковая скорость 10М/с
При уменьшении страйпа до 8К использование кеша контролера повысилось до 30%.
Пиковая скорость 30 M/c
Общая производительность поднялась ~30-40%.
система была не совсем оптимальна, серверу явно не хватало ОЗУ и
быстродействия процессоров. Но какой был на таком и тестили целью было проверить fastt.


EugeneS


Если очень интерестно почему.
http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf



Там описано то о чем я говорю на этом форме.
То есть ко всему нужно подходить взвешенно. Нет одного рецепта на все случаи жизни.
ihmo Что бы выжать из конфигурации все нужно учитывать каждуюю деталь.
Так как это делают в Формуле 1.

EugeneS


Самый лучший вариант максимальный размер страйпа.
Далеет размер кластера должен быть равен размеру страницы БД.
Размер страйпа должен быть кратен размеру кластера и размеру блокак БД.
Если есть возможность размер страйпа бложен быть равен размеру IO ОС.
Я когда-то слышал что для Win это 1МБ.



Почему вы не правы по поводу размера страйпа я повторяться не буду посмотрите мое сообщение в этой ветке.
https://www.sql.ru/forum/actualthread.aspx?tid=111586

А что такое размер IO OC? или я отстал отжизни :).

Если это то о чем я думаю, то дальше наверное будем говорить о DMA.

С уважением, onstat-


ps Прошу прощения за задержку, запарка на работе.
10 авг 04, 19:38    [872500]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
killed
Этот hash ключ учитывает hot spots на этой партиц. таблице? Если нет, то получаем неравномерную нагрузку. Еще момент, если необходимо добавить дополнительный узел в кластер, то для сохранения равномерного распределения данных по *всем* узлам кластера нужно заново "размазать" эту таблицу?



На то он и hash-алгоритм, чтобы уметь раскидать близкие значения аргументов на далеко удалённые значения хэш-функции. Соответственно, hash-функция сглаживает эффект hot spots.

Если необходимо добавить новый узел, то нужно взять маленькие кусочки от каждого куска таблицы с каждого присутствующего узла и переместить эти кусочки на новый узел.
Скажем, если у нас было 10 узлов, на каждом из которых хранилось по 110 записей, то при добавлении одиннадцатого узла мы берём по 10 записей с каждого узла, складываем, и кладём на новый узел. Получаем 11 узлов, на каждом из которых хранится по 100 записей.
По карйней мере, так в Терадате. Как в DB2, наверное, расскажет Николай.



С уважением,
Константин Лисянский
http://lissianski.narod.ru
10 авг 04, 19:45    [872508]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
onstat-
EugeneS


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


Не обязательно, бывают спящие процессы.

EugeneS


- число параллельных процессов равно числу дисковых volume и в свою очередь равно числу дисковых контроллеров.


Тоже не обязательно, один контроллер может держать несколько томов.
IHMO Оптимально 3-5 шт.

EugeneS


- на каждом дисковом контроллере в свою очерель строится RAID10 ( в случае если используетя интесивная запись или RAID5 ). Это на сегодня самые распространненые уровни RAID. В случае если у вас есть RAID3 то можно его использовать для чтения , он лучше подходит для последовательного чтения , а RAID5 лучше для случайного чтения.



Я RAID3 & RAID5 не счтаю достойным к рассмотрению в случае работы с OLTP системами. На них можно хранить фильмы или делать бэкапы.


EugeneS


Откуда такое утверждение?
Вы сами то рельно пробовали такую конфигурациию?
Наверно нет.



Да. пробовал.

EugeneS

Дело втом что заниматься балансировкой файлов по дисковым разделам очень
не благодарное дело.

А кроме того RAID10 имеет одно очень полезное свойство.
При выходе диска из строя производительность практически не падает , чего я не скажу скжаем о RAID 5.


Нужно заниваться не балансировкой файлов, а балансировкой нагрузки на ввод вывод между томами. И возможность этого тюнинга предвидеть заранее.
Я неисползую RAID5 для баз данных и не планирую.

EugeneS

Например RAID10 на 12x72GB на железке типа HP DL380 c контроллером SA6404 на двух каналах дает примерно 150МБ на запись и примерно 100-120
на чтение.


Я не верю в то что это работала база данных.
Или в это время производились полные сканирования таблиц.


Результаты того что пробовал я:

IBM FASTT 600 (12х HDD FC 146 Gb)
Обьем базы данных 500 Gb, самая большая таблица ~230 млн записей.
в 8 таблицах больше 100 млн записей.

Объем кеша контроллеров(2шт) 512Mb.
База данных Informix DS 9.4 OS Linux RH 7.2 ядро 2.6.5
Сервер (Какой был под руками) 2хIntel PIII 1GHz 1 Gb Ram

Пробовали размер страйпа 128К.
На построении индексов коэфициент использования кеша контролера 100%
Считай полное сканирование таблиц.
Пиковая скорость 80М/с
Работа OLTP приложения(100 % индкесный поиск), 8 пользовательских сесий.
Кеш контроллера используется на 3-5 %.
Пиковая скорость 10М/с
При уменьшении страйпа до 8К использование кеша контролера повысилось до 30%.
Пиковая скорость 30 M/c
Общая производительность поднялась ~30-40%.
система была не совсем оптимальна, серверу явно не хватало ОЗУ и
быстродействия процессоров. Но какой был на таком и тестили целью было проверить fastt.


EugeneS


Если очень интерестно почему.
http://otn.oracle.com/deploy/performance/pdf/opt_storage_conf.pdf



Там описано то о чем я говорю на этом форме.
То есть ко всему нужно подходить взвешенно. Нет одного рецепта на все случаи жизни.
ihmo Что бы выжать из конфигурации все нужно учитывать каждуюю деталь.
Так как это делают в Формуле 1.

EugeneS


Самый лучший вариант максимальный размер страйпа.
Далеет размер кластера должен быть равен размеру страницы БД.
Размер страйпа должен быть кратен размеру кластера и размеру блокак БД.
Если есть возможность размер страйпа бложен быть равен размеру IO ОС.
Я когда-то слышал что для Win это 1МБ.



Почему вы не правы по поводу размера страйпа я повторяться не буду посмотрите мое сообщение в этой ветке.
https://www.sql.ru/forum/actualthread.aspx?tid=111586

А что такое размер IO OC? или я отстал отжизни :).

Если это то о чем я думаю, то дальше наверное будем говорить о DMA.

С уважением, onstat-
ps Прошу прощения за задержку, запарка на работе.



1. Я имеею ввиду Parallel Query Option у Oracle и естественно суда не включаются другие сессии, а только сессия которая будет выполнять запрос.


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

3. Балансировака нагрузки ввода-вывода как раз и сводится к раскладыванию файлов по дисковым томам в зависимости от ввода-вывода.
Это не так просто на растущей системе.
И очень часто требуется остановка системы.

4. Я говорил о линейном чтении или записи,естественно при случайном чтении и записи цифры ниже порядка 60-70МБ/с

автор
А что такое размер IO OC? или я отстал отжизни :).

Это кол-во блоков которые ядро ОС считывает за одну операцию ввода-вывода с файловой системы.
10 авг 04, 20:06    [872539]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
EugeneS


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


Разумно ограничил бы чило дисков до 5 на канал контролера
(Если речь идет о медном SCSI). И неважно сколко там томов.
Я чаще всеро использую 5хRAID1 на двухканальном контролере.
Всего десять дисков по 5 на канал.

EugeneS

3. Балансировака нагрузки ввода-вывода как раз и сводится к раскладыванию файлов по дисковым томам в зависимости от ввода-вывода.
Это не так просто на растущей системе.
И очень часто требуется остановка системы.


Добавление или удаление партиции на таблице как правило не требует
остановки системы. Задав условие партиционирования на другой (свободный по ВВ) том разгружаем систему практически моментально,
но взвешивать все за и против такого хода нужно очень хорошо, откатить назад будет тяжело.
Именно поэтому я говорил о балансировании нагрузки на тома,
а не на файлы БД.
А удаление старых данных просто прелесть, Я за 10 -20 минут удаляю
20 млн записей из 100 млн таблицы путем отсоединения партиций.
Кто быстрее и как?

EugeneS

4. Я говорил о линейном чтении или записи,естественно при случайном чтении и записи цифры ниже порядка 60-70МБ/с


Откуда статистика, это объем чтения который реально читается с диска,
или тот что требуется базой и реально попадает в кеш oracle?
Что говорит spotlite о проценте использования кеша oraclе -ом?
(Я надеюсь вы его используете?)
Какой у Вас размер страйпа? и размер блока базы?

Я приводил скорость попадания необходимых данных в кеш базы.

автор
А что такое размер IO OC? или я отстал отжизни :).

Это кол-во блоков которые ядро ОС считывает за одну операцию ввода-вывода с файловой системы.[/quot]

Значит ли это что написав программу которая читает с диска блоками по 2К
(например) винда читает за одну дисковую операцию 1 Mb с диска вместо 2К.
Может это и так, но уверенны ли вы, что базы данных используют это
значение по умолчанию?
Я намекаю на использование кеша фаловой системы для базы данных,
Я надеюсь вы это имели ввиду?

Хотелось бы услышать мнение народа по этому поводу(кеша файловой системы).

с уважением, onstat-
10 авг 04, 21:27    [872656]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Константин Лисянский
Да, компания называется NCR. Офис в Москве существует уже более 10 лет.
Teradata - это подразделение компании NCR.
А можно несколько вопросов:
  • Есть ли представительство Teradata в Украине?
  • Хотелось бы услышать или почитать про примеры успешных внедрений этой СУБД в Украине.

    ЗЫ
    Данная СУБД действительно не очень распространена и известна только в достаточно узком кругу специалистов. Хотелось бы услышать: если она такая крутая и существует уже порядка 20 лет, то почему о ней так мало известно?
    Кстати, а какой кусок пирога мирового рынка СУБД занимает Teradata?
  • 10 авг 04, 21:41    [872676]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

    Откуда:
    Сообщений: 6941
    Ggg_old


    Дискуссия становится интересной. Задам вопросик параллельно с темой, особенно хотелось бы услышать мнение onstat. Есть БД, размер страницы 2к. Есть RAID 10 (по пять винтов на канале). ОС - Windows 2000AS. Какой размер страйпа будет предпочтительней - 4k, 16k, 32k, 64k? Как в этом случае нужно учитывать или выставлять размер кластера на NTFS. Режим работы БД - смешанный, но тюнить надо под OLTP. У меня есть возможность поэкспериментировать. Есть мысль - размер страйпа 4к (был 32), размер кластера по умолчанию оставить 4к.



    Я домаю, что моя полемика сегодня много прояснила,
    Если у вас есть конкретные вопросы давайте обсудим.

    В вашем случае за раз будет читаться 4*5 = 20К за дисковую операцию.
    Если это соответствует вашим данным то наздоровье.
    Если же вы храниете фотографи в блобах и ищите их по индексу,
    может не нужно ничего менять.
    По поводу размера кластера, давайте обсудим, я в на uinix & raw devices сижу.

    С уважением, onstat-
    10 авг 04, 22:04    [872704]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    killed
    Member

    Откуда: Moscow
    Сообщений: 3526
    onstat-
    killed

    Для хранилища я бы пытался оптимизировать мультиблочные операции чтения (сканирование таблиц и др.) в первую очередь. Кстати страйпинг полезен и для чистого OLTP где 100% - индексный доступ


    Может быть, но зависит это от размера блока вашей базы,
    количества дисков в массиве и размера страйпа.
    в лушчем случае (при минимальном размере страйпа) вы получите туже производительность что и на просто диске или RAID1.

    Во вторых а как быть с распаралеливанием ввода вывода, о котором мы говорили несколько постов назад. Мне неизвесны контролеры которые
    могут выполнять паралельно операции ввода вывода в пределах одного массива. Будь то RAID5 RAID10 или RAID1.
    Тоесть то что база данных пытается паралелить по вводу выводу
    Ваш RAID сводит на нет(потому что очередь на операции ВВ в масиве одна).

    Я думаю этих аргументов пока достаточно.

    с уважением, onstat-


    Вы уж простите, но это тривиальные вещи, которые подразумеваются. Не забывайте, речь шла о терабайтной базе. Какие тут проблемы с количеством дисков? Размер блока - настраивается, размер мультиблочного чтения - настраивается, от него двигаемся к stripe element size, от него - к stripe size.

    По распараллеливание - очереди на ВВ будут к *каждому_диску*, а не контроллеру.
    10 авг 04, 22:44    [872725]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 13   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить