Имхо, сдаётся мне что всё честно..
Ну 4 гига памяти.. для
-х разрядов без дополнительных телодвижений (под никсой) придел.
Ну 2 проца (вопрос — как у Oracle ядра катят за проц или все же нет? .т.е на ксеоне с 4 ядрами но одним процем будет как написано?)
А по сути — это накладывает ограничения на БД в части эффективности её использования. Ну да, если там «пару таблиц» - нет вопросов :) А если БД растет... Тут и лукавство вероятно и сидит :) т.к. Спецы IBM наверняка (есть подозрение) знают какой придел для такого железа по БД.. а то что этот придел есть — факт.
Остается решить — на сколько хватит этот халявы? Ну.. так, примерно — на 10 гигов, 1 Тб ?
Я имею ввиду что бы это реально работало — а то отчет за смену если будет отрабатывать к окончанию следующей смены вероятно потеряет актуальность.. А вот «быстренько пересели» - это не получится, купить аналогичное — возможно, но дорого (для справки: стоимость покупки и внедрения DB2 значительно выше Oracle, но в последствии, стоимость владения ниже). Так что — думать и думать :)
Я вот думаю, одна из БД у меня может «расти» ~ 15-20 Гб/год — пока не в промышленной эксплуатации (в смысле денег никто не даст пока) — стоит ли пробовать DB2 ???
PS: вот, тестю Firebird/PostgeSQL/MySQL — и что странно, запрос типа SELECT * FROM ROWS 1500000 TO 1600000 быстрее всех отрабатывает на Firebird при аналогичной структуре и наполнении всех СУБД основанных на существующей БД Oracle (с которой есно никто и рядом в этом тесте не стоял) — хотелось бы аналогичную производительность как в Oracle.

miksoftstells2SELECT * FROM ROWS 1500000 TO 1600000Неужели вы рассчитываете осмысленно сравнивать СУБД на основе бессмысленного запроса?
Знаете, можно продумать всё и рассчитать, вывести матмодель и т.д. и потом даже прийти к удивительным результатам – и тут ваша правда.
Я же просто тупо «пробую как на практике» без умнечества.
Создал базы на разных СУБД с одинаковой структурой, наполнением и функциональностью.
Средний размер БД ~ 3 Гб. Количество таблиц 240 количество записей от 8 млн до 10.. в таблице.
ОС GNU/Linux (Debian) железо – один из серверов в стойке аналогичный рабочему.
В общем – это бэкап одной из рабочих баз.
Интересовало – как себя будет вести СУБД при массовой записи – для этого написал приблуду на Delphi которая заполняла (перекачивала данные из Oracle в MySQL/Firebird/PostgreSQL) БД.
После 60% наполнения делал запросы – цель, определить под нагрузкой (заполнение продолжалось) отклик СУБД. Всё было как обычно – инструменты разработчика, драйвера-конекторы, ОС и т.д. всё из текущей практики.
Простейший запрос, который показывает способность работы с индексами, кешем, дисковой подсистемой, оптимальностью хранения (организации хранения) данных – это SELECT “из середины»… На этом запросе PostgreSQL показал стабильное но далеко не лучшее время, т.к. сказалось отсутствие кэширования. MySQL значительно использует кэш:
MySQL (5.1.31 таблицы InnoDB)
Для процедуры выборки
(Выборка безусловна на 100 000 записей со смещением 5 500 000 от начала.)
1. Executed OK (34.125 с)
2. Executed OK (33.969 с)
Обыкновенный селект:
1: 31.031 с
2: 28.109 с
3: 26.719 с
но при этом значительно увеличилось потребление памяти.
Firebird (2.1)
Для процедуры:
1. 3s 140ms
2. 2s 937ms
3. 2s 938ms
Для обычного селекта:
1. 2s 734ms
2. 2s 719ms
3. 2s 704ms
Для PostgreSQL среднее время ~ 28 c.
(Выборка по условию)
SELECT HEATID FROM PD_COOLWATER WHERE HEATID = '1001539' ;
(Без индекса – всего записей: 8 288 152, ТИП HEATID = CHAR(7))
MySQL:
Записей 50. Время: 00:01:42
Firebird:
Записей 50. Время: 391 мс
PostgreSQL (8.3)
Суммарное время выполнения запроса:2063 ms. (~ 2 c)
строк извлечено: 50

C включенным индексом по полю HEATID
MySQL
Записей 50. Время: 4.297 с
Firebird:
Записей 50. Время: 78 мс
PostgreSQL:
Суммарное время выполнения запроса:2328 ms.(~ 2.3 c)
строк извлечено: 50
Можно и дальше проводить изыскания и строить нормальный эксперимент..:)
Но во первых – задача чисто практическая а не научная и сводится к «элементарной» задачи оптимизации при заданных условиях (чисто практических)
- время реакции и отклика СУБД на заданных БД
- соответствие стандартам в том числе ХР и т.д.
- удобство разработки (включая опыт программистов)
- Требования к железу под нагрузкой
- максимальный объем данных с которыми может «нормально» работать СУБД
- наличие инструментов, методов и средств обслуживания БД.
- стоимость (точнее, её отсутствие) приобретения СУБД
- возможность работы СУБД на разных платформах (требуется установка на *nix).
Во вторых – модераторов прошу не бить.. за отклонение от топика, это только ответ на замечание..:)
Совершенно не рассмотренными остались иные СУБД и в частности DB2.. По простой причине – я не знаком с ними а хотелось бы.. DB2 скачал и дома поставил, но пока сказать нечего :(
Если кто реально подскажет – стоит ли «мутить» с DB2 (её «бесплатной» версией) – буду признателен.

Хренstells2,

В mysql 50 записей по ключу - 4 сек??? в постгресе 2.3 сек?? выбросьте свои тесты на помойку, результат явно невалидный.

И mysql и постгрес за это время сумеют тысячи записей найти по ключу на обычном домашнем компьютере.
угу.. это не "тест".. это просто обычный запрос выполненый в MySQL Query Browser (впрочем, на серваке с консоли также), так что - ни доказывать не опровергать нет смысла.
50 записей из 8 млн.. которые есно лежат как угодно.

I_love_MSDNЧто - то как- то я не верю...

Что IBM даёт бесплатно? в смысле СУБД.. :)
или посту выше?
Во втором случае никто не мешает проверить как нравиться - не суть..
Меня больше интересует "вы можете развернуть и запустить в работу сервер баз данных за минут" (как то так) - это анотация к DB2.. понятно что за 15 минут ничего толкового не выйдет - но сама суть.. Это верно? (относительно Oracle)

Хренstells2,

авторугу.. это не "тест".. это просто обычный запрос выполненый в MySQL Query Browser (впрочем, на серваке с консоли также), так что - ни доказывать не опровергать нет смысла.

Тогда зачем было приводить тут эти выкладки? что они могут доказать, если сам тест " это не тест " и " ни доказывать ни опровергать нет смысла "?

А как вы измеряли скорострельность в Query browser? А настройки серверов какие?

Мой пост был не показать что хуже или лучше, я просто скопировал рабочий процесс, т.е. тупой факт как есть не подтасованный, ибо я заинтересован в выборе СУБД а не определения «кто круче»..И сегодня, вопрос выбора остается открытым для меня, ибо кроме производительности еще интересуют и другие характеристики. Решено только что не MS SQL.
Да, я согласен, что тюнинг возможно повысит результаты. Но в общем то, конфиги в первом приближении нормальные (хотя и не спорю). С MySQL еще одна сложность, хоть и заявлено о полной реализации процедур и т.д. Но сделано это пока через зад (имхо), я о параметрах передаваемых в процедуру селекта (что активно используется в АСУ ТП).
Железо.. не лучший вариант — ксеон на 4 ядрах с двумя гигами оперативки (тестовый же) и SAS винты (массив на 300 гигов), изернет канал гигабитный.
У Firebird практически ничего не менялось акромя алиасов..
У MySQL установки не влияющие на производительность, за исключением параметров: количество подключений и кеш открытых таблиц (20 и 512 соответственно).
У PostgreSQL так же ничего не менялось кроме настройки безопасности.
Все таблицы и типы данных идентичные включая и ключи и индексы.
Всё живет на одной машине — но работает(ло) по очереди, т.е. В на каждый тест стартовал один сервер, так что все в равных условиях.
Время.. гм.. любой запрос показывает время возврата результата.. Firebird например, еще и показывает подробности — время подготовки, выполнения, затраты на один курсор и т.д.
Зачем тот пост «если это не тест» - конечно это тест, но в личных целях — просто спорить и доказывать не вижу смысла: copy-paste и всё..
По скорости записи — софтина что писала делала и подсчет, я поставил условие на подсчет каждой 1000 инсертов. т.е. 1000/с
Так что насчет DB2 ?

Senya_Lstells2,
MySQL вроде бы и хвалят как раз за скорость простых select'ов.

Да, для MyISAM, но они не поддерживают ссылочную зависимость и много еще чего.
Речь о нормализованной базе и не совсем малой :) Которая имеет правила, ограничения, зависимости, связи и т.д. В этом плане, MySQL обычно никто не рассматривал, т.к. до последнего времени в основном эта СУБД использовалась на WEB серверах и до сих пор, многие и не подозревают что сегодня MySQL функционально ничем не уступает Firebird а в чем-то (по набору функций) и превосходит.
Senya_L
Но вообще берите FB, не прогадаете. )))

да вот уж думаю.. :) Еще бы кто точно сказал "у меня БД большая, я активно в неё пишу и читаю и пользователей больше 10 и при этом все довольны" )