Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
AndreiNz
Member

Откуда:
Сообщений: 471
vadiminfo

Ведь Вы сами придумали, что вам так сказали? Из пропоганды? В пылу так сказать полемического спора?
...


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

Я, вообще, не утверждаю, что знаю Оракл достаточно хорошо, но рядом со мной работают люди, в чьих знаниях я не сомневваюсь.
3 ноя 06, 22:40    [3356203]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Lepsik
Member

Откуда: glubinka
Сообщений: 4257
dmitryn
Вот пришло в рассылке по поводу cache и ibm.
------------------------------------------


делайте ссылки сайт IBM иначе это выглядит как дешевая реклама. Учитывая что сам IBM поэтому поводу ничего не пишет, это еще и ложь.

2SergSuper
---Хотя про InterSystems написано на сайте IBM

это лишь означет что на ихнем линуксе и железе Кэш может крутится, но не более того.
3 ноя 06, 23:29    [3356274]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
AndreiNz
c127


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


Вы знаете, я тоже был очень удивлен, когда мне сказали, что в Оракле надо в каждом запросе указывать, какой индекс использовать. А иначе работать будет через пень колоду. Не хотите ли пройтись по Ораклу?

Оракл тут может быть совсем ни при чем. Вам кто-то что-то сказал об оракле, вот и начните с выяснение соответствует ли сказанное тому, как работает оракл на самом деле.

LittleCat
c127

Читайте пост ###, мне добавить нечего https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=351164&pg=16#3349901

А че там было написано ? А то что-то не видно поста ###, может процитируете ?

Там кроме прочего было сказано примерно, что фраза
kvasov> но это фантазии, а критерий конкурентоспособности реален и прост как тапок - доходы должны превышать расходы

лишена смысла и говорит о том, что ее автор не понимает о чем говорит. Польностью согласен.

Sergei Obrastsov
c127

Как я понимаю М-фанаты иссякли, пару дней назад были хоть какие-то аргументы, теперь пошел откровенный флейм. Потом будут ныть, что они такие хорошие, а их почему-то никто не любит.

M-фанат вообще-то ждет, когда же ему покажут циклы в структуре. Видимо уже не дождется.

Я думал это очевидно, видно у М-фанатов совсем с образованием туго.
Пример. Пусть q1,q2 это преподаватели, s1,s2 это студенты. Ребро (d,f) значит что люди d,f связаны отношением учит-учится.
Граф: множество вершин: {q1,q2,s1,s2}
множество ребер: {(q1,s1),(q1,s2),(q2,s1),(q2,s2)}
ВНИМАНИЕ, ЦИКЛ:
q1-s1-q2-s2-q1

Еще раз предлагаю почитать хоть что-нибудь по графам и деревьям, нельзя же быть таким необразованным. Если Вы вдруг не читатель, а писатель, то не пытайтесь участвовать в профессиональных разговорах, а то станете посмешищем вроде ЧАЛ-а. Но решать Вам разумеется.
4 ноя 06, 00:22    [3356350]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
c127
Я думал это очевидно, видно у М-фанатов совсем с образованием туго.
Пример. Пусть q1,q2 это преподаватели, s1,s2 это студенты. Ребро (d,f) значит что люди d,f связаны отношением учит-учится.
Граф: множество вершин: {q1,q2,s1,s2}
множество ребер: {(q1,s1),(q1,s2),(q2,s1),(q2,s2)}
ВНИМАНИЕ, ЦИКЛ:
q1-s1-q2-s2-q1

 q1 $---------$ q2
    |\        |\
    | \       | \
    $  $      $  $
    s1 s2     s1 s2 

Повторите, пожалуйста, еще раз Вашу методику обхода.
4 ноя 06, 00:56    [3356384]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
AndreiNz

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

Ваша фраза
AndreiNz

что в Оракле надо в каждом запросе указывать, какой индекс использовать. А иначе работать будет через пень колоду.

Не соответствует действительности. На самом деле не надо, а есть возможность указать если надо. Большая разница. Впрочем, уже типа пытался это пояснять.

AndreiNz

То что я написал делается на самом деле.

Где? Кем делается? Фамилии у них есть? Я знаю, что многие не в курсах про хинты, хотя пишут запросы для отчетов цельными днями. Вы еще с Вашими хинтами попробуйте превзойти оптимизатор в каждом запросе. А я посмотрю.

AndreiNz

А вот ваш ответ наводит на мысль, что с Ораклом вы знакомы только по книжкам.

Мне показалось, что Вы и не читали смысла ответа.


AndreiNz

Я, вообще, не утверждаю, что знаю Оракл достаточно хорошо,

Этого могли и не говорить. Зачем тада хотели пройтись по нему? Думали, легкая прогулка будет? Он самый удобный для антипропаганды? Ну еще бы. Всякая СУБД, на самом деле, круче его. Любой парень легко докажет, что у него СУБД лучше, не зная достаточно хорошо Оракла. А если лучше него, то лучше всех. Оракл ить среди лидирующих. А так трать время на каждую мелкую СУБД. А тут один шаг в лидеры. Мечта любого адепта.

AndreiNz

но рядом со мной работают люди, в чьих знаниях я не сомневваюсь.

Возможно, сомнения всегда полезны. Даже Вам.
4 ноя 06, 00:57    [3356386]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
c127
Там кроме прочего было сказано примерно, что фраза
kvasov> но это фантазии, а критерий конкурентоспособности реален и прост как тапок - доходы должны превышать расходы

лишена смысла и говорит о том, что ее автор не понимает о чем говорит. Польностью согласен.


ну не знаю, мне этот момент понравился вот в этой книжке
http://www.duel.ru/publish/parshev/why2.htm

но раз уж Вы лучше "в материале" (ну а почему нет?), может скажете тогда свою точку зрения, а конкурентоспособность - это что?
4 ноя 06, 01:17    [3356401]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Значицца так, предлагаю вопрос с оракловым оптимизатором закрыть вот на чем:

1. В других реляционных СУБД (например DB2) оптимизатор реализован более удачно (самообучающийся). Поэтому какой бы кривой оптимизатор ни был в Оракле это не значит что он кривой во всех реляционных СУБД и не свидетельствует о недостатках реляционных СУБД в целом.

2. В Оракле можно продиктовать план запроса хинтом. Строго говоря это - нарушение декларируемого в реляционных СУБД принципа разделения физической структуры от логической. На практике - простой и удобный способ тюнинга запросов, не свободный притом от недостатков. Например переименовали индекс - трогайте запросы, меняйте хинты :)

3. Существуют более "правильные" с точки зрения теории способы добиться от Оракла приемлемых планов:
- регулярно собирать статистику и строить гистограммы (не 100%, но 98% канает)
- продиктовать планы ораклу с помощью stored outlines, которые лежат отдельно от исходников запросов.

В общем Реляционная СУБД - это как компилятор с языка С. Позволяет в 10 раз быстрее написать и отладить код чем на ассемблере, причем критические по производительности участки кода (это в среднем 2-10% кода) можно и не ассемблере написать.

А в мампсах надыть усе писать на ассемблере, от начала и до конца. Поэтому мампсы маст дай для 98% проектов. Я лично не вижу сколько-нибудь существенной ниши на рынке для мампсов. Если реляционная СУБД хреново справляется (и из нее уже выжато все что можно) - дешевле поставить железяку поблатнее. Уперлись в ввод-вывод - воткнуть побольше каналов ввода-вывода, добавить дисков и раскидать по ним данные "шоб в параллель". Ну или добавить процессоров или оперативной памяти если уперлись в них, что бывает реже. Переписывать же софт с языка высокого уровня (SQL) на язык низкого уровня (мампсы) из-за проблем с производительностью - это идиотизм. Поддержка такой системы будет стоить нереальных денег, потому что невозможно найти людей которые будут ее поддерживать. Плюс завтра объемы данных подрастут и более блатную железяку придется покупать полюбому.

А для 2% проектов с "нереальными требованиями" существуют специально заточенные под обработку неперянного числа примитивных и единообразных транзакций мэйнфреймовые системы. До этих систем и мампсам и реляционным СУБД как до луны. Но это - дорогущие узкоспециальные системы.
4 ноя 06, 02:08    [3356431]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
AndreiNz
Member

Откуда:
Сообщений: 471
vadiminfo,

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

Фамилии хотите, а что вам дадут фамилии новозеланцев? Скажу только, что один из них разработал несколько продуктов для нашей фирмы и эти продукты успешно работают в таких странах, как Австралия и Канада, причем в довольно ответственных (в смысле человеческих жизней) отраслях, а не просто денюжки из одного банка в другой перекачиают. Другой работал в Лондоне на Всемирный Банк и Шел, причем работал контрактором и именно на Оракле. У него не возникло никакаих возражений или вопросов по поводу хинтов, когда он пришел в нашу компанию. Третий пишет статьи для Борланда (когда он еще существовал), этого вы, наверное, сможете вычислить.

Так что, у этих людей достаточный опыт, чтобы ему доверять.
4 ноя 06, 07:35    [3356506]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
###
Member

Откуда: Курумоч
Сообщений: 658
kvasov
ну не знаю, мне этот момент понравился вот в этой книжке
http://www.duel.ru/publish/parshev/why2.htm
Вы всерьез об "этом"? Лучше дамский роман почитайте...
kvasov
но раз уж Вы лучше "в материале" (ну а почему нет?), может скажете тогда свою точку зрения, а конкурентоспособность - это что?
Думаю, что это выходит за рамки обсуждаемой темы...
4 ноя 06, 08:06    [3356512]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
Sergei Obrastsov
Повторите, пожалуйста, еще раз Вашу методику обхода.

Одним из любопытных следствий Вашего опровержения является то, что Вы только что доказали планарность графа K33. Как Вам наверное известно, это крупное научное достижение :)
4 ноя 06, 12:27    [3356650]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kvasov
Member [заблокирован]

Откуда:
Сообщений: 853
###
Думаю, что это выходит за рамки обсуждаемой темы...


Ну и ладно, если речь о рассказах про "это", то видимо желательно конечно воздержаться.
4 ноя 06, 13:20    [3356695]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Зл0й

1. В других реляционных СУБД (например DB2) оптимизатор реализован более удачно (самообучающийся). Поэтому какой бы кривой оптимизатор ни был в Оракле.

Если есть ссылка, где это реально подтверждается, то, плиз, киньте. Какое там самообучение - с учителем, без такового, какой алгоритм обучения? С явным представлением знаний, без такового. Желательно, чтобы там было сравнение и количества самих алгоритмов в этих СУБД. Это полезная инфа.
И зафикирована ли где-то кривизна? Там радиус кривизны и все такое.

Зл0й

В Оракле можно продиктовать план запроса хинтом. Строго говоря это - нарушение декларируемого в реляционных СУБД принципа разделения физической структуры от логической.

Это слишком строго. Наверняка и в других СУБД иногда приходится переделывать сам запрос ради производительности, т.е. ради физического уровня переделывать логику. И разделение то есть - просто эти уровни влиют друг на друга - недостаток. А вот када таблы приходится структуприровать под производительность, то другое дело - то структура. Но мире нет совершнства.
Но если Вы и перепишите запрос, а план окажется все равно не тот, хотя нужные алгоритмы в СУБД есть, то хинт и не помешает. Ведь, к примеру, может оказаться несколько равноценных планов, а вам нужен только один. Есть два индекса - в одних запросах нужен один, в других другой, а данный запрос абсолютно симметричен с точки зрения выбора индекса (точнее пути), но выбрать он может только один. И он выбирает не тот. Я писал про старые и свежие данные. Откуда он знает что вам нужны свежие? Ну Вы ему и скажете с помощью хинтов.

Зл0й

Существуют более "правильные" с точки зрения теории способы добиться от Оракла приемлемых планов:
...(не 100%, но 98% канает)

Вот именно, что существуют различные средства. И вот именно, что 2% остается на сложные случаи, где все средства хороши. Более того, бывают разные обстоятельства когда, нужны просто ручки, чтобы по быстрому подкрутить. Не всегда связанные с "кривизной" оптимизатора, а, например, с "кривизной" решений.

AndreiNz

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

Вот я и говорю Вам, что одного желания показать мало. Если и есть проблемы, то Вы их не показали. В сложном запросе Вам с Вашими хинтами, превзойти оптимизатор врядли удастся. Он поумнее нас с Вас вместе взятых будет.
А Вы писали, что в любом запросе их надо писать. Еще раз - много проггеров, пишуших запросы про них не знает, и запросы отрабатыет с требуемой по ТЗ поизводительностью. Трудности с запросами возникают редко. По моему Том Кайт где-то писал, что таких тяжелых запросов на приложение достаточно мало.
У нашей фирмы несколько проектов. Одна из моих обязанностей - задачи оптимизации запросов, когда проггерам не удается добиться требуемой производительности. За три года таких случаев всего четыре. Из них только в в двух пришлось прибегнуть к хинтам. Причем в одном как временное решение, пока не перепроектировали с использованием секционирования. А запросов в каждом проекте несколько десятков.
Поэтому, найденный Вами недостаток, кажется, слишком надуманным.
Рекомендую глубже копать, если хотите что-то показать, чтобы потянуло на статью в каком-нибудь журнале - мол у лидирующей СУБД недостаток существенный нашел.

AndreiNz

Фамилии хотите, а что вам дадут фамилии новозеланцев?

Фамилии новозеланцев не дадут решительно ничего в плане убедительности, обнаруженного Вами, недостатка. Этого мало. Нужны фамилии американцев или европейских ученых от компьютерных наук. Все таки Вы ищите проблемы у лидеров среди СУБД, не в Новой Зеландии социальную оценку оных собираете.
4 ноя 06, 13:28    [3356705]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
softwarer
Sergei Obrastsov
Повторите, пожалуйста, еще раз Вашу методику обхода.

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

Это не граф K33. Еще раз напомню структуру:
P(преподаватель,студент)=
S(студент,преподаватель)=

Итого, у нас 2 массива. Это два дерева, а не одно. Графы? Пожалуйста.
Все то же самое, что я и приводил:

  структура "P"               структура "S"

p1 $-------$ p2           s1 $---------$ s2
   |\      |\                |\        |\
   | \     | \               | \       | \
   $  $    $  $              $  $      $  $
  s1  s2  s1  s2             p1  p2    p1  p2

Напомню определение дерева:
Деревом называется произвольный связный граф без циклов.

Будете упражняться в остроумии дальше?
4 ноя 06, 14:16    [3356776]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Sergei Obrastsov

Все то же самое, что я и приводил:


  структура "P"               структура "S"

p1 $-------$ p2           s1 $---------$ s2
   |\      |\                |\        |\
   | \     | \               | \       | \
   $  $    $  $              $  $      $  $
  s1  s2  s1  s2             p1  p2    p1  p2

Напомню определение дерева:
Деревом называется произвольный связный граф без циклов.


Поясните, плиз, зачем Вы по два раза нарисовали в внизу в одном случае s1 и s2, во втором p1 и p2 в связи с упоминанием о деревьях? Ожидается, что последние как минимум ориентированные графы, и потомок имеет не более одного предка. Ну и так по мелочам. Наприер, существует только один узел, который не имеет предков.
Почему нельзя перерисовать, напрмер, так:

p1 $----$ p2           
   |\    /           
   |   /   | 
   $ /   \ $     
   s1       s2  
Тогда это, скорее всего, не дерево (более одного предка). Или, на самом деле все же это разные s1 и s2 у p1 и у p2? Ведь, множества в математике не содержат дублей, и в частности множество узлов.
4 ноя 06, 15:41    [3356899]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Как всегда трусость и жалость к себе недоучек "реляционщиков" берет верх в их собственном сознании над простым человеческим желанием чему-то научиться. Я этих "оппонентов" уже хорошо изучил. А некоторые интеллектуалы еще надеятся, что к их соображениям кто-то сможет прислушаться. Не смогут, даже если захотят.
Ведь с какой завидной настоичивостью все с ног на голову переворачивают. Хорошо известно, что "Р"СУБД приводят к постоянному программированию любых, даже самых элементарных "запросов" (а, как теперь выясняется, еще и к командировкам для "вставки хинтов"). Это неизлечимый недостаток приложений на "Р"СУБД, лишенных, "благодаря" РМД, идентификации, навигации и семантики данных. Даже 2% приложений, для которых было бы разумно использовать "Р"СУБД, найти не удастся. Собственно, никому так и не удолось привести хотя бы один пример типового приложения, для которого "Р"СУБД были бы эффективнее, чем ОСУБД на MUMPS, при использовании которых и прикладное программирование, и сопровождение сведены к минимуму.
4 ноя 06, 15:59    [3356922]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
лучше бы помолчал, не-товарищ ЧАЛ.
В Оракле и других РСУБД хоть хинты есть. А в M - чуть что с "поиском" не так, приходится доп. глобалы вешать, и код писать для их увязки с имеющимися глобалами. Это я вам, заметьте, как программист на М со стажем говорю.

Собственно, я уже среди тех, кто вас (ЧАЛ) игнорирует. Сколько можно словоблудить? Надоело уже.
4 ноя 06, 17:14    [3357057]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Точно, kdv. Вы именно среди тех "специалистов", о которых я сказал. Думаете мне не надоело слушать недоучек и болтунов ?
Вы никакой абсолютно "программист на М", так как не поняли суть MUMPS за весь свой "стаж программирования". Наверное, Вы и на SQL такой же программист. В любой ОСУБД на MUMPS никто для "поиска" никаких глобалов не "вешает", и ни счем их не "увязывает". Действительно, лучше бы помолчали.
4 ноя 06, 17:54    [3357106]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
И учтите, господа "аббревиатуры", я постараюсь не позволять непрофессионалам морочить людям головы, распространяя дезинформацию и/или неправду. И буду всегда выводить вас на чистую воду. Очных семинаров по теории и практике БД вы испугались, заочных тоже - постоянно все перевираете, обводя в прямоугольнички только "нужные" предложения. Что там мои высказывания - Кодда и Дейта с легкостью игнорировали, даже когда понимали о чем речь.
РМД лишила базы данных идентификации, навигации и семантики. При использовании "Р"СУБД (в которых РМД даже не стали реализовывать) приходится постоянно программировать даже самые примитивные "запросы", постоянно программировать даже самые элементарные интерфейсы. РСУБД, даже если бы их удалось создать, никогда бы не достигли той ясности и выразительности, которая всегда была у ОСУБД на MUMPS. А "Р"СУБД, хотят того их разработчики или нет, могут, теоретически, достигнуть качеств ОСУБД на MUMPS, только когда они (разработчики) откажутся полностью (а не частично, как сейчас) от ограничений РМД. При этом, конечно же, не следует отказываться от "алгебр", если они органично дополняют возможности СУБД.
4 ноя 06, 21:15    [3357348]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
mumps-ист
Guest
Чернышев Андрей Леонидович
Собственно, никому так и не удолось привести хотя бы один пример типового приложения, для которого "Р"СУБД были бы эффективнее, чем ОСУБД на MUMPS, при использовании которых и прикладное программирование, и сопровождение сведены к минимуму.


Дайте, пожалуйста, ссылку на ОСУБД на MUMPS (при использовании которых и прикладное программирование, и сопровождение сведены к минимуму), для которой нужно привести пример.
4 ноя 06, 21:16    [3357352]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Я не коммерсант, и не маркетолог, уважаемый (опять) неизвестно кто.
4 ноя 06, 21:20    [3357363]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Чернышев Андрей Леонидович

чем ОСУБД на MUMPS, при использовании которых и прикладное программирование, и сопровождение сведены к минимуму.

Т.е. ЧАЛу еще никого не удалось развести на эту его дореляционную ОМД, вот там и минимальное программирование - никто не программирует. Ну и сопровождать нечего - оно и минимальное. Ну, разве только на Балабановской спичечной фабрике или в Сывтывкаре на откатах, на какие-то компы что-то установили. Минимальное использование -> минимальное программирование и сопровождение.
4 ноя 06, 21:37    [3357387]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Откаты - это прерогатива "сложных приложений" на Oracle. Только они и позволяют впаривать "Р"СУБД, чтобы потом зарабатывать на постоянном программировании каждого нового "запроса". Я уверен, что на "спичечной фабрике vadiminfo" либо MS SQL, либо Oracle. В Сыктывкаре точно Oracle или MS SQL (в крайнем случае обходятся "без СУБД" на 1c/dbf).
4 ноя 06, 21:51    [3357411]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
И прекратите лгать, vadiminfo. Никогда не существовало, и не существует никакой "моей ОМД".
4 ноя 06, 22:07    [3357437]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Чернышев Андрей Леонидович
Member

Откуда:
Сообщений: 257
Потрясающие признания можно услышать от "реляционщиков", когда они начинают говорить о "своем, о наболевшем".

"Нужны фамилии американцев или европейских ученых от компьютерных наук."
Да зачем они нужны. Достаточно "фамилии" vadiminfo. Вот его прямая речь:

"А запросов в каждом проекте несколько десятков."

Предположим у "проекта" всего 100 пользователей. И каждому по его просьбе (сами-то пользователи в приложениях на "Р"СУБД произвольных "запросов" делать не смогут) vadiminfo, мотаясь по командировкам, написал всего по 10 (уникальных, отличающихся от "запросов" других пользователей) "запросов". Плюс "штатные запросы". Больше тысячи, мягко говоря, получается. Трудно себе представить серьезное приложение, где "штатных запросов" несколько десятков, и совсем невозможно представить приложение, где всего несколько десятков "запросов". Но видимо именно такими приложениями и занимается весь мир "реляционных разработчиков".
5 ноя 06, 01:36    [3357630]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
vadiminfo
Зл0й

1. В других реляционных СУБД (например DB2) оптимизатор реализован более удачно (самообучающийся). Поэтому какой бы кривой оптимизатор ни был в Оракле.

Если есть ссылка, где это реально подтверждается, то, плиз, киньте. Какое там самообучение - с учителем, без такового, какой алгоритм обучения? С явным представлением знаний, без такового. Желательно, чтобы там было сравнение и количества самих алгоритмов в этих СУБД. Это полезная инфа.
И зафикирована ли где-то кривизна? Там радиус кривизны и все такое.

Алгоритмы в деталях и подробностях никто не расскажет - это trade secret. В общих чертах почитайте здесь:

http://www.dia.uniroma3.it/~vldbproc/006_019.pdf

vadiminfo
Зл0й

В Оракле можно продиктовать план запроса хинтом. Строго говоря это - нарушение декларируемого в реляционных СУБД принципа разделения физической структуры от логической.

Это слишком строго. Наверняка и в других СУБД иногда приходится переделывать сам запрос ради производительности, т.е. ради физического уровня переделывать логику. И разделение то есть - просто эти уровни влиют друг на друга - недостаток. А вот када таблы приходится структуприровать под производительность, то другое дело - то структура. Но мире нет совершнства.
Но если Вы и перепишите запрос, а план окажется все равно не тот, хотя нужные алгоритмы в СУБД есть, то хинт и не помешает. Ведь, к примеру, может оказаться несколько равноценных планов, а вам нужен только один. Есть два индекса - в одних запросах нужен один, в других другой, а данный запрос абсолютно симметричен с точки зрения выбора индекса (точнее пути), но выбрать он может только один. И он выбирает не тот. Я писал про старые и свежие данные. Откуда он знает что вам нужны свежие? Ну Вы ему и скажете с помощью хинтов.


Строго - это если фундаменталистски следовать теории. На практике обычно ищется некий компромисс. Хинт вкрячить просто, удобно и надежно. Недостаток - появляется лишняя зависимость между логической и физической моделью.

vadiminfo
Зл0й

Существуют более "правильные" с точки зрения теории способы добиться от Оракла приемлемых планов:
...(не 100%, но 98% канает)

Вот именно, что существуют различные средства. И вот именно, что 2% остается на сложные случаи, где все средства хороши. Более того, бывают разные обстоятельства когда, нужны просто ручки, чтобы по быстрому подкрутить. Не всегда связанные с "кривизной" оптимизатора, а, например, с "кривизной" решений.

Возражений не имею.

vadiminfo
AndreiNz

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

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

Не обязательно. Например если по атрибуту не построена гистограмма, то ораклячий оптимизатор предполагает равномерный закон распределения даного атрибута. Если закон распределения совсем другой, то исходя из знаний предметной области (закон распределения атрибута мне извстен а оптимизатору - нет), я построю лучший план запроса чем оптимизатор.

vadiminfo

А Вы писали, что в любом запросе их надо писать. Еще раз - много проггеров, пишуших запросы про них не знает, и запросы отрабатыет с требуемой по ТЗ поизводительностью. Трудности с запросами возникают редко. По моему Том Кайт где-то писал, что таких тяжелых запросов на приложение достаточно мало.
У нашей фирмы несколько проектов. Одна из моих обязанностей - задачи оптимизации запросов, когда проггерам не удается добиться требуемой производительности. За три года таких случаев всего четыре. Из них только в в двух пришлось прибегнуть к хинтам. Причем в одном как временное решение, пока не перепроектировали с использованием секционирования. А запросов в каждом проекте несколько десятков.
Поэтому, найденный Вами недостаток, кажется, слишком надуманным.
Рекомендую глубже копать, если хотите что-то показать, чтобы потянуло на статью в каком-нибудь журнале - мол у лидирующей СУБД недостаток существенный нашел.


У вас задачки невеликие (без обид). У меня на работе хранилище данных на 40 терабайт, заливаем 200 гиг каждый час. Соответственно весь ораклячий ETL собран на хинтах, чтобы гарантировано работало. Иначе если начнет тормозить - не расхлебаем. Просто не успеем - каждые 5 часов простоя это примерно терабайт накопившийся для обработки.
5 ноя 06, 04:18    [3357694]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить