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

Откуда: С-Петербург
Сообщений: 2347
2 Kulikov
>>Ты не говори про лицензию ты попробуй. За 90 дней обыгаться можно до потери сознания и пульса :)

Дадут шанс - обязательно попробую. Потому как очень интересно.:)
Во всяком случае поучиться настраиваить подобную систему очень хочу.

Кстати, для всех - DB2 самая легко настраиваемая система. *Это мой субъективный взгляд конешно*

2 Сергей Тихонов.
Просмотрел указанную Вами ссылочку.

With Microsoft SQL Server 2000, scale out is generally accomplished via clustered architectures. In a clustered database architecture, multiple autonomous systems, each containing a copy of the operating system and a copy of the database engine, share a single copy of the database. The multiple copies of the database and operating system coordinate with one another but are controlled separately. This arrangement is generally referred to as a "loose coupling" of the operating systems.

В статье все-же написано что Sharing Nothing - теоретически д.б. более линейно масштабируемой системой.
Из статьи я также понял, что механизмы кластеризации в Windows реализованы для общего случая, а не конкретно под SQL Server, и
и следовательно такое решение не будет столь же хорошо масштабирроваться как для MPP архитектуры, которую предлагают IBM,Sybase,Nonstop SQL.
может именно поэтому в конце статьи дается совет - scale up (нарастить один сервер) прежде чем scale out (делать кластер).

Наверно все дело в реализации.
Основной довод в пользу scale up - кластер работает со скоростью самого медленного узла. Ну что тут сказать?... Правильной балансировкой нагрузки должен заниматься администратор БД.


Искать нечто подобное этой статье и именно от IBM...не возьмусь...)))
Разве что предложу посмотреть эту ссылочку:
http://www-306.ibm.com/software/data/db2/udb/support/manualsNLVv8.html#ru_main
- руководство администратора
9 авг 04, 15:12    [868913]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2killed: Что ты подразумеваешь под синхронизацией в данном случае, пример если не сложно.

P.S. У IBM есть Shared-Disk. Db2 on zSeries, блокировка и контроль конкурентного доступа к ресурсам на аппаратном уровне.
9 авг 04, 15:27    [868972]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
gardenman
Наверно все дело в реализации.
Основной довод в пользу scale up - кластер работает со скоростью самого медленного узла. Ну что тут сказать?... Правильной балансировкой нагрузки должен заниматься администратор БД.

Нет, думаю - смысл не в этом. Смысл в том, что БД легче масштабируются при архитектуре scale up. Дело все в том (помимо прочего), что межсерверные соединения гораздо медленнее, чем внутрисерверные шины. С учетом накладных расходов на обмен данными между узлами, получаем результат :-\\. Об этом, кстати, писали недавно в одном из номеров журнала "Byte Россия"...

ЗЫ
В том же BOL для MSSQL говорится, что роутинг запросов должны организовывать разработчики. Потому как даже если у нас распределенное секционированное представление и СУБД будет обрабатывать только нужные таблицы на нужном сервере, "прокачка" данных через узел, на который пришел запрос, негативно влияет на производительность...
9 авг 04, 15:36    [869006]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
gardenman
В статье все-же написано что Sharing Nothing - теоретически д.б. более линейно масштабируемой системой.
Нет, в статье говорится, что единственный плюс scale out - неограниченная возможность наращивать ресурсы системы. И это все при куче всяких но: администрирование, управление, обслуживание и т.д.
9 авг 04, 15:44    [869036]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
>>С учетом накладных расходов на обмен данными между узлами, получаем результат

Так по-моему в том и состоит суть архитектуры MPP чтобы сократить такую прокачку до минимума. В идеале на каждом узле д.б. обработаны только свои данные. Причем резутьтат - это не только SELECT, но и INSERT/UPDATE/DELETE.
Это называется межраздельным пареллелизмом.
9 авг 04, 15:53    [869078]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Говорить что сейчас основной тормоз в ХД это сеть.
На данный момент не совсем корректно.

Сеть 1GBit это примерно 80МB в секунду с издержками.
Диск это примерно 5МБ в секунду

То бишь если мы копируем какой-нибудь большой файл по сети нам нужно примерно 16 дисков что-бы забить сеть.

