Oracle10g на Линухе - быстрее всех!

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 21:00

P.S.
Может кто нибудь объяснит мне чайнику почему такой прогресс в частоте процессора а на рынке нет массивнопарралельных систем ?
Ведь погрессв частотевсеравно ограничен закономи пироды
Но законы природы никак неограничивают число процессоров

vc · Post by vc » 04 Mar 2004 21:07

Dmitry67 wrote:И что же будет с двумя таблицами A и a ?

Their names will become case-insesitive, right ? ... whilst the column collation will remain the same as before the 'alter'.

Dmitry67 wrote:А что кстати говорит стандарт о case-sensitivity имен колонок (не таблиц) и данных ?

Every SQL laguage element (including table/column names) should be case-insensitive.

Data case-sensitivity is determined by the collation so I believe, here, SS2K is compliant. In other words, it should be up to the customer what collation to chose.

VC

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 21:08

tengiz wrote:Иногда полученная скорость оказывалась недостатком. Например, когда я сдавал одну свою работу воякам, толстый полковник оказался недоволен - "Ну что такое, эта фигня такую сложную задачу решает, она не должна так быстро ответ давать. Иначе, кто поверит, что задача на самом деле сложная?" В итоге, как в дурной комедии, пришлось искусственно добавить задержку и глубокомысленные "попискивания" по ходу дела. Работу после этого приняли на "ура".

Боюсь что Вашу идею приняли на ура в фирме где Вы сейчас работаете

У меня комп тоже делает задержку,,, и очень глубокомысленную

flip_flop · Post by **flip_flop** » 04 Mar 2004 21:14

tengiz wrote:
Dmitry67 wrote:В частности приходило в голову что 99% времени приходитя на крошечный самый самый вложенный цикл который можно запогрммировать в таком железном виде и все будет просто летать

Давным-давно это называли спецпроцессором и паяли из логической россыпи.

"Опять классик идею украл" :wink:

Сейчас в FPGA это называется "unroll loops" (what a suprise?!)
Можно подбросить еще пару "классических идей, идущих в головы светлых личностей" :wink:

:
- конвеeрная обработка
- распределенная память
- обмен данных по електрическим соединениям, не через память
- еtc.
Все это доступно в FPGA но народ не торопится.
Еше одна идея - язык программирования надо делать подходящим для систем, извлекающих выгоду от возможности паралелизации (может имеется уже?). Матлаб подходит как исконно векторный язык. Может какая-та надстройка над C++?

tengiz · Post by **tengiz** » 04 Mar 2004 21:16

Dmitry67 wrote:А есть ли увас там ребята которые занимаются подобными вещами, то есть удаленными от внедреия мжет на десятки лет?

MSR.

tengiz · Post by **tengiz** » 04 Mar 2004 21:18

Dmitry67 wrote:...почему такой прогресс в частоте процессора а на рынке нет массивнопарралельных систем ? Ведь погрессв частотевсеравно ограничен закономи пироды. Но законы природы никак неограничивают число процессоров

Массово-параллельные вычисления очень даже используются. Но для настоящих массово-параллельных задач, в основном это обработка сигналов - во всяком случае это одно из важнейших направлений использования узкоспециализированных MP систем. Например, многомерная цифровая фильтрация, фазированые антенные решётки, обраружение и классифиакция, адаптивная цифровые методы и пр. "Обычные" бизнес-задачи плохо поддаются "массовой параллелизации". Во всяком случае пока это именно так. А до тех пор пока это так, деньги от "обычного" бизнеса в эту область рекой не потекут. А если нет денег, то и впечатляющего прогресса тоже не будет. Пока кому нибудь не придёт в голову очередная идея века.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 21:21

Пжалуй Вы правы
А генерация реалистичных изображений в реальном времени с эмуляцией там воды дыма и пр ?

flip_flop · Post by **flip_flop** » 04 Mar 2004 21:30

Dmitry67 wrote:P.S.
Может кто нибудь объяснит мне чайнику почему такой прогресс в частоте процессора а на рынке нет массивнопарралельных систем ?
Ведь погрессв частотевсеравно ограничен закономи пироды
Но законы природы никак неограничивают число процессоров

Попытаюсь ответить навскидку
1. Проектировние Фон-Неймановских систем имеет более 50 лет эволюции, тогда как "переконфигурируемые вычислительные системы" находятся в детском возрасте
2. Требуется четко идентифицировать области предпочтительного применения таких систем (e.g. DSP)
3. Требуетса смена парадигмы, критическая масса специалистов в индустрии и академии
4. Алгоритмы должны быть настроены на параллельную обработку
5. Программирование для паралельных систем не такая тривиальная вещь как обычное программирование :wink:

zVlad · Post by **zVlad** » 04 Mar 2004 21:33

tengiz wrote:
zVlad wrote:On my question:

"...why don't change it to case sensitive? Like we have in DB2."

our SQL Server guy answered:

"...will be performance hit to the database. using UCase(..) will force SQL Server to scan the table rather than utilizing indexes. and more problem with table joins."

zVlad, по этим обрывкам информации непонятно вообще в чём была исходная проблема. Переход на case insensitive, напротив, немного поднимет производительность, .......

You mean "case sensitive", don't you?

I knew about just one problem: due to case insensetivity on SQL Server site and "case sensetivity" (I disagree with this term applied to this matters, let's discuss it latter) on DB2 site we had and have problems when if something happen in DB2, say, DELETE using value which has two presentations, for example: Fee2, and FEE2 then DB2 hadles those values as two different values, while SQL Server doesn't. As a result, replicated table doesn't match to source table.
This problem could be fixed be making SQL Server set up to case sensitive mode. Our guy says there are applications which rely on default SQL Server's insensitivity, and in order to produce same reports, as expected, they would have to use functions like Ucase, which will lead to poor performance due to table scan.

About "case sensetivity" in DB2. DB2 is not case depended product at all. DB2 stores and handle character data exactly in that form how those data was sent from application program to DB2 to store them, and DB2 retrieves those data and makes all comparisons without any stupid (you could say wise, which is in this case absolutaly the same shit) assumptions about.

Thanks to heavens, people who made DB2 were wise enough to realize that this is not a database manager's business to handle characters cases, instead, this is an application program's business. DB2 has functions LCASE or LOWER, and UCASE or UPPER, that's all anybody should expect from RDBMS. Period.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 21:43

zVlad
Я понял проблему
Действитеьно если апплиация полагается на case insensitive collation то тогда дело плохо
А кто генерирует операторы delete where ?
с той стороны можно подправить ?

Что касается case-sensitivity То Вы конечно попытались сделать хорошую мну пи плохой игре
Как Вы собираетесь реализовывать accent-insensitivity ? Тут функциями upper не обойдешься
Тут в Европе аксанты очень важны
Вот только недано делал у одной колонки accent-insensitive
Кстати, а Вы в курсе что в режиме accent-insensitive строки
'bœuf' и 'boeuf' должны быть одинаковыми (hint: посчитайте количество букв)

flip_flop · Post by **flip_flop** » 04 Mar 2004 21:50

Dmitry67 wrote:Пжалуй Вы правы
А генерация реалистичных изображений в реальном времени с эмуляцией там воды дыма и пр ?

Это тоже DSP, поетому подходит. Можно еще многое добавить в области обработки видеоизображений - оценку движения, распознавание образов, etc. "Умные" радиоустройства - еще одна ниша. Но это все специализированные системы, не "ширпотреб" типа процессоров общего применения, поэтому панацеи ожидать не следует.

zVlad · Post by **zVlad** » 04 Mar 2004 22:20

Dmitry67 wrote:zVlad
Я понял проблему
Действитеьно если апплиация полагается на case insensitive collation то тогда дело плохо
А кто генерирует операторы delete where ?
с той стороны можно подправить ?

Что касается case-sensitivity То Вы конечно попытались сделать хорошую мну пи плохой игре
Как Вы собираетесь реализовывать accent-insensitivity ? Тут функциями upper не обойдешься
Тут в Европе аксанты очень важны
Вот только недано делал у одной колонки accent-insensitive
Кстати, а Вы в курсе что в режиме accent-insensitive строки
'bœuf' и 'boeuf' должны быть одинаковыми (hint: посчитайте количество букв)

1. Delete ... where, as well as Update where are coming from source database - from DB2, from application runs on DB2. You are right this could be fixed there in that application. Application could translate everything in upper case, but recently we saw that for our client, for example, "WK32p" and WK32P" - are two different values.

2. I would separate datatypes like CHAR (VARCHAR, LONGVARCHAR) and TEXT (in SQL Server) or CLOB in DB2. First one (char) must be code-driven in comparisons, second set could be handled with different rules.

tengiz · Post by **tengiz** » 04 Mar 2004 22:33

zVlad wrote:You mean "case sensitive", don't you?

Нет. Я имел виду в точности то, что написал.

Согласно Вашему описанию затыка - это в чистом виде прикладная проблема, которую создали себе на голову те, кто проектировал Вашу систему. Ваши рассуждения о том что хорошо, что плохо и что такое мудрость я вообще не понял. У меня закрадывается смутное подозрение, что мы с Вами обитаем в параллельных мирах и никак не можем доровориться о том, что же такое case/accent sensitivity, что такое collation/sort order и почему гибкость в этих вещах так важна для современных DBMS, которые претендуют на то, чтобы быть пригодными для любого языка и любой культуры.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 22:43

zVlad wrote: 2. I would separate datatypes like CHAR (VARCHAR, LONGVARCHAR) and TEXT (in SQL Server) or CLOB in DB2. First one (char) must be code-driven in comparisons, second set could be handled with different rules.

Ничего не понял
Мы говорим о строковых типах (n)CHAR,(n)VARCHAR,(n)TEXT
Я не знаю есть ли в DB2 но в SQL есть два типа
TEXT и IMAGE
То есть для строковых и бинарны типов
Разница жк между TEXT и CHAR только количественная и связаа с неспособностью базы быстро обрабатываь длинные типы
Но это тоже строка

Теперь что Вы поимает под code-driven ?
Это с collation или нет ?

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 22:55

вот для Вас
Почитать чтобы не хтелосьтакого делаь самому

Explain all the essential rules so that if you're trying to build your own collation (e.g. for IBM DB2) you'll understand what actually goes on with the dictionaries and/or the telephone books;

http://www.dbazine.com/gulutzen1a.html

ну а теперь перейдем к интерсным вопросамтипа width-insensitivty и kana-insensitivity

sp123 · Post by **sp123** » 05 Mar 2004 02:39

Dmitry67 wrote:вот для Вас
Почитать чтобы не хтелосьтакого делаь самому

Explain all the essential rules so that if you're trying to build your own collation (e.g. for IBM DB2) you'll understand what actually goes on with the dictionaries and/or the telephone books;

http://www.dbazine.com/gulutzen1a.html

ну а теперь перейдем к интерсным вопросамтипа width-insensitivty и kana-insensitivity

Забавно... IMHO, затолкать алгоритм приведения всех вариаций слова к какому-то онозначному варианту, наверное, можно, хоть и геморрой. Мне интересно, как потом заставить это быстро работать... В Oracle понятно, а в DB2? Вроде funcion-based индексы там не практикуются?

zVlad · Post by **zVlad** » 05 Mar 2004 03:04

tengiz wrote:
zVlad wrote:You mean "case sensitive", don't you?

Нет. Я имел виду в точности то, что написал.

Согласно Вашему описанию затыка - это в чистом виде прикладная проблема, которую создали себе на голову те, кто проектировал Вашу систему. Ваши рассуждения о том что хорошо, что плохо и что такое мудрость я вообще не понял. У меня закрадывается смутное подозрение, что мы с Вами обитаем в параллельных мирах и никак не можем доровориться о том, что же такое case/accent sensitivity, что такое collation/sort order и почему гибкость в этих вещах так важна для современных DBMS, которые претендуют на то, чтобы быть пригодными для любого языка и любой культуры.

С первым Вашим утверждением я абсолютно согласен. Да наш вендор незаморачивается ничем кроме своих проблем - для него наша репликация - тьфу: ваши проблемы. Я тут писал как этот вендор реагирует на вопрос о кодовой странице: видно без микроскопа, что у него используется кодовая страница 1047 (совместимая с Open system так сказать), но он бьет себя кулаком в грудь и кричит: 37-АЯ КОДОВАЯ СТРАНИЦА У НАС.

Насчет что такое хорошо и тд - ну не умею я доносить мысль на английском, а русской клавы на работе нет. Хотя дело видимо не в клаве. Вот Вы когда-нибудь задумывались на вопрос почему в DB2 скажем нет flash-back или разные режимы чувствительности к верхнему-нижнему регистру? Вы может быть думаете, что у ИБМ нет гениальных (как в Микрософте) девелоперов или исскустных программеров - поэтому мол и нет. А я думаю, что у ИБМ есть очень мудрые ученые и аналитики, которые прежде чем сказать "гоп" сначала думают потом запрягают лошадь и уж потом едут. Потому в DB2 может и не быть каких-нибудь замысловатых возможностей, от наличия которых в других подобных продуктах у пользователя только изжога появиться может.

Вы абсолютно правы, говоря, что мы обитаем в совершенно разных мирах. В этом объяснение всех наших боданий. Моя главная мысль (если отбросить все рассуждения о мудрости) была в том, что в данном контексте база данных должна сохранять то, что ее просят сохранить, и выполнять операции сравнения так это соответсвует здравому, не затуманеному смыслу - т.е. согласно которому "б" не равен "Б", разве что после трех рюмок. Если же нужны особые правило - делай это через расширения - Extenders.
А вообще интересно было бы узнать, а что в Оракл на этот счет имеется?

tengiz · Post by **tengiz** » 05 Mar 2004 03:04

Dmitry67 wrote:Боюсь что Вашу идею приняли на ура в фирме где Вы сейчас работаете У меня комп тоже делает задержку,,, и очень глубокомысленную

Это не моя идея - копирайт того полковника (уже наверняка давно в отставке в качестве генерала - это было примерно 20 лет назад), не скажу его фамилию, хоть и прекрасно помню - таких забыть трудно: человек с очень нетривиальным чувством юмора. Кроме того, примерно также очаровательно косноязычен как Черномырдин. Жаль, роялти уже поздно ему требовать

zVlad · Post by **zVlad** » 05 Mar 2004 03:16

Dmitry67 wrote:
zVlad wrote: 2. I would separate datatypes like CHAR (VARCHAR, LONGVARCHAR) and TEXT (in SQL Server) or CLOB in DB2. First one (char) must be code-driven in comparisons, second set could be handled with different rules.

Ничего не понял
Мы говорим о строковых типах (n)CHAR,(n)VARCHAR,(n)TEXT
Я не знаю есть ли в DB2 но в SQL есть два типа
TEXT и IMAGE
То есть для строковых и бинарны типов
Разница жк между TEXT и CHAR только количественная и связаа с неспособностью базы быстро обрабатываь длинные типы
Но это тоже строка

Теперь что Вы поимает под code-driven ?
Это с collation или нет ?

Из словаря:

"1. collation n
1. сравнение, сопоставление, сличение (текста)
2. полигр. проверка листов брошюруемой книги
3. колляция, количественная характеристика (в библиотечном деле)
4. пожалование духовному лицу бенефиция
5. лёгкий завтрак или ужин"

Когда я говорю о TEXT (CLOB в DB2) и противопоставляю их CHAR, и VARCHAR я имею в виду не количественную разницу, а именно качественную. То есть в случае CHAR не должно быть никаких акцентов - это коды, произвольные коды, которые могут сравниваться только как бинарные коды, здесь не должно быть замешано знаний типа - некоторые люди считают что "ш" и "Ш" - это одно и тоже, а другие их различают. Вот в типах данных TEXT (CLOB) через Extenders - это выглядит уместо, понятно, и естественно.

P.S. А как насчет символов "и" и "й". Как их сортировать и сравнивать будем. Кстати, давным давно в 1993 мы купили SQL/DS for VM - базу данных ИБМ на VM. Естественно встал вопрос хранения и сортировки киррилицы, так как на тот момент начего кроме киррилицы мы хранить и не собирались. Продукт мы получили напрямую от ИБМ, прочитали руководство, раздел NLS, после чего один из нас написал небольшую программку на Ассемблере (по прилагавшемуся образцу), лично я сделал некоторые изменения в таблицах так называемого каталога. И все проблемы могущие быть связанными с киррилицей были сняты раз и навсегда. Мы могли таблицы, столбцы и любые другие объекты базы называть по-русски. Сортировка работала как надо, несмотря на то что русские буквы в мэйнфрэймовской таблице располагались не в порядке возрастания кодов.

tengiz · Post by **tengiz** » 05 Mar 2004 04:04

zVlad wrote:Вот Вы когда-нибудь задумывались на вопрос почему в DB2 скажем нет flash-back или разные режимы чувствительности к верхнему-нижнему регистру?

Flashback в DB2 нет, потому что нет базового механизма, позволяющего это относительно безболезненно делать. У Oracle такой механизм, как известно, имеется.

Вы может быть думаете, что у ИБМ нет гениальных (как в Микрософте) девелоперов или исскустных программеров - поэтому мол и нет...<skipped/> А я думаю, что у ИБМ есть очень мудрые ученые и аналитики, которые прежде чем сказать "гоп" сначала думают потом запрягают лошадь и уж потом едут...<skipped/>... разве что после трех рюмок.

zVlad, ну что Вас непрерывно тянет на какие-то застольные разговоры, только вместо "ты меня уважаешь?" у Вас каждый раз всё скатывается к "ты что, IBM не уважаешь???"

Ей-Богу я даже в нетрезвом виде стараюсь держаться подальше от таких бесед. Так что прошу прощения - я лучше на технические темы буду стараться высказываться.

verzlo · Post by **verzlo** » 05 Mar 2004 04:47

Вот случайно набрел...
http://cgi.ebay.com/ws/eBayISAPI.dll?Vi ... egory=3773

Надо же.. кто-то покупает небось....

zVlad · Post by **zVlad** » 05 Mar 2004 04:47

tengiz wrote:......
zVlad, ну что Вас непрерывно тянет на какие-то застольные разговоры, только вместо "ты меня уважаешь?" у Вас каждый раз всё скатывается к "ты что, IBM не уважаешь???" Ей-Богу я даже в нетрезвом виде стараюсь держаться подальше от таких бесед. Так что прошу прощения - я лучше на технические темы буду стараться высказываться.

Наверное это от моего рабоче-крестьянского происхожлдения

.
Давно уже замечаю, что наличие разных там фичей в продукте (в данном случае в базах данных), равно как знание их тем кто рядом сидит и называется DBA, не гарантирует успеха бизнеса ради которого эта самая DB и DBA были куплены. Нет конечно, если купить (не буду говорить что) и посадить (не буду говорить кого) то тогда вообще может ничего не получиться. Но в среднем ни сильно навороченных RDBMS ни гениев не надо никому.
Вот возьмите мою контору, вот уже больше двух лет мы время от времени бъемся головой об не чувствительность к регистру символов SQL Server-a, до сего дня мне - тупому DB2 DBA - казалось это SQL Server такую особенность имеет, сегодня оказалось нет, это не особенность - это мощь SQl server-a, и это наши спецы так решили исходя из соображений производительности приложений, которые с другой стороны находятся. Может они и не до конца правы, кто ж их поимет - они по-русски то не говорят. Но я с ними спорить и докапываться не стану.

Так что мне на сегодня очень льстит "упрощенность" DB2 - я по крайне мере знаю (знал и раньше), что в ней нет излишеств, на которых можно погореть, или дураком выглядеть (уж я бы нашего SQL Server специалиста повозил бы рожей по стенке если бы он понимал по-нашему). Уж если не его, то менеджера, который принял решение реплицировать DB2 в SQL Server.

Dmitry67 · Post by **Dmitry67** » 05 Mar 2004 09:23

zVlad wrote:То есть в случае CHAR не должно быть никаких акцентов - это коды, произвольные коды, которые могут сравниваться только как бинарные коды

Да ????
А я то наивный думал что CHAR - это символы
Ладно, забыли про case-sensitivity. Хоть ORDER BY то работать должен ?
Учитывая то только в англ языке алфавит compatible with ASCII. Ну еще по моему в интальянском потому что там букв мало.

Во всех остальных языках сортировка по ASCII неправильна ! Это означает что на всей территории Европы для сортировки нельзя использовать ORDER BY сервера а все эти "stupid' сортировки делать на клиенте. Вот уж действительно "без излишеств". Я бы даже сказал полный аскетизм

Только потом не надо удивляться почему DB2 считают 'чем то старым с mainframe' которое не поспевает за ходом прогресса

Dmitry67 · Post by **Dmitry67** » 05 Mar 2004 09:29

zVlad wrote:1
Моя главная мысль (если отбросить все рассуждения о мудрости) была в том, что в данном контексте база данных должна сохранять то, что ее просят сохранить, и выполнять операции сравнения так это соответсвует здравому, не затуманеному смыслу -
2
т.е. согласно которому "б" не равен "Б", разве что после трех рюмок. Если же нужны особые правило - делай это через расширения - Extenders.

1 В режиме case_insensitive тем не менее сервер сохраняет и воспроизводит данные AS IS, не меняя регистра
Это вам надо сохранять НЕ as is с помощью upper. Кстати как upper работает для русского языка ?

2 Ага. А вы согласны что 'b' < 'c' < 'ç' < 'd' ???
Это я Вам как француз говорю. У нас алфавит такой. И несмотря на то что ç находится в старшей части таблицы ascii, даже после трех рюмок никто не поставит ç после z !

zVlad · Post by **zVlad** » 05 Mar 2004 12:56

Dmitry67 wrote:............

Только потом не надо удивляться почему DB2 считают 'чем то старым с mainframe' которое не поспевает за ходом прогресса

А вот здесь, Дима, я Вас вынужден огорчить.
DB2 считают, как Вы сказали "...'чем то старым с mainframe' ...", только ограниченные люди, которые знаниям предпочитают слухи, распускаемые еще более ограниченными людьми.
Я уже намекал выше о том, что еще в 1993 (до появления SQL Server-a) мы совершенно спокойно, пользуясь руководством по Natuonal Language Support (NLS), обеспечили правильную сортировку и вообще использование киррилицы в SQL/DS (ныне DB2 for VM). И знаете как это делалось в SQL/DS? Нет не знаете. Делалось это путем перекодировки символов перед их сохранением и обратной перекодировки перед возвращением. Делается это естественно на сервере. Сравнения и сортировки осуществляются до обратной перекодировки. С помощью этого механизма можно любой алфавит обеспечить, даже придуманный произвольно. Я не могу Вам рассказать как с этим обстоят дела ныне, думаю что как то обстоят не хуже чем было. А как интересно это сделано в SQL Server?
Уверяю Вас, Дима, Вам станет легче жить если Вы поймете что DB2 - это современная база данных ничем не уступающая базам данных конкурентов ИБМ, и кое в чем даже их превосходящая.