Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:

S>> Вообще паралелное чтение и запись в любом случае зло, извежать которое можно многим путями которые много раз описывал и имеются в практике.
S>Как интересно... Можно ссылочку на описане хотя бы одного путя избежать R/W в OLTP задачах? Например, при резервировании авиабилетов. Выделение каждому пассажиру своей авиакомпании не предлагать.
Или при выписке товара. В основном проблемы касаются условно чистого чтения, т.к. даже смомент начала транзакции чтения и ее завершении могут происходить множественные изменения если конечно эти транзакции не последовательны. И стоит ли тратить столько усилий на блокировки и версионное чтение, если можно держать две базы 1 на чтение с синхронизацией много чтецов один писатель, а другая на последовательный доступ для записи с репликацией в базу для чтения с промежутком в 30 сек.
Никаких блокировок, но много ситуаций когда в момент транзакции билетов уже нет. Но возможен вариант когда выбирается не один билет а несколько с приоритетом из которых 1 должен быть обязательно выписан. Вариантов много.
А блокировки с клиента еще большее зло. Хотя ...

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Sinclair, Вы писали:

S>> ODBMS обычно предпочитают хэш-индексы
M>Я припоминаю только одну базу, которая пользовала хеш-индекс, но это было что-то древнее, типа клариона и обходилось это неоправдано дорого с точки зрения места на диске, в итоге уже в следующей версии на это дело забили.
M>Для реляционных баз хеш далеко не лучшее решение, как ни крутись, но при использовании хеш таблиц обмен с диском интенсивнее и меньше поддается оптимизации, и я не очень понимаю, что меняется, если мы начинаем работать с объектами.
А у нас в RDBMS поиск по точному соответствию — экзотика. Как правило, это все-таки join, а для него merge может быть эффективнее. В ОДБМС, напротив, полагают, что запросы типа id<5 делатья будут редко (если вообще их разрешили), а самые частые — это траверсинг, т.е. вытаскивание 1 объекта по его ID. Даже тесты OO7, афаик, занимаются исключительно навигацией по графу. Никаких поисков по предикатоу (а уж тем более IAmountable) там и не пахнет. Так что в теории вроде сходится. Versant раньше использовал хеши для oid, не знаю что с ними сейчас.

Здравствуйте, Serginio1, Вы писали:


S> Давай разберем структуру имеющую поля как числовые, строковые и ссылочные. Обычно это делается через описание полей (заголовочная часть таблицы) и прописания связей в SQL которые по сути и прописывают поведение записей на которых затем и строится запрос. Но возможно делать описание поведения структуры путем введения некоторой большей функциональности. Помоему в клиппере даже хранился скомпилированный код например для вычисления индексного выражения и функции сравнения.
Ну, давай разберем. И чем это нам поможет? У нас класс, а не структура! У него методы есть. А поля всех типов — private.

S> Ну я думаю что оптимизатор еще не дошел "строить совсем другой алгоритм", то либо ручками либо в лоб.
Вот приведи мне пример "ручками"
S> Хорошо пусть будет метод, но выборку с учетом индекса тоже можно делать абсолютно не вникая в тонкости. Что в общем то и делаю, но на объектном уровне. Все те же подходы.
Как интересно. А что ты используешь в качестве ключа такого индекса? Как ты определяешь момент, когда ключ изменился?
S>Просто для работы с коллекцией данных объекта нужен еще объект для выборки данных, а через него уже управлять использованием индесов при выборке, навигации и блокировок.

S>> Наличие индексов позволяет одновременно выполнять запросы к тем областям екстента, где нет эксклюзивных блокировок.
S> Вот ты сразу о переборе.
Да не я сразу о перебеоре! Я тебя с самого начала попросил предоставить план выполнения запроса. Ты предложил прямой перебор. Предложи другой план. Только не начиная про "объект, управляющий использованием индексов". Какие индексы ты будешь использовать?
S>В задаче не было о них ничего сказано, да и оптимзатор должен пройтись перебором если записях Amount<100 будет больше чем половина. Или я не прав????
Почему — прав. Только во-первых ему для этого нужно знать, сколько записей где Amount()<100 еще до начала выполнения запроса.
S>А так я только за индексы.
Замечательно. А как насчет второго предиката? Какой индекс будет использоваться в случае ISecuredObject.AllowsAccess((Context.User as Employee).Manager)? Что будет ключом?

Здравствуйте, Sinclair, Вы писали:


S>> Ну я думаю что оптимизатор еще не дошел "строить совсем другой алгоритм", то либо ручками либо в лоб.
S>Вот приведи мне пример "ручками"
S>> Хорошо пусть будет метод, но выборку с учетом индекса тоже можно делать абсолютно не вникая в тонкости. Что в общем то и делаю, но на объектном уровне. Все те же подходы.
S>Как интересно. А что ты используешь в качестве ключа такого индекса? Как ты определяешь момент, когда ключ изменился?
Ну вот тебе простой пример, мне нужно сделать выборку по Amount, в навигационном объекте все данные об индексах таблицы есть и если есть индекс соответствующий данному свойству то наложить Range не проблема. А вот если такого индекса нет то вперед с песней и перебором.
Ситуация другая когда Amount вычисляет значения из связанного с данным объектом поля другого объекта при чем данный объект может быть различных типов, а может еще быть и третьим четвертым в цепочке связей. Ответ только перебором. Причем таких ситуаций не так уж и мало.
Но зато КАКАЯ Гибкость.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:


S>> А вот тесты на памяти дают 4 кратное превосходство Хэш таблиц над Б+ деревьями.
M>Ну ты пойми, что в реальных системах никогда у тебя не бует такого счастья, как все в памяти.
Согласен, но сколько в реальных системах используется память???
Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением. И зачем нужны тогда 64 битные процессоры???

Здравствуйте, Serginio1, Вы писали:

S> Согласен, но сколько в реальных системах используется память???
На 100%.
Например, в загруженных блокировочниках в принципе не самая большая редкость, когда больше 40% памяти отводится только под блокировки.

S>Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением.
S>И зачем нужны тогда 64 битные процессоры???
Кеш и массив мало связаны, и не смотря на все потуги, дотянуть производительность дисковой памяти до ОЗУ, пока даже близко не удается.

Здравствуйте, Sinclair, Вы писали:

S> В ОДБМС, напротив, полагают, что запросы типа id<5 делатья будут редко (если вообще их разрешили), а самые частые — это траверсинг, т.е. вытаскивание 1 объекта по его ID.
То есть, там тот самый .Amount()>100 в принципе не предполагается? Или я чего-то не допонял?

S> Так что в теории вроде сходится. Versant раньше использовал хеши для oid, не знаю что с ними сейчас.
Все равно, в случаях, когда напрямую в память хеш/хеши не влезают, а как правило в БД так и есть, выгоднее использовать Б-деревья даже для точечного доступа.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:


S>> Все зависит от условий. Опять же я Хэш таблицу поднял только для использования группирования данных путем хранения в ней Key, Value что соответствуе клястерному инддексу.
M>Бррр... Уж для группирования-то хешь зачем использовать? Какой Key-Value, и причем здесь кластерный индекс?

Пример
Select Fld1,Fld2,Fld3, Sum(Fld4),Sum(Fld5),Sum(Fld6)
From XYI
Group By Fld1,Fld2,Fld3

По сути Fld1,Fld2,Fld3 это Key
Sum(Fld4),Sum(Fld5),Sum(Fld6) это Value.

Испльзование хэш таблицы даст больший выигрыш ввиде
Хэш, Key, Value

S>> Не совсем понял
M>Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков.
За счет блокировки диапозона ????
S>>Но поторюсь Хэш таблицы вылезли при обсуждении использовании их при группировании данных.
M>Да я вообще не понимаю куда ты хеши впихнуть хочешь. Не смотря на пулеметную скорость, в БД задачах индексы на хеш таблицах использовать не выгодно.
M>Это может быть выгодно, только в некоторых, довольно редких случаях, при джойнах, и это умеют делать все БД. Если оптимизатор посчитает, что для джойна выгоднее использовать хешь, то сервер его и использует, но держать постоянный хешь индекс смысла не имеет.

Ага
Select * From Doc,Tovar Where Doc.TovarID=Tovar.ID
очень редкий случай?????
Считай все, что основано на соединении по ключу.
Пример Справочник товаров в зависимости от предприятия ассортимент ограничен для кого это 1000 а для кого и 100 000. При этом использовать диапозон этих ключей представляется маловероятным.
Да и бог с ними с Хэшами. Проектировщики БД сами с усами. Но можно найти много ситуаций где выгодно их применять.

К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> Согласен, но сколько в реальных системах используется память???
M>На 100%.
M>Например, в загруженных блокировочниках в принципе не самая большая редкость, когда больше 40% памяти отводится только под блокировки.

Во во и я о том же. Все равно как не крути память хотят пожрать все, но используется только часто используемая. Все таки интересно посмотреть когда 64 разрядную Win 2003 сделают под Athlon 64, и когда будет возможен запас по памяти.
S>>Тот же Raid массив прежде всего выгоден за счет огромного Кэша с упреждающим чтением.
S>>И зачем нужны тогда 64 битные процессоры???
M>Кеш и массив мало связаны, и не смотря на все потуги, дотянуть производительность дисковой памяти до ОЗУ, пока даже близко не удается.
Но всеже это уже не не напряги как раньше с диском. А насчет Кэша и массив то покупаешь память и прикручиваешь к раидам сколько купишь столько и будет кэш у каждого диска. Сам не проверял но соседи в восторге.

Здравствуйте, Serginio1, Вы писали:

S> Но всеже это уже не не напряги как раньше с диском.
Не те, но порядок тот же...

Здравствуйте, Serginio1, Вы писали:

S> Испльзование хэш таблицы даст больший выигрыш ввиде
S> Хэш, Key, Value
Так в этом случае еще больший выигрыш даст indexed (materialized) view, что обычно и делается.

M>>Еще раз. B tree сортирован, хеш — нет. сортировка позволяет снизить вероятность дедлоков.
S> За счет блокировки диапозона ????
Нет конечно.. За счет того что разные параллельные запросы использующие один и тот же индекс, гарантировано будут перебирать записи в одном и том же порядке.

S>Select * From Doc,Tovar Where Doc.TovarID=Tovar.ID
S> очень редкий случай?????
S> Считай все, что основано на соединении по ключу.
Так вот по такому запросу я сразу не скажу что выгоднее хэш джоин, merge или loop.
Сильно зависит от селективности и количества записей удовлетворяющих предикату в обеих таблицах.

S> Проектировщики БД сами с усами. Но можно найти много ситуаций где выгодно их применять.
Ну так об чем и речь, что там где выгодно — они и применяются, но таких мест очень мало. И это уж ни как не прямые индексы к таблице.
К тому же еще такой момент. Ты писал, что это аналог кластерного индекса по PK, так вот кластерный индекс по PK в большинстве случаев далеко не самый оптимальный вариант.

S> К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго.
Ну вот ты опять про своего клиента. Все на одной машине, одна система делает, причем во время перестроения куба OLTP нагрузка отсуствует как класс.
Это не долго — это нормально.

Здравствуйте, Merle, Вы писали:


S>> К стати по вопросу по Кубам и времени их заполнении у Вас не было перфоманса о лимитируещем звене. Или его построение велось с клиента. Уж ооочень долго.
M>Ну вот ты опять про своего клиента. Все на одной машине, одна система делает, причем во время перестроения куба OLTP нагрузка отсуствует как класс.
M>Это не долго — это нормально.

Это нормально было лет 10 назад. А 10 лет назад вычислялся наверное 70 часов????
Ненормально это. И когда зарплата начисляется около часа в монопольном режиме. Итд. Наверное я отстал от жизни.

Здравствуйте, Merle, Вы писали:

>Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на >64 разрядный Intel, и подобный переход довольно серьезно влияет на относительно >высокоуровневые алгоритмы. У Oracle есть нехилый опыт написания под под подобную >архитектуру на спарках, чего не скажешь про MS и даже, как говорят, про команду >разработчиков DB2 UDB (хотя по идее уж IBM'ерам-то опыта не занимать).

Аргументы по поводу проблем IBM и MS в 64-и bit???

Здравствуйте, Merle, Вы писали:


M>Дело в том, что сейчас все прогрессивное человечество, в едином порыве, переползает на 64 разрядный Intel
хм помоему быстрее на Athlon 64 переползут.

Здравствуйте, Serginio1, Вы писали:

S> хм помоему быстрее на Athlon 64 переползут.
Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи.
Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..

Здравствуйте, Аноним, Вы писали:

А>Аргументы по поводу проблем IBM и MS в 64-и bit???
А каке нужны аргументы?
Ты хочешь сказать, что с оптимизировать систему под другую архитектуру — нефиг делать и особого опыта не нужно?
У MS с таким опытом вообще все грустно, слава богу, что 64bit сиквел себя очень не плохо показал, но этого явно недостаточно и там есть еще чег подкручивать. У IBM'еров UDB разрабатывает совершенно отдельная команда, у которой опыта работы на таких системах тоже не дофига. Но надо признать, что они молодцы, поскольку на тех же tpc-с тестах DB2 смотрится получше Оракла.
(см. 4 и 5 места Non-Clustered TPC-C by Performance)

Здравствуйте, Merle, Вы писали:

M>Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи.
M>Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..

Да не, зря ты так. О нем от производителей больших железок очень хорошие отзывы. Sun уже даже анонсировал линейку серверов на них (кто знает, может со временем спарки и уйдут на пенсию).

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Аноним, Вы писали:

А>>Аргументы по поводу проблем IBM и MS в 64-и bit???
M>А каке нужны аргументы?
M>Ты хочешь сказать, что с оптимизировать систему под другую архитектуру — нефиг делать и особого опыта не нужно?
M>У MS с таким опытом вообще все грустно, слава богу, что 64bit сиквел себя очень не плохо показал, но этого явно недостаточно и там есть еще чег подкручивать. У IBM'еров UDB разрабатывает совершенно отдельная команда, у которой опыта работы на таких системах тоже не дофига. Но надо признать, что они молодцы, поскольку на тех же tpc-с тестах DB2 смотрится получше Оракла.
M>(см. 4 и 5 места Non-Clustered TPC-C by Performance)

Ну разрабатывает другая команда и что из этого DB2 LUW (Linux, UNIX, Windows)
наименее конcерванивная из всех DB2 (400,390,LUW,VSE/VM)
Сколько считается дофига заниматься разработкой 64-bit??? 5 лет недостаточно???
И опять же ты ничего не сказал про проблемы. Только про свои ощущения.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Serginio1, Вы писали:

S>> хм помоему быстрее на Athlon 64 переползут.
M>Чего-то я не видел 64 процессорных серверов на атлоне, а на итаниуме их как грязи.
M>Пока за Атлон серьезные производители серверов, типа HP, Unisys, ect., не возьмутся то и говорить не о чем..

НР точно будет выпускать серверы ProLiant с процессорами AMD Opteron
http://www.amdnow.ru/news/archive.shtml?category=1&amp;view=1-04

Сервер IBM eServer 325 на базе AMD Opteron с установленной Oracle 8i позволил повысить производительность weather.com и совершить быстрый и переход на новую платформу без переписывания программного обеспечения.

Компания DaimlerChrysler AG установила новый кластер на базе процессоров AMD Opteron в Техноцентре "Мерседес-Бенц" в Германии

Fujitsu Siemens представляет рабочую cтанцию на базе Opteron

Sun: AMD64 – убийца Itanium


Популярный английский тематический интернет-журнал Computing опубликовал в четверг интервью со Скоттом Макнили (Scott McNealy), председателем совета директоров и исполнительным директором Sun Microsystems, Inc. В числе других вопросов, само собой, были обсуждены и некоторые аспекты касательно созданного недавно союза Sun и AMD.

Директор Sun лишний раз подтвердил, что его компания будет активно использовать Opteron в своих двух-, четырех- и восьмипроцессорных системах, а также упомянул некий «новый многозадачный чип», появление которого планируется уже в следующем квартале. Он рассчитывает достигнуть взаимовыгодного соглашения с AMD, поскольку версия Solaris (разрабатываемая Sun операционная система) для процессоров Xeon удачно портировалась на Opteron без каких-либо значительных изменений. По словам главы нового союзника AMD, компания сделала выбор в пользу Opteron, оставив без внимания Itanium, т.к. его время ушло – «Itanium – архитектура ушедшего тысячелетия». Дело в том, что 64-х битная архитектура Intel требует значительных изменений в коде программ, в особенности, операционных систем – что связано с большими затратами на изменение исходников, перекомпиляцию и сертификацию новой версии ОС. Одним словом, позицию Скотта Макнилли можно охарактеризовать его высказыванием «AMD64 – убийца Itanium».

Здравствуйте, Аноним, Вы писали:

А>Сколько считается дофига заниматься разработкой 64-bit??? 5 лет недостаточно???
Они что, под 64bit все 5 лет разрабатывали? Нет конечно.
Насколько я знаю команду UDB мариновали вместе с разработчиками DB2 под майнфреймы около 2х лет, а потом отправили под обычные интелы 32бит разрабатывать, чем они и занимались.

А>И опять же ты ничего не сказал про проблемы. Только про свои ощущения.
Ну например эффективный алгоритм сканирования индексов совсем другой...
Я не являюсь экспертом в разработке низкоуровневых алгоритмов зависящих от разрядности процессора и поэтому могу всказывать только свои ощущения. О чем я собственно и написал.