В БД конечно все не так, у нас есть кэш и все такое и диски нужно читать реже, но
Это работает пока объем БД сравним с объемом ОЗУ. Когда у нас начинаются хранилища данных и ОЗУ/объем ХД примерно 10%, то ....
9 авг 04, 16:11    [869135]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Nikolay Kulikov
Говорить что сейчас основной тормоз в ХД это сеть.
На данный момент не совсем корректно.

Сеть 1GBit это примерно 80МB в секунду с издержками.
Диск это примерно 5МБ в секунду

То бишь если мы копируем какой-нибудь большой файл по сети нам нужно примерно 16 дисков что-бы забить сеть.

В БД конечно все не так, у нас есть кэш и все такое и диски нужно читать реже, но
Это работает пока объем БД сравним с объемом ОЗУ. Когда у нас начинаются хранилища данных и ОЗУ/объем ХД примерно 10%, то ....

ИМХО, сравнение слегка некорректное. Потому как большие БД - это не 1 диск в 5МБ в секунду, это дисковый массив(ы) - обычно RAID10 со страйпом... Если взять, скажем, Hitachi Data Storage, там канал между стойкой и сервером порядка 2Gbit, так что...
9 авг 04, 16:20    [869160]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2Сергей Тихонов: Если у тебя в крутом хитачи будет 4 диска (я утрирую) ты не сможешь из них выжать 80 МБ в сек :)
Данные читаются с диска, а не со Storage. И опять же в Shared-Nothing тебе не надо всю "терабайтную таблицу" гонять по сети.
9 авг 04, 16:26    [869180]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
2killed: Что ты подразумеваешь под синхронизацией в данном случае, пример если не сложно.

P.S. У IBM есть Shared-Disk. Db2 on zSeries, блокировка и контроль конкурентного доступа к ресурсам на аппаратном уровне.


Возможно, я не совсем правильно выразился. Попробую обьяснить свою мысль. Если в архитектуре shared nothing каждый нод хранит лишь свои собственные данные, то синхронизации данных между нодами не нужна. Но в любом случае неизбежны проблемы с балансировкой нагрузки. Администратора не будем рассматривать. Для серьезных продакшн систем, пытаться балансировать данные между нодами вручную - самоубийство. Остается как я понимаю один путь. Увеличивать кластер в тех нодах, которые выпадают по нагрузке. Фактически - это "деление пополам".

Если данные по нодам пересекаются (если это позволяет архитектура), то межнодовая синхронизация нужна. Это с точки зрения здравого смысла. Но как это делается - не знаю. С шаред-нафинг не работал, поэтому могу ошибаться.
9 авг 04, 16:30    [869193]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
а откуда цифра 5Мб/сек ?

Диск выдает 20-40Мб/сек. Страйпингом поднимаем еще выше. Согласен с Тихоновым, что сейчас альтернативы SAN нету, тем более если речь о хранилище в террабайт
9 авг 04, 16:34    [869209]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
5Мб считал по характеристикам первого попавшегося диска, может где и ошибся.
Я не говорю что SAN это плохо я говорю что сеть не всегда узкое место и не все так однозначно при оптимизации.
9 авг 04, 16:42    [869225]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Nikolay Kulikov
2Сергей Тихонов: Если у тебя в крутом хитачи будет 4 диска (я утрирую) ты не сможешь из них выжать 80 МБ в сек :)
Данные читаются с диска, а не со Storage. И опять же в Shared-Nothing тебе не надо всю "терабайтную таблицу" гонять по сети.
Простой пример: если у нас есть 2 таблицы, одна из которых разделена на секции и лежит на разных хостах, и вторая, которая достаточно большая и не может быть по своей природе секционирована (мы можем ее реплицировать если ее объем в пределах разумного, но смысл не меняется): при джоине этих 2 таблиц (запрос запускается на любом из узлов) мы неизбежно имеем ситуацию, когда порция данных должна быть передана с узла на узел (ведь необязательно критерии по секционированной таблице "впишутся" в 1 узел). И даже если оптимизатор правильно определил, откуда и куда лучше это сделать, мы все равно имеем межузловую передачу данных :-\\.
А по поводу скорости дисковой подсистемы - я уже ответил... 2Gbit - это больше, чем 1Gbit Ethernet ;-)) ...
9 авг 04, 16:49    [869246]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
killed
а откуда цифра 5Мб/сек ?

Диск выдает 20-40Мб/сек. Страйпингом поднимаем еще выше. Согласен с Тихоновым, что сейчас альтернативы SAN нету, тем более если речь о хранилище в террабайт


На полном сканировании таблиц да.
На индексном поиске вы страйпингом никогда не поднимите
реальную скорость обмена.

Вопрос в том, что храним? и как ищем? Универсального варианта нет.

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

Откуда: Москва
Сообщений: 607
killed

Возможно, я не совсем правильно выразился. Попробую обьяснить свою мысль. Если в архитектуре shared nothing каждый нод хранит лишь свои собственные данные, то синхронизации данных между нодами не нужна. Но в любом случае неизбежны проблемы с балансировкой нагрузки. Администратора не будем рассматривать. Для серьезных продакшн систем, пытаться балансировать данные между нодами вручную - самоубийство. Остается как я понимаю один путь. Увеличивать кластер в тех нодах, которые выпадают по нагрузке. Фактически - это "деление пополам".

Если данные по нодам пересекаются (если это позволяет архитектура), то межнодовая синхронизация нужна. Это с точки зрения здравого смысла. Но как это делается - не знаю. С шаред-нафинг не работал, поэтому могу ошибаться.


Я тоже доконца не понимаю твою точку зрения, но несколько мыслей вслух.
Строки таблицы распределяются по узлам по hash ключу, т.е мы имеем примерно одинаковое количество таблицы на каждой ноде.
Если у нас у двух таблиц одинаковый hash key то join происходит в пределах одной ноды и результаты отправляются на координирующую ноду.

Когда может потребоваться синхронизация - например у нас огромная таблица и куча мелких справочников. Справочники можно сделать (replicated) что бы их не таскать постоянно по сети на все узлы.

P.S. Я знаю одного западноевропейского оператора у него хранилище на DB2 EEE 70Тб дисков, если найду официальную информацию кину ссылку. Продакшн в полный рост.
9 авг 04, 16:57    [869275]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2Сергей Тихонов: Пример хороший только давай уточнять. Что за такая природа что таблицу нельзя разбить?? И насколько критичен запрос что эту таблицу не держать на каждом узле??? Тут как всегда срабатывает принцип
nothing new, nothing free, no magic
P.S. Давай рассмотрим на конкретном примере, иначе мы перейдем к задаче о сферическом коне в вакууме.
9 авг 04, 17:09    [869312]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Nikolay Kulikov
2Сергей Тихонов: Пример хороший только давай уточнять. Что за такая природа что таблицу нельзя разбить?? И насколько критичен запрос что эту таблицу не держать на каждом узле??? Тут как всегда срабатывает принцип
nothing new, nothing free, no magic
P.S. Давай рассмотрим на конкретном примере, иначе мы перейдем к задаче о сферическом коне в вакууме.
Я хотел сказать о том, что при любом секционировании вполне вероятна (и реальна) ситуация, когда в результате запроса нам нужно будет объединить (join) данные c нескольких узлов. И даже в случае оптимального решения СУБД и выбора правильного узла (с точки зрения быстродействия) мы имеем ситуацию, когда данные будут пересылаться с узла на узел для окончательной обработки...
9 авг 04, 17:42    [869434]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
Да ты прав. Пересылать придется. Но не терабайт же :)
9 авг 04, 17:59    [869487]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
Нет, не терабайты. Все зависит, конечно, от предметной области, разработчиков БД, самой СУБД. Но ситуация с бутылочным горлышком в виде межсерверных соединений - вполне реальна :-\\...
9 авг 04, 18:25    [869594]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
onstat-
killed
а откуда цифра 5Мб/сек ?

Диск выдает 20-40Мб/сек. Страйпингом поднимаем еще выше. Согласен с Тихоновым, что сейчас альтернативы SAN нету, тем более если речь о хранилище в террабайт


На полном сканировании таблиц да.
На индексном поиске вы страйпингом никогда не поднимите
реальную скорость обмена.

Вопрос в том, что храним? и как ищем? Универсального варианта нет.

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


Для хранилища я бы пытался оптимизировать мультиблочные операции чтения (сканирование таблиц и др.) в первую очередь. Кстати страйпинг полезен и для чистого OLTP где 100% - индексный доступ
9 авг 04, 20:45    [869878]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

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


Я тоже доконца не понимаю твою точку зрения, но несколько мыслей вслух.
Строки таблицы распределяются по узлам по hash ключу, т.е мы имеем примерно одинаковое количество таблицы на каждой ноде.
Если у нас у двух таблиц одинаковый hash key то join происходит в пределах одной ноды и результаты отправляются на координирующую ноду.

Когда может потребоваться синхронизация - например у нас огромная таблица и куча мелких справочников. Справочники можно сделать (replicated) что бы их не таскать постоянно по сети на все узлы.

P.S. Я знаю одного западноевропейского оператора у него хранилище на DB2 EEE 70Тб дисков, если найду официальную информацию кину ссылку. Продакшн в полный рост.


Этот hash ключ учитывает hot spots на этой партиц. таблице? Если нет, то получаем неравномерную нагрузку. Еще момент, если необходимо добавить дополнительный узел в кластер, то для сохранения равномерного распределения данных по *всем* узлам кластера нужно заново "размазать" эту таблицу?
9 авг 04, 20:55    [869886]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
А кто-то может дать ссылку, где почитать про Oracle RAC, каким образом, допустим, тяжелые запросы распараллеливаются между узлами кластера и т.п.?
9 авг 04, 22:18    [869970]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

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

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


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

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

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

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

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

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

Откуда:
Сообщений: 1255
Сергей Тихонов
А кто-то может дать ссылку, где почитать про Oracle RAC, каким образом, допустим, тяжелые запросы распараллеливаются между узлами кластера и т.п.?


Oracle9i Real Application Clusters Concepts
Release 2 (9.2)
Part Number A96597-01

4. Scalability in Real Application Clusters

Data Warehouse Systems and Real Application Clusters
Data warehouse systems perform well on Real Application Clusters because applications with low update activity can access the database through different instances without additional overhead. If the data blocks are not modified, then multiple instances can read the same blocks into their buffer caches and perform queries on the blocks without additional I/O. Data warehouse systems usually benefit from scale up and may experience speed up as well.

Oracle Parallel Execution in Real Application Clusters
Real Application Clusters provides the framework for parallel execution. Parallel execution performs efficiently in Real Application Clusters because it can distribute portions of a large SQL statement across multiple instances. The transaction is completed more quickly because it executes on multiple CPUs.

In Real Application Clusters, Oracle determines at runtime whether it will run parallel execution server processes on only one instance, or whether it will run processes on multiple instances. In general, Oracle tries to use only one instance when sufficient resources are available. This reduces cross-instance message traffic.
10 авг 04, 10:39    [870541]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

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

Технологии Informix живут и будут жить в продуктах IBM, как эти
продукты будут называться - вопрос десятый.
От том что сам IBM думает по поводу этих технологий есть любопытный документ:
[url=http://] http://www.snt.com.ru/upload/images/downloads/unallocated/informix_white_paper.pdf[/url]

По моим данным выход IDS 9.5 выходит в конце этого года.
Сейчас IBM развивает и поддерживает продукты Informix не хуже, чем это делалось до приобретения.

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


Я, cнимаю шляпу перед IBM и низко кланяюсь им за подежку "умирающих продуктов" и выход новых версий никак не противоречит сказаному мной.
А именно вспомните OS/2 IBM подерживала ее много лет и выпускала новые версии, но это не было развитие. Это лишь переиод времени( не спорю очень долгий ) в течении которого заказчики медленно переползут на что-то еще.
Они могут вообще не переползать, ведь не секртет, что деньги IBM делает на консалтинге.
10 авг 04, 10:46    [870576]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Коллеги,
ну какого черта вы прицепились к кластерам.
У них, что стоимость, что затраты на сопровождение высокие и самое главное
я ни у кого высоких результатов не видел.
Ну ладно на OLTP и DSS отдельно, но чтобы на смешанных системах это из области фантастики.
Я считаю что следует в нашем случае рассматривать системы c архитектурой SMP, NUMA.
Кроме того давайте определимсяся с цифрами , что такое VLDB.
1. Какой объем ?
2. Сколько OLTP cессий?
3. Сколькл DSS сессий?
После этого можно идти дальше.
10 авг 04, 10:51    [870591]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить