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

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 не уважаешь???"

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