powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Проект построения большой БД - давайте пообсуждаем
25 сообщений из 307, страница 3 из 13
Проект построения большой БД - давайте пообсуждаем
    #32641124
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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
- руководство администратора
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641159
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2killed: Что ты подразумеваешь под синхронизацией в данном случае, пример если не сложно.

P.S. У IBM есть Shared-Disk. Db2 on zSeries, блокировка и контроль конкурентного доступа к ресурсам на аппаратном уровне.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641181
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanНаверно все дело в реализации.
Основной довод в пользу scale up - кластер работает со скоростью самого медленного узла. Ну что тут сказать?... Правильной балансировкой нагрузки должен заниматься администратор БД.
Нет, думаю - смысл не в этом. Смысл в том, что БД легче масштабируются при архитектуре scale up. Дело все в том (помимо прочего), что межсерверные соединения гораздо медленнее, чем внутрисерверные шины. С учетом накладных расходов на обмен данными между узлами, получаем результат :-\\. Об этом, кстати, писали недавно в одном из номеров журнала "Byte Россия"...

ЗЫ
В том же BOL для MSSQL говорится, что роутинг запросов должны организовывать разработчики. Потому как даже если у нас распределенное секционированное представление и СУБД будет обрабатывать только нужные таблицы на нужном сервере, "прокачка" данных через узел, на который пришел запрос, негативно влияет на производительность...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641205
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gardenmanВ статье все-же написано что Sharing Nothing - теоретически д.б. более линейно масштабируемой системой.Нет, в статье говорится, что единственный плюс scale out - неограниченная возможность наращивать ресурсы системы. И это все при куче всяких но: администрирование, управление, обслуживание и т.д.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641234
gardenman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>>С учетом накладных расходов на обмен данными между узлами, получаем результат

Так по-моему в том и состоит суть архитектуры MPP чтобы сократить такую прокачку до минимума. В идеале на каждом узле д.б. обработаны только свои данные. Причем резутьтат - это не только SELECT, но и INSERT/UPDATE/DELETE.
Это называется межраздельным пареллелизмом.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641276
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Говорить что сейчас основной тормоз в ХД это сеть.
На данный момент не совсем корректно.

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

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

В БД конечно все не так, у нас есть кэш и все такое и диски нужно читать реже, но
Это работает пока объем БД сравним с объемом ОЗУ. Когда у нас начинаются хранилища данных и ОЗУ/объем ХД примерно 10%, то ....
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641293
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay KulikovГоворить что сейчас основной тормоз в ХД это сеть.
На данный момент не совсем корректно.

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

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

В БД конечно все не так, у нас есть кэш и все такое и диски нужно читать реже, но
Это работает пока объем БД сравним с объемом ОЗУ. Когда у нас начинаются хранилища данных и ОЗУ/объем ХД примерно 10%, то ....
ИМХО, сравнение слегка некорректное. Потому как большие БД - это не 1 диск в 5МБ в секунду, это дисковый массив(ы) - обычно RAID10 со страйпом... Если взять, скажем, Hitachi Data Storage, там канал между стойкой и сервером порядка 2Gbit , так что...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641305
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Сергей Тихонов: Если у тебя в крутом хитачи будет 4 диска (я утрирую) ты не сможешь из них выжать 80 МБ в сек :)
Данные читаются с диска, а не со Storage. И опять же в Shared-Nothing тебе не надо всю "терабайтную таблицу" гонять по сети.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641314
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov2killed: Что ты подразумеваешь под синхронизацией в данном случае, пример если не сложно.

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

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

Если данные по нодам пересекаются (если это позволяет архитектура), то межнодовая синхронизация нужна. Это с точки зрения здравого смысла. Но как это делается - не знаю. С шаред-нафинг не работал, поэтому могу ошибаться.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641327
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а откуда цифра 5Мб/сек ?

Диск выдает 20-40Мб/сек. Страйпингом поднимаем еще выше. Согласен с Тихоновым, что сейчас альтернативы SAN нету, тем более если речь о хранилище в террабайт
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641337
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
5Мб считал по характеристикам первого попавшегося диска, может где и ошибся.
Я не говорю что SAN это плохо я говорю что сеть не всегда узкое место и не все так однозначно при оптимизации.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641352
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov2Сергей Тихонов: Если у тебя в крутом хитачи будет 4 диска (я утрирую) ты не сможешь из них выжать 80 МБ в сек :)
Данные читаются с диска, а не со Storage. И опять же в Shared-Nothing тебе не надо всю "терабайтную таблицу" гонять по сети.Простой пример: если у нас есть 2 таблицы, одна из которых разделена на секции и лежит на разных хостах, и вторая, которая достаточно большая и не может быть по своей природе секционирована (мы можем ее реплицировать если ее объем в пределах разумного, но смысл не меняется): при джоине этих 2 таблиц (запрос запускается на любом из узлов) мы неизбежно имеем ситуацию, когда порция данных должна быть передана с узла на узел (ведь необязательно критерии по секционированной таблице "впишутся" в 1 узел). И даже если оптимизатор правильно определил, откуда и куда лучше это сделать, мы все равно имеем межузловую передачу данных :-\\.
А по поводу скорости дисковой подсистемы - я уже ответил... 2Gbit - это больше, чем 1Gbit Ethernet ;-)) ...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641354
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killedа откуда цифра 5Мб/сек ?

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

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

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

С уважением, onstat-
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641368
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killed
Возможно, я не совсем правильно выразился. Попробую обьяснить свою мысль. Если в архитектуре shared nothing каждый нод хранит лишь свои собственные данные, то синхронизации данных между нодами не нужна. Но в любом случае неизбежны проблемы с балансировкой нагрузки. Администратора не будем рассматривать. Для серьезных продакшн систем, пытаться балансировать данные между нодами вручную - самоубийство. Остается как я понимаю один путь. Увеличивать кластер в тех нодах, которые выпадают по нагрузке. Фактически - это "деление пополам".

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


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

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

P.S. Я знаю одного западноевропейского оператора у него хранилище на DB2 EEE 70Тб дисков, если найду официальную информацию кину ссылку. Продакшн в полный рост.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641392
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2Сергей Тихонов: Пример хороший только давай уточнять. Что за такая природа что таблицу нельзя разбить?? И насколько критичен запрос что эту таблицу не держать на каждом узле??? Тут как всегда срабатывает принцип
nothing new, nothing free, no magic
P.S. Давай рассмотрим на конкретном примере, иначе мы перейдем к задаче о сферическом коне в вакууме.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641468
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov2Сергей Тихонов: Пример хороший только давай уточнять. Что за такая природа что таблицу нельзя разбить?? И насколько критичен запрос что эту таблицу не держать на каждом узле??? Тут как всегда срабатывает принцип
nothing new, nothing free, no magic
P.S. Давай рассмотрим на конкретном примере, иначе мы перейдем к задаче о сферическом коне в вакууме.Я хотел сказать о том, что при любом секционировании вполне вероятна (и реальна) ситуация, когда в результате запроса нам нужно будет объединить (join) данные c нескольких узлов. И даже в случае оптимального решения СУБД и выбора правильного узла (с точки зрения быстродействия) мы имеем ситуацию, когда данные будут пересылаться с узла на узел для окончательной обработки...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641495
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да ты прав. Пересылать придется. Но не терабайт же :)
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641567
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нет, не терабайты. Все зависит, конечно, от предметной области, разработчиков БД, самой СУБД. Но ситуация с бутылочным горлышком в виде межсерверных соединений - вполне реальна :-\\...
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641735
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat- killedа откуда цифра 5Мб/сек ?

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

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

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

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

Для хранилища я бы пытался оптимизировать мультиблочные операции чтения (сканирование таблиц и др.) в первую очередь. Кстати страйпинг полезен и для чистого OLTP где 100% - индексный доступ
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641739
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nikolay Kulikov

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

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

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

Этот hash ключ учитывает hot spots на этой партиц. таблице? Если нет, то получаем неравномерную нагрузку. Еще момент, если необходимо добавить дополнительный узел в кластер, то для сохранения равномерного распределения данных по *всем* узлам кластера нужно заново "размазать" эту таблицу?
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32641776
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А кто-то может дать ссылку, где почитать про Oracle RAC , каким образом, допустим, тяжелые запросы распараллеливаются между узлами кластера и т.п.?
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32642152
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
killed
Для хранилища я бы пытался оптимизировать мультиблочные операции чтения (сканирование таблиц и др.) в первую очередь. Кстати страйпинг полезен и для чистого OLTP где 100% - индексный доступ


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

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

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

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

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

с уважением, onstat-
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32642163
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сергей ТихоновА кто-то может дать ссылку, где почитать про 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.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32642184
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
onstat-
Технологии Informix живут и будут жить в продуктах IBM, как эти
продукты будут называться - вопрос десятый.
От том что сам IBM думает по поводу этих технологий есть любопытный документ:
http://] http://www.snt.com.ru/upload/images/downloads/unallocated/informix_white_paper.pdf

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

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


Я, cнимаю шляпу перед IBM и низко кланяюсь им за подежку "умирающих продуктов" и выход новых версий никак не противоречит сказаному мной.
А именно вспомните OS/2 IBM подерживала ее много лет и выпускала новые версии, но это не было развитие. Это лишь переиод времени( не спорю очень долгий ) в течении которого заказчики медленно переползут на что-то еще.
Они могут вообще не переползать, ведь не секртет, что деньги IBM делает на консалтинге.
...
Рейтинг: 0 / 0
Проект построения большой БД - давайте пообсуждаем
    #32642190
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коллеги,
ну какого черта вы прицепились к кластерам.
У них, что стоимость, что затраты на сопровождение высокие и самое главное
я ни у кого высоких результатов не видел.
Ну ладно на OLTP и DSS отдельно, но чтобы на смешанных системах это из области фантастики.
Я считаю что следует в нашем случае рассматривать системы c архитектурой SMP, NUMA.
Кроме того давайте определимсяся с цифрами , что такое VLDB.
1. Какой объем ?
2. Сколько OLTP cессий?
3. Сколькл DSS сессий?
После этого можно идти дальше.
...
Рейтинг: 0 / 0
25 сообщений из 307, страница 3 из 13
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Проект построения большой БД - давайте пообсуждаем
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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