Yo!!2krestianin

чушь, I/O выходит на первое место только в приложениях типа tpc-h. откройте любые тесты, что tpc-c, что sap - на OLPT увеличение проца на 200Mhz дает прирост производительносьти чуть ли не в разы, в то время как i/o влияет существенно но не в разы.

Извините, но не могу избавиться от впечатления, что под OLTP вы понимаете только лишь скорость работы процессора, отбрасывая от реальной системы I/O накопителей, где собственно и лежит база. Транзакция ведь может быть такой, что поднимет все блоки данных с винта. Увеличение герцовки проца на 200 MHz не может и никогда не могло дать прирост производительности системы в разы! А вот влияние I/O существенно - это ближе к истине, о чем ранее я и напомнил, да это по идее и должно быть давно извествно сисадминам СУБД, а тут хрясь - "наша СУБД станет в разы круче, если ей только лишь проц заапгрейдить"... :-0
Именно в тестах tpc-h и выровняли значимость I/O, дабы получить более объективные результаты, и спора тут никакого и нет. Вы сами зачем-то привели в аргументах тесты tpc, подкрепив ими противопоставление проца и I/O.
Сорри, но у меня сейчас Pentium-3 с одним IDE-винтом отработает все тот же запрос к СУБД отнюдь не на порядки быстрее той старушки Pentium-Pro с добротными SCSI-дисками, на которой эта БД была ранее.

Это я не понимаю, что вы пытались доказывать в процитированном вашем сообщении, сами, причем, аргументируя "мягкими" и "теплыми" тестами?
Да и вижу я ваши намеки на SAP, но дело ведь не в переборе всевозможных тестов, а в том, что систему тормозит больше самая медленная ее часть - I/O -это обычно и без тестов понятно, и что от этого будет тормозить сильнее - DW или OLTP, никак не меняет суть дела.

Действительно, сравнение BMW и Мерседесов-ов какое-то...

2 Yo!!

Я посмотрел ваши примеры.
Система с 2.8ГГц выиграла 19 тестов из 24, проиграла 2 теста, и по оставшимся 2-м тестам разницу можно признать несущественной.
Различие между дисковыми подсистемами только лишь в том, что при машине с 2ГГц используются и 4-х канальные SCSI-контроллеры и 2-х канальные, а при 2.8ГГц проце используются только 2-х канальные. Количество памяти SCSI-контроллеров одинаковое (по 128М), пропускная способность на канал у плат тоже одинаковая (160 МБ/с), количество (правда одинаковых) винтов заметно разное, на системе "2ГГц" их больше и при этом они разнесены
на на 6 SCSI-контроллеров 4-х канальных и 4 контроллера 2-х канальных, -
что будет в таком случае твориться на шине в материнской плате, если честно - сложно сразу сказать, в то время как в "выигрышном" варианте только 5 2-х канальных контроллеров. Каждый лишний контроллер будет драться за ресурсы шины материнки и где оптимальная грань количества SCSI-контроллеров для конкретной матери сходу и не скажешь, но одно дело когда системная шина на 10 контроллеров, а другое - только на 5.

Утверждать, что 2.8ГГц система сильнее "зажата" по I/O, но при этом выигрывает именно за счет лишних 800МГц, на мой взгляд довольно смело, потому что у проигравшей системы нет явных преимуществ по I/O - у нее просто на одном из видов SCSI-адаптеров по 4 канала, но при этом их больше, да еще они смешаны с 4-мя 2-х канальными.

Вам не кажется странным, что на "проигравшей системе" для чего-то навешано
6-ть адаптеров, каждыq из которых может обслуживать по 56 винтов +
4-е адаптера, каждый может вести по 28 винтов,
а вот на "выигравшей" системе
5-ть адаптеров, каждый может вести по 28 винтов.
Зачем пихать 6х56 + 4х28, когда для базы видать вполне хватало
5х28 ???????? :-0

Сравнивать на самом деле надо
2ГГц + Ultra160/256MB/4 канала с 2ГГц + Ultra160/128MB(а то и ниже)/2 канала

а затем

2.8ГГц + Ultra160/256MB/4 канала с 2.8ГГц + Ultra160/128MB(а то и ниже)/2 канала

А во всем остальном должно быть идентичное равенство.

Я скорее приду к выводу, что у "выигравшей" в этом сравнении системы не было поводов проигрывать в I/O.

2 Yo!!

И кстати, что вы все время так давите на разницу между DW и OLTP ?

Случаются системы чисто DW, гораздо чаще, чем чисто OLTP, но что самое главное - большинство остальных систем работают в смешанном режиме.
Да и сама эта терминология в достаточной мере условна - для разгрузки систем выделяют DW-часть, либо в иных случаях просто практически отсутствует OLTP-"режим", а данных великое множество, и посему БД можно оптимизировать именно только на отгруз информации.
Для вас что , чистый OLTP-режим какой-то особый показатель? Я действительно не могу понять хода вашей мысли в этом направлении. :-)

У меня возникло ощущение , что господин Yo!! путает два несравниваемых понятия: OLTP (On-line transaction processing) и OLAP (On-line analytical processing), потому что по его постам можно заключить, что тесты tpc-* связаны именно с OLTP и здесь проходит какая-то таинственная тонкость по сравнению с DW (DataWarehouse), в то время как на самом деле тесты tpc-* и появились на свет после выдвижения Коддом требований к системам по выполнению OLAP (например, многомерный анализ данных).
tpc-c из имитации банковской активности oltp в тесте предшественнике tpc-a, превратился в более сложную среду oltp на основе имитации складской системы; tpc-h - имитация крупной БД по принятию решений без отказа от oltp-транзакций, в том числе сами решения принимаются в режиме ad-hoc (т.е. без тюнинга запросов).

Утверждая, что поднятие частоты проца на 200МГц (кстати, непонятно относительно чего: от 200МГц - это 100% от номинала, от 4000МГц - это только 5%) повышает продуктивность системы по тестам tpc-c в разы, когда tpc-h только на чуть-чуть ( поэтому, мол, самое главное - это проц, а не I/O) привел в качестве доказательства в конце концов тест на tpc-h 8-ми головых систем, где у одной системы каждая голова на 40% выше, бездоказательно утвержлая, что эта система "зажата" по I/O. Как это можно утвержать просто глядя на кол-во SCSI-плат мне не понятно, потому что не понятно сколько отдельных ответвлений в шине PCI на этой материнке сделано (а много их не сделаешь, т.к. длина шины PCI считанные дюймы), в результате чего вполне может оказаться, что у выигравшей системы каждый адаптер сидит на своей нитке, в то время как у проигравшего кажды адаптер имеет по 2-3 соседа.

2 Yo!!
А что вам так сложно объяснить нам ту самую разницу, которая видна только вам? Если вы такой высокий специалист, почему только лишь сорите постоянно намеками без существенных пояснений.
Может мне (и не только мне одному) было бы интересно узнать в чем суть, и какое такое могучее понимание стоит за вашими словами о витринах данных и чистых OLTP системах?

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

Собственно с самого начала вы стараетесь сказать что эффективность I/O важна только в отдельных случаях ( DW ) в ответ мне, где на мой взгляд и опыт I/O важен всегда.

krestianin Yo!!2krestianin
чушь, I/O выходит на первое место только в приложениях типа tpc-h. откройте любые тесты, что tpc-c, что sap - на OLPT увеличение проца на 200Mhz дает прирост производительносьти чуть ли не в разы, в то время как i/o влияет существенно но не в разы.

То-то и оно, что tpc-c отражает абстрактное количество транзакций, которое успевает прохавать система в еденицу времени. в то время как tpc-h отражает возможности СУБД по успешному хаванью разносторонних сложных транзакций в зависимости от величины БД.

А специалисты HP просто создали систему не по незнанию своему, а именно по знанию - она расчитана на бОльшие объемы данных, это видно невооруженным глазом, взамен пожертвовав производительностью по сравнению с другими своими творениями.

Возьму пример с вас и не стану приводить в пример две OLTP-транзакции, одна из которых гоняет один и тот же блок данных между памятью и процом (чисто процессор), а вторая заставит СУБД перелопатить с накопителей все блоки данных (чисто процом не прожить без эффективного I/O).

kmikeА чё такое OLPT? Просветите.

Об этом известно только господину Yo!! , но молчит, особенно про "чистый" olPt.

2 Yo!!

Выходит у вас в России не было большого количества случаев столкнуться с большими БД? И поэтому вы считаете, что в России в основном хватает писюков, напичканых мозгами, чтобы туда вся БД сразу влезла и не требовала дополнительных решений по I/O?

Данные обычно имеют способность активно плодиться. И поэтому сколько мозгов ни дай - все мало. Хотя ваша правда в том, что очень много БД на писюках. Не вижу ничего в этом плохого. Задача любого DBA выкручиватся в первую очередь на том, с чем довелось столкнуться (заказчик как правило трудно раскручивается на новое железо).

Вы молодец, что знаете много о DW и DataMart (сюда много всякого можно перечислить, тот же datamining , например), но у всего этого одни и те же корни - данные не влезают в ОЗУ, и происходит это повсеместно, а в России еще чаще.

Различия в наших взглядах на вещи очевидны - я никогда не стану делать свою БД в расчете на то, что ей купять много мозгов и ей этого хватит до скончания веков. Практика показывает, что через 2-4 года система вылезает из своих детских штанишек, а памяти сунуть столько, сколько-б хотелось, на практике довольно проблематично.

Но самое главное, IMHO, DBA просто не имеет права расчитывать на размер ОЗУ, стремящийся к бесконечности, потому что понимает - его БД - самая лучшая БД, и через небольшой промежуток времени в ней данных станет завались, в отличие от количества ОЗУ.