EugeneS

Я вот недавно с одним знакомым общался , у него были проблемы на win32 платформа с Oracle тоже.
Проблема выглядит примерно так.
Поскольку реализация Oracle под Windows мультитредовая , а не мультизадачная как в Unix-like cистемах,то Oracle под Windows -это один процесс , который не может адресовать больше чем 4GB памяти, пользовательские сессии - это треды внутри этого процесса, следовательно число сессий ограничено таки 4GB.
В Unix же пользовательский серверный процесс - у каждого свой ( в Dedicated mode ) и каждый процесс может адресовать 4GB памяти.
Собственно это и есть причина почему 32 разрядность не так давит в Unix-like системах.
Но однозначно для вас 64-bit система - это решение.


Теоретически это возможно,
но процессам нужно обмениваться информацией это возможно
1.через разделяемую памаять
2. pipe
3.диск. (это не рассматриваем).

Прикиньте производительность вашей сесии и всего oracle
если он таблицу, индексы начнет тащить через pipe.
Мы кажется вопросы двойной буферизации уже обсуждали.
и продолжать думаю не стоит.
То есть используется доступ через разделяемую память и семафоры.
Системные вызовы shm* всеравно ограничены разрядностью платформы.
Так, что глобально это ничего не решает.

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

ps я тоже unix люблю больше.

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

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

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


DSA архитектура informix делает тоже самое там есть технология PDQ
которя паралелит все операции.
С точки зрения скорости индексного поска дерево гораздо выгоднее чем список(таблица), На это есть соответствующие выкладки,
ссылок под руками нет. Для меня это само собой разумеещееся.
В качестве примера посмотрите на библиотеку STL С++.


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

По поводу джойнов 100-миллионных таблиц. В Терадате есть алгоритм nonsort-merge join, который не требует предварительной сортировки (поскольку данные всегда хранятся отсортированными по значению хэш-значения), поэтому память для сортировки не нужна.


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

Константин Лисянский
Кстати, в соседнем форуме я приводил результаты своих упражнений с таблицами с более 100 млн записей.

Почитайте здесь, может будет интереснро.


Спасибо, Обязательно загляну.

Константин Лисянский
Если мы говорим о паралелизме, то лучше RISK платформы я не знаю.
Там паралелизм заложен аппаратно.

Здесь, мне кажется, Вы слишком низко опускаетесь. Кроме аппаратного параллелизма должен ещё быть программный. Можно говорить о разных видах приложений - например, приложения, ориентированные на паралельные вычисления - это одно, приложения, ориентированные на параллельную обработку данных (СУБД) - немного другое.


DSA & PDQ меня полностью устраивают в качестве програмной реализации
паралелизма обработки баз данных.

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

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

Любой SMP, а не только Intel страдает потерей линейной масштабируемости при количестве процессоров более 4. Это, на мой взгляд, основная проблема SMP при обработке больших объёмов данных.
Для преодоления этого ограничения существует архитектура MPP.
А данные в кэше для DSS-приложений не имеют такого критического значения, как для OLTP. Об этом коллеги уже говорили выше.


Я не видел реализации MPP для интел,
наверное потому что аппаратная часть подгуляла :)
Помоему MPP работает только на РИСКах.
Мне про DSS тяжело судить потому что у меня чистый OLTP ( 500Gb)
и практического опыта в DSS таких обьемов нет.
Мне кажется, что если мою базу превратить
в DSS и нарезать OLAP кубов
по критерия необходимым для бизнеса база вырастет до 3 Tb.
Лишних пару миллионов на аналитику реководство не дает,
но это их проблемы.
А опыт наверное появится на другой работе .

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

Константин Лисянский
С точки зрения скорости индексного поска дерево гораздо выгоднее чем список(таблица), На это есть соответствующие выкладки,
ссылок под руками нет. Для меня это само собой разумеещееся.

Для меня - не очень. В противном случае деревья уже бы давно использовались в Терадате (напомню, продукту уже чуть более 20 лет).

Использование таблиц даёт определённые преимущества, а именно - возможность обрабатывать индексы параллельно. Как распараллеливается обработка древовидных индексов я, честно сказать, не знаю, поэтому сравнить, наверное, не смогу.


Одни просесс(процессор) берет одну ветку, другой другую,
третий третью. При этом блокировка происходит только на уровне ветки.
То есть процессы друг друга не блокируют. Вставки
строк в таблицу происходят паралельно, если значения ключей индекса
не пересекается на одной ветке дерева, ( имеют разные значения индексного ключа).

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

Константин Лисянский
авторЗато память нужна для хранения хеша который по размеру соизмерим с обьемом индекса. В принципе это индексное объединение таблиц, только по искуственному индексу(хешу). Принципиальных отличий я не вижу.

Не совсем так. Хэш как индекс хранить не надо. Хэш - это функция.
Другое дело, что хэш-значение входит в ROWID и хранится вместе с записью -это так. Но первичный хэш-индекс никогда не хранится, а вычисляется.
[/quot ]

То есть вы имеете ввиду кластерный индекс.
Тогда на вставке удалении вы потеряете в 10 крат.
Как быть с другими индексами? связка таблиц делается не обязательно по
первичному ключу.

Константин Лисянский
[quot ]Я не видел реализации MPP для интел,
наверное потому что аппаратная часть подгуляла :)
Помоему MPP работает только на РИСКах.

1. Терадата MPP работает ТОЛЬКО на Intel.
2. Что значит подгуляла?
3. Ещё раз - нет :)



MPP это апаратная платформа, кто именно производит такое железо
на чипах intel . Какие процессора и чипы используются,
какие ОС работают ?
Если можно ссылки.

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