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

Откуда: Киев
Сообщений: 787
onstat-
это ровно 2 в степени 32 бит.
Угу. Только есть еще такие фичи, как PAE и AWE...
18 авг 04, 18:39    [891929]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Сергей Тихонов
onstat-
это ровно 2 в степени 32 бит.
Угу. Только есть еще такие фичи, как PAE и AWE...


То есть вы хотите сказать, что на 32 разрядной платформе можно
непрерывно адресовать больше чем 2 в степени 32 байт.
Странно почему new, malloc и прочие ограничены разрядностью платформы?

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

Чем больше понимаешь, тем больше осознаешь, что ничего не понимаешь.
18 авг 04, 18:59    [891956]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
onstat-
То есть вы хотите сказать, что на 32 разрядной платформе можно
непрерывно адресовать больше чем 2 в степени 32 байт.
Странно почему new, malloc и прочие ограничены разрядностью платформы?
Насчет непрерывно или нет - не знаю, но адресовать можно. Поищите инфо в хелпе винды (только версии AS или DC) или в инете по этим аббревиатурам (см. выше).
18 авг 04, 19:02    [891961]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Сергей Тихонов
onstat-
То есть вы хотите сказать, что на 32 разрядной платформе можно
непрерывно адресовать больше чем 2 в степени 32 байт.
Странно почему new, malloc и прочие ограничены разрядностью платформы?
Насчет непрерывно или нет - не знаю, но адресовать можно. Поищите инфо в хелпе винды (только версии AS или DC) или в инете по этим аббревиатурам (см. выше).


То что ОС поддерживает я знаю и так.
Я в своей жизни не видел 32 разрадного приложения которому можно былобы отдать больше чем 3GB оперативной памяти. А 4 Gb теоретически возможный предел(IHMO). То есть как ее будет использовать MSSQL аж целых почти 8 Gb.
Для кого покумаем еще 4 Gb памяти с контролем четности.
А что такое 3Gb оперативки для базы данных в терабайт.

С уважением, onstat-
з.ы. Отозвитесь кто отдавал MSSQL больше 3Gb оперативки и как?
18 авг 04, 19:17    [891995]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
onstat-
Отозвитесь кто отдавал MSSQL больше 3Gb оперативки и как?
Я отдавал. На сервере с 4 ГБ памяти MSSQL отдано ~3,35 ГБ. И работает - аж нарадоваться не могу ;-).

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

ЗЫ
А как вы думали, топовые результаты в TPC-C для MSSQL 2000 получены для 32-bit? :-)
18 авг 04, 19:44    [892049]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Городовой
Guest
onstat-
Сергей Тихонов
onstat-
То есть вы хотите сказать, что на 32 разрядной платформе можно
непрерывно адресовать больше чем 2 в степени 32 байт.
Странно почему new, malloc и прочие ограничены разрядностью платформы?
Насчет непрерывно или нет - не знаю, но адресовать можно. Поищите инфо в хелпе винды (только версии AS или DC) или в инете по этим аббревиатурам (см. выше).


То что ОС поддерживает я знаю и так.
Я в своей жизни не видел 32 разрадного приложения которому можно былобы отдать больше чем 3GB оперативной памяти. А 4 Gb теоретически возможный предел(IHMO). То есть как ее будет использовать MSSQL аж целых почти 8 Gb.
Для кого покумаем еще 4 Gb памяти с контролем четности.
А что такое 3Gb оперативки для базы данных в терабайт.

С уважением, onstat-
з.ы. Отозвитесь кто отдавал MSSQL больше 3Gb оперативки и как?

А вот сюда http://support.microsoft.com/default.aspx?scid=kb;en-us;274750 смотрите и пробуете. Про всякие тонкости, это уж отдельно. Но для терабайтных OS проблема все равно не разрешится.
18 авг 04, 19:48    [892063]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Сергей Тихонов

Выводы (для меня во всяком случае) следующие: пока что я рассматриваю только Oracle вместе с RAC, как СУБД, подходящую для моего проекта...


А с ораклом ранее работали?
18 авг 04, 19:51    [892074]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
killed
А с ораклом ранее работали?

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

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

А вот сюда http://support.microsoft.com/default.aspx?scid=kb;en-us;274750 смотрите и пробуете. Про всякие тонкости, это уж отдельно. Но для терабайтных OS проблема все равно не разрешится.


Спасибо, но ограничение в 4GB всеравно остается.
Т.Е. однозначно для баз более терабайта нужна 64 разрядная платформа,
Или про нормальную производительность можно забыть.

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

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

Откуда:
Сообщений: 6941
Сергей Тихонов
onstat-
...однозначно для баз более терабайта нужна 64 разрядная платформа, или про нормальную производительность можно забыть.
Абсолютно согласен :-).


Добрался и посмотрел в Ваш профиль.
Так SUN для Вас самое то, и ходить далеко не нужно,
просто набрать внутренний номер.


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

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

Откуда:
Сообщений: 6941
Сергей Тихонов
onstat-
...Так SUN для Вас самое то...
Почему так однозначно? SUN - один из вариантов...


Вопервых по моим сведениям ваша организация самый крупный поставщик
SUN в Украине(Это не реклама).
Во вторых специалистов у Вас полно.
В третих ну сами понимаете ..... и вобще как это будет выглядеть если генеральный поставщик SUN в Украине покупает у IBM или HP RISK сервер для своих целей.

С уважением, onstat-
ps язык мой - враг мой :)
pps А мне всеравно больше нравится Informix, кстате IBM до сих пор ведет разработку под SUN.
ppps ЭТО НЕ РЕКЛАМА.
18 авг 04, 22:52    [892238]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Константин Лисянский
Member

Откуда: Москва
Сообщений: 902
onstat-
...однозначно для баз более терабайта нужна 64 разрядная платформа, или про нормальную производительность можно забыть.

Абсолютно согласен :-).



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



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

Откуда: Moscow
Сообщений: 3526
Константин Лисянский
onstat-
...однозначно для баз более терабайта нужна 64 разрядная платформа, или про нормальную производительность можно забыть.

Абсолютно согласен :-).



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



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


Тем не менее, сейчас кэш-буферы в несколько гигабайт скорее обычная практика, чем исключение. Память в общем-то не так дорого стоит, грех не воспользоваться. На 32бит платформах (Win, Linux), чтобы адресовать больше памяти придется использовать механизмы трансляции адресов (принцип у всех общий). А это дополнительные издержки. Спрашивается зачем, если можно работать с 64бит и не иметь различных ограничений по определению.

А те клиенты, которых вы упомянули, видимо они уже довольно давно сидят на Террадате. У них был выбор 32 vs 64 в момент покупки? А то ведь и для Оракла можно говорить, что большинство до сих пор сидит на 32 бита и ничего, как то работают.
18 авг 04, 23:37    [892260]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
_Dog
Member

Откуда: от туда...
Сообщений: 265
Дас :) ... Сергей, как автор топика, скажите : Вас все же альтернативы МС и Оракле интересуют или уже нет? А то получится скоро как в ОЛАП форуме с тов. Юрием(ака Cognos.narod): Вы начали с МС и Оракл, а мы Вас Терадату, IQ, IBM пытаемся уговорить попробовать/оценить... Может хватит? :)

killed: Да по-другому там многое. И скорости и железо и design и т.д. Потому что это базы для VLDB и DWH - начиная с ядра, кончая оптимизатором. Допустим агрегированные таблицы могут вообще быть не нужны, partitioning - когда база станет ~2ТБ(или ХХХмлн rows), тюнинга постоянного не надо, загрузка ХХГБ/час и т.д.
19 авг 04, 00:15    [892285]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

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


Добрался и посмотрел в Ваш профиль.
Так SUN для Вас самое то, и ходить далеко не нужно,
просто набрать внутренний номер.
С уважением, onstat-


Я, тоже посмотрел, так мы почти соседи, если вы конечно сидите
У Индустриального моста.

Но мое личное мнение насчет Sun.
1. дела у них идут не очень
2. Очень дорогой support, да еще и без локальных складов.
3. Интерес могут представлять только железо с числом процессоров больше 8 иначе железки на Intel-ах имееют предпочтение.
4. Кластер если уж вы решитесь строить точно не стоит строить на Sun-ах.
19 авг 04, 10:14    [892699]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Павел Новокшонов
Member

Откуда: Moscow -> Atlanta, GA
Сообщений: 90
Т.Е. однозначно для баз более терабайта нужна 64 разрядная платформа, Или про нормальную производительность можно забыть.


Чепуха это батенька.

Приезжайте к нам в соседний Арканзас, там ХД у компании Вол-Март за сотню терабайт прекрасно работает в 32-разрядной архитектуре.

Немного за жизнь. Объем памяти в интелловском серваке от NCR скажем 4 ГБ max. К примеру кластер состоит из 14 узлов. 14Х4=56 ГБ на систему. Объем данных у меня в базе порядка 1 Терабайта. Данные лежат в 3-й нормальной форме и есть несколько десятков больших таблиц каждая из которых может быть порядка 20-30 ГБ. О каком кэше можно говорить когда пользователи выполняют в среднем 10000-15000 DSS запросов в день, объединяя большие таблицы,
используя самые различные условия выборки, выгружая большие объемы данных для построения многомерных кубов PowerPlay и тулзов по визуализации данных. Количество пользователей в ХД около 1000, данные собираются со всех 26 казино компании. Вся производительность на уровне железа определятся кол-вом узлов в системе, скоростью CPU в этих узлах и скоростью дисковой подсистемы (EMC Symmetrix). Оптимизация индексами, приоритеты и пр. это уже отдельные
приблуды.

Кэш конечно же хорош для OLTP запросов и приложений, но не всегда
полезен в терабайтных ХД с большим кол-ом пользователей и самое главное
с неограниченными возможностями строить любые запросы при помощи тулзов типа Cognos или Business Objects конечными пользователями.

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

По поводу Оракла RAC есть ряд вопросов. Насколько его тяжело администрить в многоузловом кластере? Если это 20 узлов, означает ли это что у меня есть 20 инстансов Оракла на каждом узле? Нужно ли создовать dbspace'ы, tablespace'ы, добавлять дисквое пространство, по необходимости, делать реорги, перестраивать индексы и т.п. Скажем в Информиксе и DB2 (версии для OLTP систем) это приходится делать постоянно. В Терадате всего этого нет в принципе. Сущность CУБД одна в независимости от кол-ва узлов.

Насколько хорошо RAC может обрабатывать 20-50 одновременных тяжелых запросов пользователей? Можно ли при этом подгружать данные в хранилище? Данные могут быть в 3 НФ или же это должна быть многомерная
структура? Какие ограничения на ко-во узлов в кластере RAC?

Вопрос сложности администрирования совсем не праздный скажем в Штатах, где хороший DBA получает 80-100K в год и менеджмент учитывает сколько DBA'ев требуется в отдел для поддержки той или иной системы.
19 авг 04, 10:17    [892718]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
onstat-
Member

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


onstat-
...однозначно для баз более терабайта нужна 64 разрядная платформа, или про нормальную производительность можно забыть.

Абсолютно согласен :-).



Позвольте усомниться. Подавляющее количество клиентов Teradata работает на 32-битной платформе. Порядка 200 клиентов имеют базы размером свыше терабайта.



Что значит подавляющее? значит есть есть версия терадаты 64 бит.
Я обращаю ваше внимание на 64 разрядное приложение, а не возможность работать 32 разрдному серверу терадаты на 64 разрядной платформе.
А это очень большая разница.

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

При чём здесь память? Базы данных - это приложения, ориентированные на работу с дисками, а не памятью.


Память очень даже причем, если у вас на индексные деревья
нехватает памяти о чем можно дальше говорить. А на join-ах >100 милионных
таблиц вы обязательно с этим столкнетесь.

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

Производительность СУБД, на мой взгляд, всё же, определяется архитектурой системы, эффективным распараллеливанием обработки и балансировкой нагрузки, продвинутым оптимизатором и в целом хорошим движком sql, а не тем, сколько памяти операционка отводит приложению.


Если мы говорим о паралелизме, то лучше RISK платформы я не знаю.
Там паралелизм заложен аппаратно. Я также незнаю промышленно
выпускаемых сейчас 32 разрядных RISK систем.
IHMO SMP на Intel32 платформе производительность ограничена
частотой системной шины в случае работы с большими объемами данных(в кешах процессров ничего не задерживается).

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

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

Откуда:
Сообщений: 1255
Сергей Тихонов
onstat-
Отозвитесь кто отдавал MSSQL больше 3Gb оперативки и как?
Я отдавал. На сервере с 4 ГБ памяти MSSQL отдано ~3,35 ГБ. И работает - аж нарадоваться не могу ;-).

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

ЗЫ
А как вы думали, топовые результаты в TPC-C для MSSQL 2000 получены для 32-bit? :-)


