Dmitry67 wrote:
Ну можно создать таблички по несколько миллионов и сравнить небольшие тесты навскидку
нет смысла. даже если сравнивать просто планы вылезит тьма непоняток. например один делает фулскан, а другой ходит по индексам, но тут есть вариант, что МФ с допотопными дисками действительно разумней ходить по индексу, тогда как современный писюк гораздо быстрей сделает фулскан с флеш-диска
ну и сравнивать нужно с z/OS, LUW все таки другая ветвь кода, более современная и с большим набором плюшек.
Dmitry67 wrote:
Ну можно создать таблички по несколько миллионов и сравнить небольшие тесты навскидку
нет смысла. даже если сравнивать просто планы вылезит тьма непоняток. например один делает фулскан, а другой ходит по индексам, но тут есть вариант, что МФ с допотопными дисками действительно разумней ходить по индексу, тогда как современный писюк гораздо быстрей сделает фулскан с флеш-диска
Вообще-то прелесть флеш-дисков именно в том, что на них можно быстро ходить по индексам. Фулскан с них будет не сильно быстрее (а иногда и медленнее) чем с "допотопных"
iDesperado wrote:
ну и сравнивать нужно с z/OS, LUW все таки другая ветвь кода, более современная и с большим набором плюшек.
а без разницы - у обоих глюки с оптимизацией (см. предыдущую страницу)
Ну это имеет смысл для оценки ступеньки входа
Допустим я начинаю новый бизнес. Могу я использовать DB2 для небольшой базы, которая потом вырастет до неизвестно каких размеров?
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Dmitry67 wrote:Ну это имеет смысл для оценки ступеньки входа
Допустим я начинаю новый бизнес. Могу я использовать DB2 для небольшой базы, которая потом вырастет до неизвестно каких размеров?
у меня глубокое имхо, что для оценки все равно должен привлекаться спец по той базе которую оцениваем. если оценивать будете только вы, то вы скорее всего протестируете дефолтный вариант или с той оптимизацией, с какой вы бы такую задачу на родном мсскл делали бы. например, вы вероятно все таблички 8к страницы разместили бы по дефолту, а в db2 можно поиграться и часть таблиц допустим на 32к страницы разместить. думаю там можно поиграться с несколькими кешами, допустим для некоторых таблиц отдельный пул выделить. но это кто-то с опытом db2 должен, кто о таких хитростях знает и спроектирует базу с учетом хитростей.
Dmitry67 wrote:Ну так большинство стартапов ставит именно дефолтную конфигурацию
А тут выясняется что надо сразу спеца по Db2 звать ...
Попытался представить себе стартап на MF/DB2. Не смог. А вообще интересно, такое в природе встречается? Из присутствующих кто-нибудь может поделиться опытом, впечатлениями? Ну не обязательно стартап, просто свежий крупный web проект. Что за объемы, каков траффик, проблемы и способы решений, все такое. Пока что мы много чего узнали про компанию, где работает zVlad. И все. И вся эта дискуссия хоть и интересна для чтения, но от реалий большинства читателей сильно далека. А хотелось бы ближе к жизни.
Угасание будет плавным в течение 10 лет,
Последние МФ будут гонять как виртуалки под VMware в режиме эмуляции. Медленно, но на суер пупер новом Intel выпуска 2020 года быстрее, чем 'реальные' - даже в режиме эмуляции.
Кстати ловите идею - это рынок.
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Abappy wrote:
Есть две таблицы - в первой 10 миллионов (+-) записей, во второй 100 тысяч (+-) записей , создаётся запрос по объединению таблиц ( по ключу с соотношением 1:n ( то-есть н записей во второй таблице соответствует одна запись первой) ) с условием по одному из полей (не ключевых) второй таблицы (селект из второй таблицы с этим условием возвращает 1 тысячу (+-) записей . Вторичные индексы и по полям объединения и полям выборки и по всем вместе и т.д. - есть.
Все известные мне базы данных за исключением дб2 сначала выбирают данные из второй таблицы а потом с ними строят джойн с первой . Дб2 в зависимости от фазы луны и т.п. вещей в 50%+ случаев решает, что сначала стоит построить полный хэш джойн обеих таблиц, а потом уже к нему применить ограничение (и получить тысячу записей в результате).
Итого этот банальный запрос выполняется иногда больше 10 секунд.
db2advis запускали? Статистику с опцией with indexes считали? Когда база неправильно применяет предикаты, это почти наверняка проблемы со статистикой.
Dmitry67 wrote:Угасание будет плавным в течение 10 лет,
Последние МФ будут гонять как виртуалки под VMware в режиме эмуляции. Медленно, но на суер пупер новом Intel выпуска 2020 года быстрее, чем 'реальные' - даже в режиме эмуляции.
Кстати ловите идею - это рынок.
Т.е. лет через пять я уже должен потерять работу и не найти другую.
А что мешает гонять МФ "как виртуалки под VMware в режиме эмуляции" уже сейчас? Вы такие примеры знаете?
3.02 What sort of MIPS rate can I expect?
Even on a Celeron 300 you should see an execution speed of 1 to 2 MIPS, which is enough to run OS/360 (MFT or MVT) or MVS 3.8 with a response time better than that of a 3033 from the 1970's. It's also fast enough to run VSE/ESA with an acceptable response time. On a more recent system with a 2GHz Pentium processor, you may see the system peak at around 30 MIPS which is enough to run Linux/390 or z/OS with a light workload.
Performance on server class machines is now fairly respectable. For example, on a dual-core Intel Xeon with hyperthreading (4 CPUs) running at 3.46GHz, you might expect to see a sustained MIPS rate of 40 to 60 MIPS. A dual-processor quad-core Mac Pro (8 cores, 3 GHz) will sustain over 150 MIPS. For anyone who is prepared to spend a considerable amount of money on their Hercules system, there are reports that a sustained 300+ MIPS has been achieved on an Intel Core i7 processor running at 3.75GHz using all four cores plus hyperthreading (8 CPUs).
3 Ее уже реализовали - см пункт 2
Итак, погружаем hercules в VMware - и вот он, mainframe заспиртованный в банке на полке
Зарегистрированный нацпредатель, удостоверение N 19719876044787 от 22.09.2014
Dmitry67 wrote:Угасание будет плавным в течение 10 лет,
Я не fanboy мейнфреймов, помню что такие предсказания делались в середине 1990х...
Дима видимо мечтает разделить "славу" того предсказателя.
In a September 1990 blockbuster announcement, IBM introduced System/390 -- the company's most comprehensive roll-out of products, features and functions in more than a quarter of a century. Encompassing a family of 18 new IBM Enterprise System/9000 processors (10 air-cooled models and eight water-cooled models), System/390 drew on such technologies as high-speed fiber optic channels with IBM's new ESCON architecture, ultra-dense circuits and circuit packaging for higher performance, integrated encryption/decryption for sensitive data, extended supercomputing capabilities, and twice the processor memory previously available.
It was around that same time that some industry observers were declaring the impending death of the mainframe. One such analyst wrote in the March 1991 issue of InfoWorld, for example, "I predict that the last mainframe will be unplugged on March 15, 1996."
To be fair, the "mainframe," circa 1991, was a dead end. But IBM believed (along with a lot of its customers) that this way of computing -- serious, secure, industrial-strength -- would always be in demand.
.......
Indeed, that same InfoWorld pundit, who in 1991 predicted the death of the mainframe, wrote in February 2002: "It's clear that corporate customers still like to have centrally controlled, very predictable, reliable computing systems -- exactly the kind of systems that IBM specializes in." In other words, the king is dead ... long live the king.
