Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

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


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


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


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

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

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


Тут промелькнула цифра IO OC = 1M , подозреваю, что речь шла о max_io_size. Кэш файловой системы используется при read ahead, если не используется direct read. На солярисе его можно настраивать, насчет виндовз - не знаю.
Про настройку RAID я писал на оракловом форуме здесь.
10 авг 04, 23:21    [872745]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

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

А удаление старых данных просто прелесть, Я за 10 -20 минут удаляю
20 млн записей из 100 млн таблицы путем отсоединения партиций.
Кто быстрее и как?



В оракле - это две-три секунды в независимости от объема данных, если под отсоединением понимается удаление партиции или преобразование ее в отдельную таблицу
10 авг 04, 23:32    [872754]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
Сергей Тихонов
Запросто: Вертикальное и горизонтальное масштабирование систем


Честно говоря, статья не создаёт впечатление профессионально написанной. Системы MPP (горизонтальное масштабирование в версии автора) оказывается, не предназначены для больших баз данных и хранилищ данных. В то время, как Терадата позиционируется исключительно для создания хранилищ данных. А более 35% инсталляций - хранилища размером свыше 1 терабайта. Скорее всего, автор в этом мало что понимает. И разобраться как следует не счёл необходимым.


Если честно, про BYNET ничего не понял :-\\... Каким образом добавление узла увеличивает пропускную способность? Где почитать можно?


Можно почитать статью Born To Be Parallel. В ней рассказываются об архитектурных принципах СУБД Teradata. Про BYNET тоже есть немного.

Здесь про BYNET кратко (цифры немного уже устарели - это про предыдущую версию).

Если и это не поможет - пишите. Попробую объяснить.


А можно несколько вопросов:

Есть ли представительство Teradata в Украине?

Хотелось бы услышать или почитать про примеры успешных внедрений этой СУБД в Украине.


Teradata развивает бизнес в Украине. Поскольку до настоящего времени не было готовности компаний строить крупномасштабные корпоративные хранилища данных, пока состоявшихся внедрений в Украине не существует. Но надо заметить, что компании проявляют интерес к этой технологии.

Если Ваш интерес не праздный, и речь идёт о создании большого хранилища данных, то настоятельно рекомендую рассматривать Терадату.
Опять-таки, если интерес есть, я готов лично рассказать о Терадате. Я буду в Киеве в пятницу. Можем встретиться. Если интересно, киньте мне по мейлу свой телефон, я Вам позвоню, договоримся о встрече.


Данная СУБД действительно не очень распространена и известна только в достаточно узком кругу специалистов. Хотелось бы услышать: если она такая крутая и существует уже порядка 20 лет, то почему о ней так мало известно?
Кстати, а какой кусок пирога мирового рынка СУБД занимает Teradata?


Распространённость Терадаты обусловлена её точным позиционированием - это СУБД позиционируется исключительно как СУБД для (больших) хранилищ данных. Соответственно, количество инсталляций не так велико, как у других СУБД, которые позиционируются для решения задач OLTP. Соответственно, доля рынка СУБД получается не большая. Точной цифры я назвать не готов. Однако в сегменте корпоративных хранилищ данных Терадата лидирует.



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

Откуда: Москва
Сообщений: 902
А удаление старых данных просто прелесть, Я за 10 -20 минут удаляю
20 млн записей из 100 млн таблицы путем отсоединения партиций.
Кто быстрее и как?


То же самое в Терадате. Только не очень понятно, зачем так долго? За 20 минут, как известно, можно добежать до канадской границы :)
За 10-20 минут можно 20 млн записей загрузить в таблицу из текстового файла. А уж партиции подропать - так это секунды.

Делается примерно так:
ALTER TABLE SalesTable
MODIFY PRIMARY INDEX (product_code, sales_date, agent_id)
DROP RANGE BETWEEN DATE ‘2001-06-01AND DATE ‘2001-06-30’
EACH INTERVAL ‘1’ MONTH
WITH DELETE;

Подробности о том, как и почему - здесь.



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

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



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

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

С уважением,
Константин Лисянский
http://lissianski.narod.ru


1)
Да, но рассматривайте хот спотс (кстати это ведь не обязательно данные "лежащие рядом") с точки зрения приложения в целом, а не на уровне отдельной таблицы. Т.е. с одной стороны данные хот спотс лучше равномерно размазать по нодам, а с другой стороны это потянет за собой дополнительные данные других таблиц (соединения, объединения, подзапросы). Т.е. если обобщить, то партицирую получаем выигрыш по CPU, утилизации памяти, но в довесок также получаем минусы увеличенной межнодовой передачи данных?

2) А представьте, нужно вместо 10 записей, взять по 10 миллионов? Я правильно понимаю, что на время процедуры "репартишина" Терадата не гарантирует получение корректных результатов запросов?
11 авг 04, 02:06    [872830]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
killed


1)
Да, но рассматривайте хот спотс (кстати это ведь не обязательно данные "лежащие рядом") с точки зрения приложения в целом, а не на уровне отдельной таблицы. Т.е. с одной стороны данные хот спотс лучше равномерно размазать по нодам, а с другой стороны это потянет за собой дополнительные данные других таблиц (соединения, объединения, подзапросы). Т.е. если обобщить, то партицирую получаем выигрыш по CPU, утилизации памяти, но в довесок также получаем минусы увеличенной межнодовой передачи данных?

2) А представьте, нужно вместо 10 записей, взять по 10 миллионов? Я правильно понимаю, что на время процедуры "репартишина" Терадата не гарантирует получение корректных результатов запросов?



1) Основное приложение Терадаты это обработка сложных DSS запросов (как произвольных так и запланированных) от многих пользователей на сравнительно больших объемах данных. Хэш-партишонинг и равномерное распределение данных по узлам здесь рулит. В Терадата есть механизмы по оптимизации запросов засчет вторичных индексов и join индексов, котрые также в свою очередь равномерно размазаны по узлам. Подвесить межнодовую шину в Терадата (тобишь Bynet) сложно. Как правило в системах с хорошей загрузкой затырк это CPU и диск. Опять же производительность запроса зависит от многих факторов - кол-ва узлов в кластере, оптимизации запроса при помощи индексов, кол-ва одновременных пользователей в системе, приоритета пользователя, свежести статистики и т.п.

Главные преимущества хэш-партишонинга в Терадата - 1) Параллельная эффективность - данные равномерно раскиданы по узлам и по виртуальным процессорам СУБД. Каждый отвечает за свой кусочек диска и данных. 2) Просто администрить. Не важно таблица 100 ГБ или 1 ТБ - ты отводишь диск под базу, определяешь первичный индекс в таблице, а Терадата сама раскидывает данные при загрузке. Голова не болит, не надо перестраивать индексы, делать реорги и заниматься такого роды фигней. Once the data is there - it is there.

2) При добавлении новых узлов в Терада делается реконфиг и данные автоматичести перераспределяются между узлами в новой конфигурации кластера. Система при этом недоступна для пользователей. Добвалять узлы в кластер дело дорогое, вызванное потребностью "подкачать мускулы". Одним словом бывает это нечасто.
11 авг 04, 08:56    [872981]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

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

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

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


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

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

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

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


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

По распараллеливание - очереди на ВВ будут к *каждому_диску*, а не контроллеру.


Для меня они уже давно тривиальные.
1. Посмотрите в операциооной
системе sar если у вас unix или performance monitor если винда
и скажите сколько очередей на один диск(массив). На то они и очередь чтобы в ней стоять. :)

2. Учтите что в кеш контролера попадает минимум srtipe* количество дисков объем данных. Как быстро он забьется не нужным базой мусором? А темболее
на терабайтной базе. И переписывается тоже этот весь объем в случае изменения. Посмотрите мои предидущие посты там исследовалась база в пол терабайта.

3.Обьясните как паралелится очередь на каждый диск если 1 операция
ВВ читает одновременно страйпы со всех дисков, и операция длится
до тех пор пока линейка страйпов не будет обработана на всех дисках.
Паралельно можно читать только то что записано а не то что хочет база.
В чем тут паралелизм?


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

Откуда: Москва
Сообщений: 902
killed
1) Да, но рассматривайте хот спотс (кстати это ведь не обязательно данные "лежащие рядом") с точки зрения приложения в целом, а не на уровне отдельной таблицы. Т.е. с одной стороны данные хот спотс лучше равномерно размазать по нодам, а с другой стороны это потянет за собой дополнительные данные других таблиц (соединения, объединения, подзапросы). Т.е. если обобщить, то партицирую получаем выигрыш по CPU, утилизации памяти, но в довесок также получаем минусы увеличенной межнодовой передачи данных?


Как я уже писал выше, межнодовая передача - естественное явление. Вы правильно заметили, что определённые операции требуют перераспределения данных между узлами.
Для этого в СУБД Терадата существует коммутатор BYNET с довольно высокой пропускной способностью на узел. Кроме того, что он умеет просто передавать данные и сообщения, он ещё и обладает определённым интеллектом, позволяющим более эффективно распараллеливать некоторые операции. Например, возьмём сортировку. Понятное дело, что сначала сортировка выполняется локально на каждом узле. Но ведь, результат должен быть отсортирован глобально, не так ли? Если бы узли были связаны, скажем, с помощью Ethernet, то для окончательной сортировки все данные нужно было бы гнать на один узел. В случае СУБД Teradata окончательную сортировку выполняет сам BYNET. Кроме сортировки, BYNET реализует механизм семафоров, которые использутся для координации работы узлов.

Ещё одно замечание по поводу hot spots - действительно, иногда с точки зрения производительности хорошо хранить данные, находящие рядом логически (например, за один и тот же день), рядом и физически например, для удобства сканирования таблиц. Для этого в терадате существует механизм PARTITIONED PRIMARY INDEX. Это двухуровневый партишионинг таблиц. Если этот механизм используется, то данные в пределах узлов хранятся по партициям, которые мы назначаем при создании или изменении таблицы (см. мой пример про удаление строк выше), а внутри партиций данные упорядочиваются по значениям хэш-индекса.
Использование этого механизма позволяет в определённых случаях довольно сильно повысить производительность при сканировании или соединении таблиц за счёт partition elimination.


2) А представьте, нужно вместо 10 записей, взять по 10 миллионов? Я правильно понимаю, что на время процедуры "репартишина" Терадата не гарантирует получение корректных результатов запросов?


10 миллионов - это детский объём для Терадаты. Как написал Павел, Терадата, действительно, недоступна во время операции добавления узла. Я думаю, любая другая система также будет недоступна при изменении конфигурации железяки, на которой она работает.



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

Откуда:
Сообщений: 1255
Константин Лисянский

Как я уже писал выше, межнодовая передача - естественное явление. Вы правильно заметили, что определённые операции требуют перераспределения данных между узлами.
Для этого в СУБД Терадата существует коммутатор BYNET с довольно высокой пропускной способностью на узел. Кроме того, что он умеет просто передавать данные и сообщения, он ещё и обладает определённым интеллектом, позволяющим более эффективно распараллеливать некоторые операции. Например, возьмём сортировку. Понятное дело, что сначала сортировка выполняется локально на каждом узле. Но ведь, результат должен быть отсортирован глобально, не так ли? Если бы узли были связаны, скажем, с помощью Ethernet, то для окончательной сортировки все данные нужно было бы гнать на один узел. В случае СУБД Teradata окончательную сортировку выполняет сам BYNET. Кроме сортировки, BYNET реализует механизм семафоров, которые использутся для координации работы узлов.

10 миллионов - это детский объём для Терадаты. Как написал Павел, Терадата, действительно, недоступна во время операции добавления узла. Я думаю, любая другая система также будет недоступна при изменении конфигурации железяки, на которой она работает.


С уважением,
Константин Лисянский
http://lissianski.narod.ru


Ну вообще-то если мы про кластера, то добавление узла в Oracle RAC проходит без остановки , как и его изъятие, правда у Oracle архитектура Shared-disk.

То есть если я правильно понял коммутатор BYNET еще и ускоритель сортировки.
Будет ли логичным наличие этих свойств ( аппаратная сортировка ) с аналогичными устройствами для ускорения скажем дополнительный криптовальный процессор?

Сдается мне TERADATA следует рассматривать как узкоспециализированое решение для определенных задач.

Да, кроме того в условиях задачи сказано , что система у нас смешаная.
А что нам предлагает TERADATA для систем OLTP?

Хотелось бы иметь хоть какое-то представление о стоимости таких решений.
Я готов согласиться что для определенных задач использование ТERADATA вполне оправдано, но как насчет цифр.
Такими цифрами для меня являются например данные приведенные в тестах TPC-C или TPC-H.
Я допускаю что TERADATA "The best" для DSS систем, но где цифры тестов.

То что продукт используется для серьезных решений - это не трудно узнать, но где цифры?
Поймите меня правильно.
Утверждение что компания А использует продукт Х не является доказательством для компании B того факта что продукт X лучше чем продукт Y. Обычно для этого используют тесты.
11 авг 04, 12:19    [873774]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Константин Лисянский
А удаление старых данных просто прелесть, Я за 10 -20 минут удаляю
20 млн записей из 100 млн таблицы путем отсоединения партиций.
Кто быстрее и как?


То же самое в Терадате. Только не очень понятно, зачем так долго? За 20 минут, как известно, можно добежать до канадской границы :)


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

Константин Лисянский

За 10-20 минут можно 20 млн записей загрузить в таблицу из текстового файла. А уж партиции подропать - так это секунды.


С уважением,
Константин Лисянский
http://lissianski.narod.ru


Да не вопрос, все зависит от производительности системы ввода вывода.

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

Откуда: от туда...
Сообщений: 265
IMHO, kogda rec o TB informacii, testy (tpc) eto tolko 5% pri vybore sistemy. ~80% eto pilotnyj projekt + cena 3-5 let ekspluatacii.

Moi sovet, Sergej, pocitaite/pogovorite bolse s Sybase, TDATA, IBM. Na segmente VLDB, ne tak vse ocevidno kak na rynke SMB. Sybase (IQ), TData- akcentiryjut sebja kak VLDB sdelanye s nulia, specialno dlia VLDB i DWH.

I Sybase IQ i TDATA konkurirujut ocen silno. Dostoinstvo TData - opyt (20let, >1000 DWH, specializacija - tolko DWH, baza udachnyh vnedrenii). Dlia nekotoryh otraslej bolhoi plius naliche horosei modeli dannyh dlia EDW (konkurenty Sybase IWS i IBM). Nedostatok - cena i sloznost/unikalnost HW.

Dostoinstvo IQ - prostota, cena, vozmoznost nacat na zeleze s 1CPU/Win, krutit na takom zeleze 100-150+GB raw data (cto v Oracle u vas zaimet gigabaitov 500-700 ili bolshe, pricem budete imet ~5 indeksov, a v IQ kazdoe pole avtomaticheski index), lineino rasti (linear scalability) - MPP ne obespecit takogo urovnia scalability. Takze est ocen horosie refference. Minus - IQ prosto baza, bez ETL, bez generatorov otcetov, mozet rabotat kak OLTP, no medlenno (kazetsia ~5000tranzakcii/cas) i t.d.

Mne v principe vse ravno, no posovetoval by vstretitsia s Konstantinom i pozvonit v local Sybase, hotite v IBM mozete tohe pozvonit. A to neserjezno kakto vygliadit. Napominaet : ja znaju MS+Oracle na etom i budu delat. A esli ktoto MySQL znaet - cto, na nem pisat?
11 авг 04, 12:44    [873895]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
Такими цифрами для меня являются например данные приведенные в тестах TPC-C или TPC-H.
Я допускаю что TERADATA "The best" для DSS систем, но где цифры тестов.


вроде бы они когда-то были самые крутые в tpc-h, но потом ушли, у оракла где-то даже документ был почему они уходят. в тот момент когда ушли они были в переди но оракл слишком быстро нагонял ...

теперь у них 4% рынка против 51% оракла.
http://www.oracle.com/solutions/business_intelligence/giga_dw.html
11 авг 04, 12:49    [873922]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

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

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


Мы пока использем 2 и 4 канальные контроллеры.
На каждом канале 6-8 дисков, но делается один большой RAID0+1 впределах либо 2-4 каналов ( зависит от контроллера).


onstat-

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


Это несколько не то.
Я могу обяснить в терминах Oracle.
Таблица лежит в табличном пространстве, которое состоит из определенного кол-ва файлов. Померяв ввод-вывод на файлы, нужно раскладывать эти файлы по дискам ( не важно это Физический диск или логичексий( RAID1 например). Причем тут партиции?
Я понимаю что можно разложить на партиции по числу дисков, но смысла особого я в этом не вижу.


EugeneS

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



onstat-

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

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


Данные получены sar или iostat.
страйп 256к размер блока 8к.
Вы наверно подразумевает в ваших высказываниях чистый OLTP?
Я никогда не настраиваю систему только под OLTP.
Ну не видел я в своей жизни чистых систем OLTP. Cмешанных сколько угодно.
А вот если говорить о чистом OLTP тогда имеет смысл маленький размер страйпа я с этим согласен, и то это очень сильно зависит от того какой объем поступает в БД.
OLTP тоже быват разные.
Пример биллинговая система телефонной компании.
Программа тарификатор выполняет загрузку файлов в БД при этом на каждую вставляемую запись "дергает" справочники и таких несколько потоков, но и данные вставляет в БД скажем 20млн.

В результате используя подхож SAME дешевле все сложить на один большой RAID0+1. Пока все мои попытки доказать себе обратное не увенчались успехом.


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

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

onstat-

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


ДА, значит если чтение идет с файловой системы, без специальных условий монтирования или использования RAW-device.
100%.
Для Oracle в этом леко убедиться
http://www.ixora.com.au/scripts/sql/multiblock_read_test.sql
В результате выясняем размр io_max_size он в большинстве случаев равем 1МБ. В ранних версиях систем может быть равен 64к или 256к.
Например на Solaris это размер можно менять от 1МБ до 4МБ.

Использование фаловой системы для хранения данных подразумевает двойную буфферизацию.
Избежать этого можно но не всегда эффективно получается.
1. Некоторые файловые системы позволяют монтироваться в режиме DIRECT_IO, но честно скажу не пробовал.
2. Использовать RAW-device, что довольно геморно и требует гораздо больших затрат на администрирование, часто проскакивает информация о том что такой режим дает до 20% выйгрыша.
Пробовал, но отказались именно из-за трудности сопровождения.
11 авг 04, 12:59    [873975]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
_Dog
IMHO, kogda rec o TB informacii, testy (tpc) eto tolko 5% pri vybore sistemy. ~80% eto pilotnyj projekt + cena 3-5 let ekspluatacii.

Moi sovet, Sergej, pocitaite/pogovorite bolse s Sybase, TDATA, IBM. Na segmente VLDB, ne tak vse ocevidno kak na rynke SMB. Sybase (IQ), TData- akcentiryjut sebja kak VLDB sdelanye s nulia, specialno dlia VLDB i DWH.

I Sybase IQ i TDATA konkurirujut ocen silno. Dostoinstvo TData - opyt (20let, >1000 DWH, specializacija - tolko DWH, baza udachnyh vnedrenii). Dlia nekotoryh otraslej bolhoi plius naliche horosei modeli dannyh dlia EDW (konkurenty Sybase IWS i IBM). Nedostatok - cena i sloznost/unikalnost HW.

Dostoinstvo IQ - prostota, cena, vozmoznost nacat na zeleze s 1CPU/Win, krutit na takom zeleze 100-150+GB raw data (cto v Oracle u vas zaimet gigabaitov 500-700 ili bolshe, pricem budete imet ~5 indeksov, a v IQ kazdoe pole avtomaticheski index), lineino rasti (linear scalability) - MPP ne obespecit takogo urovnia scalability. Takze est ocen horosie refference. Minus - IQ prosto baza, bez ETL, bez generatorov otcetov, mozet rabotat kak OLTP, no medlenno (kazetsia ~5000tranzakcii/cas) i t.d.

Mne v principe vse ravno, no posovetoval by vstretitsia s Konstantinom i pozvonit v local Sybase, hotite v IBM mozete tohe pozvonit. A to neserjezno kakto vygliadit. Napominaet : ja znaju MS+Oracle na etom i budu delat. A esli ktoto MySQL znaet - cto, na nem pisat?

Большое спасибо за совет, возможно, я им воспользуюсь...

ИМХО, лучше делать на том, что знаешь, чем на том, чего не знаешь... В любом случае при выполнении проекта максимум - что будет возможно - это консультации со спецами вендора. Отдавать проект на сторону мы не будем.

ЗЫ
Ни Terradata, ни SyBase не подходят под условия:
  • быть распространенной и известной
  • на рынке труда должно существовать достаточное количество грамотных специалистов, способных администрировать и поддерживать эту СУБД
  • с RAD-средствами тут тоже не все однозначно...
  • 11 авг 04, 14:53    [874580]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

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


    Это несколько не то.
    Я могу обяснить в терминах Oracle.
    Таблица лежит в табличном пространстве, которое состоит из определенного кол-ва файлов. Померяв ввод-вывод на файлы, нужно раскладывать эти файлы по дискам ( не важно это Физический диск или логичексий( RAID1 например). Причем тут партиции?
    Я понимаю что можно разложить на партиции по числу дисков, но смысла особого я в этом не вижу.


    В терминах Oracle я это имел ввиду:

    Oracle8i Concepts Release 2 (8.1.6)


    Partitioning addresses the key problem of supporting very large tables and indexes by allowing you to decompose them into smaller and more manageable pieces called partitions. Once partitions are defined, SQL statements can access and manipulate the partitions rather than entire tables or indexes. Partitions are especially useful in data warehouse applications, which commonly store and analyze large amounts of historical data.
    .......................
    CREATE TABLE sales ( acct_no NUMBER(5),
    acct_name CHAR(30),
    amount_of_sale NUMBER(6),
    week_no INTEGER )
    PARTITION BY RANGE ( week_no ) ...
    (PARTITION sales1 VALUES LESS THAN ( 4 ) TABLESPACE ts0,
    PARTITION sales2 VALUES LESS THAN ( 8 ) TABLESPACE ts1,
    ...
    PARTITION sales13 VALUES LESS THAN ( 52 ) TABLESPACE ts12 );




    EugeneS


    Использование фаловой системы для хранения данных подразумевает двойную буфферизацию.



    100% истина. RESPECT. И никакая база уважающая себя база не использует
    кеш файловой ситемы для ввода вывода.
    Данные через DMA попадают в адресное пространство базы.
    А с кеша ФС еще memcpy делать нужно, а это уже не DMA это нагрузка на процесор.

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

    Откуда: Москва
    Сообщений: 902
    ИМХО, лучше делать на том, что знаешь, чем на том, чего не знаешь...


    Сергей, вообразите на секунду, что всё, что Вы знаете - это MS Access. Вы стали бы делать на нём терабайтное хранилище?
    Смотрели фильм "Последний самурай"? Там в конце батальная сцена, где всех самураев таки расстреляли из пулемёта. К сожалению, несмотря на то, что они виртуозно владели мечами и луками.

    автор
    Ни Terradata, ни SyBase не подходят под условия:
    быть распространенной и известной


    Если ограничить объём данных снизу терабайтом, то Терадата -распространённая и известная. А если ограничить системы только хранилищами данных - то доминирующая.

    на рынке труда должно существовать достаточное количество грамотных специалистов, способных администрировать и поддерживать эту СУБД


    Администрируется не сложнее MS SQL (в отличие от Oracle, например). Большинство операций производится автоматически. Система поставляется уже установленной и сконфигурированной. Сервер имеет средства для удалённого подключения для мониторинга и предупреждения о возможных отказах оборудования.


    с RAD-средствами тут тоже не все однозначно...


    Если речь идёт о DSS, то RAD - понятие не очень широко используемое в этой области. Есть куча визуальных тулзов для администрирования и разработки приложений. Есть продукты партнёров класса OLAP/Reporting, есть свои средства класса Data Mining.

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


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

    Откуда: от туда...
    Сообщений: 265
    Константин Лисянский


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


    vot vot. tolko k sozaleniju mne kazetsia cto Sergej ne zakazcik a prosto hocet ne poteriat klienta.
    11 авг 04, 16:31    [875015]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    _Dog
    Member

    Откуда: от туда...
    Сообщений: 265
    [quot Сергей Тихонов
    ЗЫ
    Ни Terradata, ни SyBase не подходят под условия:
  • быть распространенной и известной
  • на рынке труда должно существовать достаточное количество грамотных специалистов, способных администрировать и поддерживать эту СУБД
  • с RAD-средствами тут тоже не все однозначно...[/quot]

    1. Absoliutno neserjozno. V VLDB eto igroki s desiatkami klientov v telco, bankah, retail i t.d. ( VLDB s TB dannyh - eto toze silno rasprostranennaja sistema?)
    2. Eto - da. Sybase IQ mozet administrirovat liuboi tolkovyi administrator Sybase ASA (jadro IQ - ASA). Training mense nedeli. Cenu admina dlia ASA, mozete predstavit. Podderzka i proektirovanie ... delat VLDB na RDBMS sozdannoi dlia togo ctoby byt VLDB - legce.
    3. Po povodu TD ne znaju, po povodu IQ - problem net (konecno ne Oracle RAD:) Povtorius, ni TData ni IQ ne pozicionirujutsia kak OLTP. Tut bolee aktualna podderzka BObjects, Cognos, Microstrategy, Excell i t.d. i t.p.

    Strah cto vendor zahocet zabrat project - eto sami smotrite. Znaju, cto TData ocen liubit prodat sama. Obsluzivanie posle prodazi - raznye varianty.
  • 11 авг 04, 16:35    [875024]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    killed
    Member

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


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

    По распараллеливание - очереди на ВВ будут к *каждому_диску*, а не контроллеру.


    Для меня они уже давно тривиальные.
    1. Посмотрите в операциооной
    системе sar если у вас unix или performance monitor если винда
    и скажите сколько очередей на один диск(массив). На то они и очередь чтобы в ней стоять. :)

    2. Учтите что в кеш контролера попадает минимум srtipe* количество дисков объем данных. Как быстро он забьется не нужным базой мусором? А темболее
    на терабайтной базе. И переписывается тоже этот весь объем в случае изменения. Посмотрите мои предидущие посты там исследовалась база в пол терабайта.

    3.Обьясните как паралелится очередь на каждый диск если 1 операция
    ВВ читает одновременно страйпы со всех дисков, и операция длится
    до тех пор пока линейка страйпов не будет обработана на всех дисках.
    Паралельно можно читать только то что записано а не то что хочет база.
    В чем тут паралелизм?


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


    1. Видите ли, sar - это уровень ОS, он по определению не знает, что там скрывается за этими массивами. Поэтому смотреть на него в этом разрезе нет смысла. Если следовать вашей логике, то если у меня два массива, то степень распараллеливания ВВ = 2. А это неверно.

    2. Понимаете, кэшу контроллера по большому счету наплевать, чего там в него попадает. Страйпы там, мирроры. Что такое "не нужный базе мусор" ? Ну не храните на дисках контроллера данных не относящихся к базе - не будет мусора.
    К чему этот пункт? Я не совсем понял. Ну есть кэш контроллера, для простоты считайте, что его нету. Этакий небольшой бонус при проектировании подсистемы ВВ.
    3. Вы не забывайте, что система многопользовательская. У каждого диска в массиве своя очередь запросов. Если один пользователь читает блок с первого зеркала RAID10, что мешает другому читать параллельно с зеркала N того же массива? Это параллелизм? Да.

    Мультиблочная операция чтения, которая покрывает всю ширину страйпа - она использует параллелизм ВВ ? Да, благодаря страйпингу.
    Кстати по вашей логике такая операция - неделима на аппаратном уровне (все остальные ждут, пока не отработает), я так не считаю.
    11 авг 04, 20:59    [875675]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

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


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

    По распараллеливание - очереди на ВВ будут к *каждому_диску*, а не контроллеру.


    Для меня они уже давно тривиальные.
    1. Посмотрите в операциооной
    системе sar если у вас unix или performance monitor если винда
    и скажите сколько очередей на один диск(массив). На то они и очередь чтобы в ней стоять. :)

    2. Учтите что в кеш контролера попадает минимум srtipe* количество дисков объем данных. Как быстро он забьется не нужным базой мусором? А темболее
    на терабайтной базе. И переписывается тоже этот весь объем в случае изменения. Посмотрите мои предидущие посты там исследовалась база в пол терабайта.

    3.Обьясните как паралелится очередь на каждый диск если 1 операция
    ВВ читает одновременно страйпы со всех дисков, и операция длится
    до тех пор пока линейка страйпов не будет обработана на всех дисках.
    Паралельно можно читать только то что записано а не то что хочет база.
    В чем тут паралелизм?


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


    1. Видите ли, sar - это уровень ОS, он по определению не знает, что там скрывается за этими массивами. Поэтому смотреть на него в этом разрезе нет смысла. Если следовать вашей логике, то если у меня два массива, то степень распараллеливания ВВ = 2. А это неверно.



    Через узкое горлышко большую бутылку можно наполнять очень долго. Может здесь все зависит от драйвера RAID, но я не думаю что в emulex криво зделали эмуляцию SCSI в fiber channel. При запасе производительносит в SAN и на дисковой стойке средняя скорость 15Мбайт/с на логический диск,
    не зависимо от того какой там масив собран. Пробовали RAID1 & RAID10
    Общая скорость ввода вывода росла практически линейно до 6 томов RAID1(дальше не пробовали). то есть в моем случае 6ХRAID1 оказались быстрее
    RAID10 такого же объема ровно в количество раз равное количеству дисков/2
    Незначительное снижение скорости(10%) наблюдалось при страйпировании
    этих RAID1 средствами OS.
    Проверялось на 4Х PIV Xeon OS Win2000AS.


    killed

    2. Понимаете, кэшу контроллера по большому счету наплевать, чего там в него попадает. Страйпы там, мирроры. Что такое "не нужный базе мусор" ? Ну не храните на дисках контроллера данных не относящихся к базе - не будет мусора.
    К чему этот пункт? Я не совсем понял. Ну есть кэш контроллера, для простоты считайте, что его нету. Этакий небольшой бонус при проектировании подсистемы ВВ.


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

    Если по поводу атомарности я не ошибаюсь, и бонус всетаки имеется то
    Если размер страйпа в десятки раз привышет размер блока базы,
    вероянтость попадания другого блока по индексу в этом страйпе ничтожно мал
    на терабайтной базе. Т.Е. весь страйп кроме одного блока базы прочитан неперед, но использован не будет. И весь страйп будет вытеснен из кеша(бонуса) в ближаешее время. Эти не используемые базой в данный момент блоки этого страйпа я и называл "мусором".
    В raw device тяжело хранить еще что нибудь помимо базы данных.

    killed


    3. Вы не забывайте, что система многопользовательская. У каждого диска в массиве своя очередь запросов. Если один пользователь читает блок с первого зеркала RAID10, что мешает другому читать параллельно с зеркала N того же массива? Это параллелизм? Да.
    Мультиблочная операция чтения, которая покрывает всю ширину страйпа - она использует параллелизм ВВ ? Да, благодаря страйпингу.
    Кстати по вашей логике такая операция - неделима на аппаратном уровне (все остальные ждут, пока не отработает), я так не считаю.


    Гугл очень много толковых ссылок дал по этому поводу,
    Вы правы, Снимаю шляпу.


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

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

    Через узкое горлышко большую бутылку можно наполнять очень долго. Может здесь все зависит от драйвера RAID, но я не думаю что в emulex криво зделали эмуляцию SCSI в fiber channel. При запасе производительносит в SAN и на дисковой стойке средняя скорость 15Мбайт/с на логический диск,
    не зависимо от того какой там масив собран. Пробовали RAID1 & RAID10
    Общая скорость ввода вывода росла практически линейно до 6 томов RAID1(дальше не пробовали). то есть в моем случае 6ХRAID1 оказались быстрее
    RAID10 такого же объема ровно в количество раз равное количеству дисков/2
    Незначительное снижение скорости(10%) наблюдалось при страйпировании
    этих RAID1 средствами OS.
    Проверялось на 4Х PIV Xeon OS Win2000AS.


    Тут вот какое дело. Если шина - чистый SCSI , ее довольно легко забить. Кстати, на OLTP это сделать проще, вопреки распространненому мнению. SAN SCSI-FC - промежуточный вариант - "SAN для бедных". А вот чистый FC (2 канала по 2Гбит/сек.) сделать узким местом будет трудно. По меньшей мере я просто не встречался пока с таким случаем.

    По поводу 15Мб/сек. - это все очень индивидуально, host-specific, поэтому трудно с чем-то сравнивать эту цифру.

    По поводу RAID1 vs RAID10. У вас может быть система с преимущественно одноблочным чтением (не работает страйпинг) и я так предполагаю, тестировали с небольшим кол-вом пользователей. Поэтому такой результат. Правда позже у вас будет болеть голова по поводу ручной балансировки ВВ между этими 6 RAID1, о чем вам уже писали выше.


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


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

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


    Если по поводу атомарности я не ошибаюсь, и бонус всетаки имеется то
    Если размер страйпа в десятки раз привышет размер блока базы,
    вероянтость попадания другого блока по индексу в этом страйпе ничтожно мал
    на терабайтной базе. Т.Е. весь страйп кроме одного блока базы прочитан неперед, но использован не будет. И весь страйп будет вытеснен из кеша(бонуса) в ближаешее время. Эти не используемые базой в данный момент блоки этого страйпа я и называл "мусором".
    В raw device тяжело хранить еще что нибудь помимо базы данных.


    У оракла есть варианты мультиблочного чтения индекса (Fast Full Index Scan, Full Index Scan) - все зависит от природы конкретного запроса, чаще - это действительно одноблочное чтение.

    Весь страйп (целая полоса) в этом случае не будет прочитан. Чтобы он был прочитан (целиком или частично), нужно чтобы с уровня ОС пришла запрос на чтение кол-ва смежных блоков, достаточного, чтобы покрыть страйп (целиком или частично). Если речь о stripe unit size (порция на одном диске) - думаю зависит от контроллера. Возможно некоторые дешевые контроллеры так и поступают. Здесь ориентироваться нужно на блок (страницу) памяти кэша, для контролера это и есть юнит памяти, в которых он оперирует.

    Raw devices - имхо оптимально для баз данных. То что базы на raw тяжело администрить - обычно говорят те, кто не пробовал. Реально больших неудобств нет, зато надежность, пефоманс выше. Что-то еще кроме БД хранить на тех же дисках - нет смысла. Ну если уж очень надо - смонтируйте на отдельной партиции фс и храните на здоровье.
    12 авг 04, 22:00    [878694]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    onstat-
    Member

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

    Через узкое горлышко большую бутылку можно наполнять очень долго. Может здесь все зависит от драйвера RAID, но я не думаю что в emulex криво зделали эмуляцию SCSI в fiber channel. При запасе производительносит в SAN и на дисковой стойке средняя скорость 15Мбайт/с на логический диск,
    не зависимо от того какой там масив собран. Пробовали RAID1 & RAID10
    Общая скорость ввода вывода росла практически линейно до 6 томов RAID1(дальше не пробовали). то есть в моем случае 6ХRAID1 оказались быстрее
    RAID10 такого же объема ровно в количество раз равное количеству дисков/2
    Незначительное снижение скорости(10%) наблюдалось при страйпировании
    этих RAID1 средствами OS.
    Проверялось на 4Х PIV Xeon OS Win2000AS.



    Тут вот какое дело. Если шина - чистый SCSI , ее довольно легко забить. Кстати, на OLTP это сделать проще, вопреки распространненому мнению.



    Потому что мультиблочных операций меньше,
    соотношение объема ВВ к количеству операций ВВ меньше поэтому накладные расходы на ВВ выше чем в DSS. Оптом читать и писать всегда дешевле.
    Для OLTP более важным критерием есть максимальное количество операций ВВ, чем максимальная скорость ВВ при прочих равных.


    SAN SCSI-FC - промежуточный вариант - "SAN для бедных". А вот чистый FC (2 канала по 2Гбит/сек.) сделать узким местом будет трудно. По меньшей мере я просто не встречался пока с таким случаем.


    OFF: Кстате FC это коммуникационный протокол(читай протокол маршрутизации),
    а не протокол работы с перефирийными устройствами.
    Поэтому SCSI-FC связка существует всегда при подключении
    FC диской системы (реализация FC-SCSI реализована в дисковой стойке или
    на контролере диска).
    FC - это протокол носитель, который инкапсулирует в себе
    протокол более высокого уровня в часности SCSI.
    Я не понял, что вы имели ввиду под вариантом "для бедных",
    он дешевле чего? и за счет чего?
    ======================================================

    Ни FC сеть ни массивы ни диски(которые тоже FC) небыли слабым местом.
    Узким местом был драйвер и его очередь. И распаралелив ВВ между логическими дисками(очередями) драйвера мы получили линейное повышение производительности ВВ.




    По поводу 15Мб/сек. - это все очень индивидуально, host-specific, поэтому трудно с чем-то сравнивать эту цифру.

    По поводу RAID1 vs RAID10. У вас может быть система с преимущественно одноблочным чтением (не работает страйпинг) и я так предполагаю, тестировали с небольшим кол-вом пользователей. Поэтому такой результат. Правда позже у вас будет болеть голова по поводу ручной балансировки ВВ между этими 6 RAID1, о чем вам уже писали выше.



    У меня чистый OLTP.
    Балансировку ввода вывода по табличным пространствам я считаю
    прямой обязаностью ДБА, вот пускай и делает свое дело, я как ДБА
    от эту работу переложить на плечи контролера не пытаюсь.
    При этом экономлю для своей организации десятки тысяч $$ $$$
    на покупке нового железа.

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



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


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




    Если по поводу атомарности я не ошибаюсь, и бонус всетаки имеется то
    Если размер страйпа в десятки раз привышет размер блока базы,
    вероянтость попадания другого блока по индексу в этом страйпе ничтожно мал
    на терабайтной базе. Т.Е. весь страйп кроме одного блока базы прочитан неперед, но использован не будет. И весь страйп будет вытеснен из кеша(бонуса) в ближаешее время. Эти не используемые базой в данный момент блоки этого страйпа я и называл "мусором".
    В raw device тяжело хранить еще что нибудь помимо базы данных.


    У оракла есть варианты мультиблочного чтения индекса (Fast Full Index Scan, Full Index Scan) - все зависит от природы конкретного запроса, чаще - это действительно одноблочное чтение.


    понятное дело.



    Весь страйп (целая полоса) в этом случае не будет прочитан. Чтобы он был прочитан (целиком или частично), нужно чтобы с уровня ОС пришла запрос на чтение кол-ва смежных блоков, достаточного, чтобы покрыть страйп (целиком или частично). Если речь о stripe unit size (порция на одном диске) - думаю зависит от контроллера. Возможно некоторые дешевые контроллеры так и поступают. Здесь ориентироваться нужно на блок (страницу) памяти кэша, для контролера это и есть юнит памяти, в которых он оперирует.


    согласен.


    Raw devices - имхо оптимально для баз данных. То что базы на raw тяжело администрить - обычно говорят те, кто не пробовал. Реально больших неудобств нет, зато надежность, пефоманс выше. Что-то еще кроме БД хранить на тех же дисках - нет смысла. Ну если уж очень надо - смонтируйте на отдельной партиции фс и храните на здоровье.


    Я так и делаю на протяжении последних 5 лет.

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

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

    Тут вот какое дело. Если шина - чистый SCSI , ее довольно легко забить. Кстати, на OLTP это сделать проще, вопреки распространненому мнению. SAN SCSI-FC - промежуточный вариант - "SAN для бедных". А вот чистый FC (2 канала по 2Гбит/сек.) сделать узким местом будет трудно. По меньшей мере я просто не встречался пока с таким случаем.


    И где это такую траву продают?
    1. UltraSCSI320 - это есть ни что иное как 320МБ/с поскольку интерфейс параллельный.
    2. FC-AL 2Gb/c ( Гигабит в секунду ) - интерфейс последовательный.
    Пересчитывает:
    2*1024*1024*1024/8192 = 262,144/1024=256МБ/с

    [url=http://]http://www.sun.com/storage/white-papers/fc_comp.html[/url]

    Fibre Channel Arbitrated Loop
    Fibre Channel is an industry-standard, high-speed serial data transfer interface that can be used to connect systems and storage in point-to-point or switched topologies. Fibre Channel Arbitrated Loop (FC-AL), developed with storage connectivity in mind, is a recent enhancement to the standard that supports copper media and loops containing up to 126 devices, or nodes. Like SSA, FC-AL loops are hot-pluggable and tolerant of failures.
    The FC standard supports bandwidths of 133 Mb/sec., 266 Mb/sec., 532 Mb/sec., 1.0625 Gb/sec., and 4 Gb/sec. (proposed) at distances of up to ten kilometers. Gigabit Fibre Channel's maximum data rate is 100 MB/sec. (200 MB/sec. full-duplex) after accounting for overhead.

    In addition to its strong channel characteristics, Fibre Channel also provides powerful networking capabilities, allowing switches and hubs to enable the interconnection of systems and storage into tightly-knit clusters. These clusters will be capable of providing high levels of performance for file service, database management, or general purpose computing. Because it is able to span up to 10 kilometers between nodes, Fibre Channel will allow the very high speed movement of data between systems that are greatly separated from one another.

    The FC standard defines a layered protocol architecture consisting of five layers, the highest defining mappings from other communication protocols onto the FC fabric. Protocols supported include:


    Small Computer System Interface (SCSI)
    Internet Protocol (IP)
    ATM Adaptation Layer for computer data (AAL5)
    Link Encapsulation (FC-LE)
    IEEE 802.2
    Because the details of the FC technology are hidden by the protocol interfaces, the impact on system software is minimal.
    Remarkably, all supported protocols can be used simultaneously. For example, an FC-AL loop running IP and SCSI protocols can be used for both system-to-system and system-to-peripheral communication, sharing a communication path that is as fast as most mainframe backplanes. This capability eliminates the need for separate I/O controllers, dramatically reducing costs, cabling complexity, and board count. (This is especially an advantage over SCSI installations, in which controller proliferation can become a significant problem.) Furthermore, users who have already invested in FC for their system interconnection can leverage that investment to meet their peripheral interconnection needs as well.



    Так что большой привет, насчет скорости FC-AL.
    кол-во устройств и расстяние , это далеко не производительность.
    13 авг 04, 16:05    [880953]     Ответить | Цитировать Сообщить модератору
     Re: Проект построения большой БД - давайте пообсуждаем  [new]
    killed
    Member

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

    Так что большой привет, насчет скорости FC-AL.
    кол-во устройств и расстяние , это далеко не производительность.


    Я согласен, что U320 по скорости приближается к FC.
    Только Вы burst rate привели. Для скази умножьте это примерно на 0.6. Это будет ближе к истине.
    13 авг 04, 20:05    [881652]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 13   вперед  Ctrl
    Все форумы / Сравнение СУБД Ответить