Я вот недавно с одним знакомым общался , у него были проблемы на win32 платформа с Oracle тоже.
Проблема выглядит примерно так.
Поскольку реализация Oracle под Windows мультитредовая , а не мультизадачная как в Unix-like cистемах,то Oracle под Windows -это один процесс , который не может адресовать больше чем 4GB памяти, пользовательские сессии - это треды внутри этого процесса, следовательно число сессий ограничено таки 4GB.
В Unix же пользовательский серверный процесс - у каждого свой ( в Dedicated mode ) и каждый процесс может адресовать 4GB памяти.
Собственно это и есть причина почему 32 разрядность не так давит в Unix-like системах.
Но однозначно для вас 64-bit система - это решение.
19 авг 04, 10:21    [892737]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Павел Новокшонов

1.По поводу Оракла RAC есть ряд вопросов. Насколько его тяжело администрить в многоузловом кластере? Если это 20 узлов, означает ли это что у меня есть 20 инстансов Оракла на каждом узле? Нужно ли создовать dbspace'ы, tablespace'ы, добавлять дисквое пространство, по необходимости, делать реорги, перестраивать индексы и т.п. Скажем в Информиксе и DB2 (версии для OLTP систем) это приходится делать постоянно. В Терадате всего этого нет в принципе. Сущность CУБД одна в независимости от кол-ва узлов.

2.Насколько хорошо RAC может обрабатывать 20-50 одновременных тяжелых запросов пользователей? Можно ли при этом подгружать данные в хранилище? Данные могут быть в 3 НФ или же это должна быть многомерная
структура? Какие ограничения на ко-во узлов в кластере RAC?

3.Вопрос сложности администрирования совсем не праздный скажем в Штатах, где хороший DBA получает 80-100K в год и менеджмент учитывает сколько DBA'ев требуется в отдел для поддержки той или иной системы.


1. Поскольку в Oracle Rac используется shared-disk, то на узлах будет только кэш и серверные процессы.
То есть это выглядит как несколько хостов разделяющие общее дисковое пространство. То есть реально набор файлов БД, просто он монтируется несколькими экземплярами ( кэш+ системные процессы ).
Все остальное как и везде, необходимо. Перестройка индексов и управление пространство и пр.
2. Этого не знает никто, потому я и настоятельно рекомендовал автору поста использовать "большую железку" для его задачи.

3. А что они еще не отдали все это на outsourcing индусам?
Ну ничего у них еще все впереди.
19 авг 04, 10:35    [892795]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Сергей Тихонов
Member

Откуда: Киев
Сообщений: 787
_Dog
Дас :) ... Сергей, как автор топика, скажите : Вас все же альтернативы МС и Оракле интересуют или уже нет? А то получится скоро как в ОЛАП форуме с тов. Юрием(ака Cognos.narod): Вы начали с МС и Оракл, а мы Вас Терадату, IQ, IBM пытаемся уговорить попробовать/оценить... Может хватит? :)

Может быть и хватит :-)
Во всяком случае для меня доводы и прочитанные документы (см. ссылки выше) в пользу Oracle выглядят убедительнее...

ЗЫ
В любом случае огромное спасибо всем за активное участие в обсуждении топика. Было очень приятно пообщаться и услышать мнения умных людей.
19 авг 04, 10:41    [892819]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
На самом деле надо понимать что в Teradata c 32-bit имеет buffer cache более 4 GB потому что это shared-nothing на каждом узле по 2GB например, и 32-bit Db2 может тоже самое и Informix XPS etc...

Но с другой стороны в shared-nothing 64-bit помогает очень так как можно выделить больше места для bufferpools (shared cache) хотя толку от них в ХД мало, ибо все равно терабайтную БД не засунешь в кэш. A вот то что можно больше памяти выделить под области сортировки, это очень помогает ибо не надо создавать каждный раз временную таблицу и иметь дополнительный IO для сортивоки этого самого терабайта :), a делать все в памяти.
19 авг 04, 10:44    [892834]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
По поводу высокой доступоности и преимуществ Oracle. Для меня не все так очевидно. Так как основное время в процессе восставноление сбоя есть определение того что соседний узел точно умер. Причем это время в гораздо больше или сопоставимо с DB2 Start и Recovery.
19 авг 04, 10:55    [892888]     Ответить | Цитировать Сообщить модератору
 Re: Проект построения большой БД - давайте пообсуждаем  [new]
Yo!
Guest
автор
По поводу высокой доступоности и преимуществ Oracle. Для меня не все так очевидно. Так как основное время в процессе восставноление сбоя есть определение того что соседний узел точно умер. Причем это время в гораздо больше или сопоставимо с DB2 Start и Recovery.


это вам собственный опыт подсказал или отдел маркетинга из IBM ? ;)
19 авг 04, 11:12    [892993]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить