Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
 MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Andrew Sagulin
Member

Откуда: г. Старый Оскол
Сообщений: 70
Целью данного сообщения не является holy war и вообще какое-либо общее сравнение различных СУБД. Я лишь хочу показать, что для моей задачи лучше подходит postgresql, и объяснить, почему я так считаю. Возможно, кому-нибудь это поможет сделать более взвешенный выбор, а комментарии к этому сообщению помогут мне по-другому взглянуть на мои проблемы. Кроме того, прошу о некоторой доли снисходительности, так как я не являюсь специалистом по СУБД, и мои знания по ним имеют достаточно узкий и несистематический характер.

Итак, моя задача - предбиллинг:
1. хранение большого количества телефонных вызовов (~300 млн. записей);
2. поиск в диапазоне дат, что соответствует индексному скану по большому количеству записей (от 400 тыс. до нескольких млн.);
3. объёмные выборки (обычно за сутки, что соответствует ~400 тыс. записей);
4. малое количество одновременно работающих клиентов (максимум 2);
5. отсутствие UPDATE - только однократный ежесуточный массовый INSERT;
6. увы, скромное железо: P4 2.4 GHz, 1Gb RAM, выделенный под БД SATA винт;
7. Windows 2000 Server SP4.

Около года успешно использую Firebird 1.5 SS. База в основном состоит из большой (18 Гбайт) таблицы и индекса по полю типа timestamp (размер индекса 2 Гбайта). Остальные таблицы сравнительно маленькие.
Что не нравится:
- медленный backup и restore. В моём случае намного быстрее остановить работу БД и сделать файловый бэкап базы, чем пользоваться gbak. Впрочем, в версии 2.0 появилась утилита nbackup, которая кардинально шустрее и гибче, чем gbak.
- невозможно штатными средствами прервать длительный запрос (?)
- некорректное, с моей точки зрения, использование кеша Windows, что на выборках большого количества записей приводит к распуханию кеша и активному свопу. Как мне удалось выяснить, одной из причин является открытие файла БД с флагом FILE_FLAG_RANDOM_ACCESS, из-за чего Windows даже при последовательном чтении файла пытается сохранить в кеше как можно больше страниц файла. Проблему удалось решить правкой исходников FB, чтобы файл БД открывался с флагом запрета кеширования. В Yaffil это можно настроить через конфиг. В конфигурации железа с 1,5 и более гигабайтами ОЗУ этот пункт практически неактуален, так как Windows в любом случае выделяет под кэш не более 900 мегабайт. В FB 2.0 эту, если можно так выразиться, проблему тоже не решили.
А в целом, жить вполне можно.

Как альтернатива, была испробована СУБД MySQL 5.0.16 (как на MyISAM так и на InnoDB). Плюсы движка MyISAM - компактность таблиц, недостаток (в моём случае не очень серьёзный) - отсутствие транзакций. InnoDB - намного больший объём, но с транзакциями. Особо тщательно, правда, я этот движок не тестировал. Недостатки MySQL (на обоих движках), из-за которых я не стал использовать эту СУБД:
- медленный индексный скан. По сравнению с FB разница 3 раза не в пользу MySQL даже на MyISAM.
- любое создание/удаление индекса приводит к полному пересозданию таблицы и всех существующих для неё индексов.

О PostgreSQL у меня на основе слухов сложилось мнение, что это какая-то навороченная, но медленная и сырая СУБД. (Не спрашивайте ссылок и точных источников - сложилось и всё). Но для коллекции, как только на работе появилась передышка, решил попробовать и её (сейчас стоит версия 8.1.4).
Прежде всего, столкнулся с нелогичностью установочной процедуры под Windows: сначала в инсталляторе предлагается установить СУБД как службу, что требует права администратора, а затем создать базу, для которой наоборот надо обязательно права простого пользователя. Так, извините, под каким пользователем запускать инсталлятор? :) Проблему решил просто: поставил под админом, от создания базы отказался, и создал её потом под обычным юзером вручную.
На sql.ru подсказали, что для моей задачи лучше всего применить partitioning. Попробовал - действительно удобно, и позволяет совсем отказаться от индекса по timestamp. Правда, были какие-то странные глюки с падением производительности при скане таблиц. После 'vacuum analyze' всех таблиц глюк пропал (просто analyze не помогало).
Теперь, что удалось добиться (по сравнению с FB) по пунктам:
- Значительно уменьшилось время внесения данных в базу (с 400 до 60 секунд). Такая разница была достигнута в большей степени в результате значительной оптимизации программы подготовки данных, которая, в свою очередь, стала возможной благодаря наличию команды 'copy'. В общем, быстродействие СУБД в этом случае не играет решающей роли.
- PG "дружит" с кешем Windows даже на больших выборках, так что ничего "подкручивать" в этом плане не пришлось.
- Теперь об очень приятном: выборка типа 'select ... from <моя большая таблица> where (datetime between ... and ...) and ...' на PG проходит в 4 раза быстрей, чем на FB. На PG узким местом является винчестер (50 Мб/сек, загрузка CPU ~60%), а на FB - процессор (12 Мб/сек, загрузка CPU ~90%). Я это связываю с накладными расходами на распаковку записей и индексов в FB, а может дело в чём и другом, не знаю...
- Применению partitioning очень способствовала версионность DDL. В результате, в одной транзакции я, если необходимо, удаляю старую таблицу, создаю новую, вношу в неё данные. А если что-то пошло не так, делаю rollback, и всё остаётся как было. В FB такой фокус с DDL не пройдёт, но там частый DDL, мягко говоря, и не приветствуется.

Для себя отметил следующие недостатки PG:
- как упомянуто выше - нелогичный инсталлятор.
- данные занимают в PG заметно больше места, чем в FB. В первую очередь из-за заголовка записи (около 28 байт в PG против 13 байт в FB), плюс все char и varchar поля в PG имеют 4-хбайтовый префикс длины поля. В FB - он 2 байта. В моём случае это вылилось в то, что одни и те же данные в FB занимают 18 гигабайт, а в PG - около 25.
- меньше актуальной русскоязычной документации, чем по FB или MySQL. Недавно видел в конференции по PG как за описанием версионности отправляли на ibase.ru. :-) Вообще, должен отметить, что ibase - просто замечательный кладезь информации по IB/FB, а в тамошней конференции много грамотных специалистов, которые помогут в сложной ситуации. Так что, если ваш выбор FB, и вы всё ещё не были на ibase.ru - бегом туда! :)
- DBD-Pg без "обработки напильником" не компилируется под Windows. Так как я с БД работаю в основном из перла, то для меня это весьма неприятное обстоятельство.
- PgAdmin сильно проигрывает по удобству и функциональности таким программа как IBExpert или Firebird Development Studio.

Теперь о "недостатках", которые я таковыми не считаю:
- Говорят, PG сложен в настройке, и без предварительного тюнинга в реальной работе практически неработоспособен. У меня вся настройка заняла 1 рабочий день при том, что я PG вообще первый раз в жизни увидел. По второму пункту: покажите мне того разработчика, который поставит неизвестную ему СУБД под рабочую нагрузку, не покрутив или хотя бы не проверив её настройки? По крайней мере, для всех пробуемых мной СУБД я считал своим долгом хотя бы ознакомиться со всеми доступными настройками.
- В FB база лежит в одном файле, а вот в PG - целый каталог. Ну, тут комментировать, собственно, нечего - бэкапить всё равно в архив, а там не важно, каталог это или один файл.

Комментарии и замечания всячески приветствуются.
16 июн 06, 14:53    [2780035]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Alexander A. Sak
Member

Откуда: Омск
Сообщений: 1228
Про инсталлятор PG.
Мне он как раз показался логичным. Служба должна работать под пользователем с ограниченными правами. Этот пользователь должен иметь право только на базу (каталог с файлами). Чтобы зарегистрировать службу, нужны (около)админские права. Вот и получается, что инсталлер - под админом, служба - под простым юзером. Мне, кстати, инсталлер сам все сделал: и юзера создал и службу от его имени запустил.
16 июн 06, 15:09    [2780177]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
позволю себе несколько замечаний:

по FB:

1) про FILE_FLAG_RANDOM_ACCESS ты не прав :-)
2) с кешем на win32 проблема действительно имеет место
3) про медленный backup. Прошу прощения, но с чем сравнивали? С дампом в скрипт или с файловым копированием (имею ввиду другие СУБД)?

по PG:

1) про "очень приятное" - это просто уход от индексного скана в пользу фуллскана партиции, тут все ожидаемо. Для ваших задач партишенинг - то, что доктор прописал.

в остальном - все достаточно объективно и достоверно
16 июн 06, 15:23    [2780315]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Andrew Sagulin
Member

Откуда: г. Старый Оскол
Сообщений: 70
dimitr
позволю себе несколько замечаний:

по FB:

1) про FILE_FLAG_RANDOM_ACCESS ты не прав :-)


Не прав, значит не прав - спорить с разработчиком FB не буду :)

dimitr

3) про медленный backup. Прошу прощения, но с чем сравнивали? С дампом в скрипт или с файловым копированием (имею ввиду другие СУБД)?


Сравнивал я, конечно, с файловым копированием. Дамп в скрипт на таких объёмах - просто нереален. (На PG я планирую настроить бэкап через архивирование WAL). Nbackup в FB 2.0, я считаю, фактически решает проблему бэкапа и оперативного (!) восстановления большого объёма данных. А инкрементный бэкап так вообще замечательная штука. Мои претензии относятся только к gbak.

dimitr

по PG:

1) про "очень приятное" - это просто уход от индексного скана в пользу фуллскана партиции, тут все ожидаемо.


В том-то и дело, что первым вариантом на PG был индексный скан по одной большой таблице. В прямую он не сработал - оптимизатор не включал bitmap scan. А вот когда я создал индекс не по timestamp, а по выражению cast(datetime as date), то включился bitmap scan и я получил при индексном скане более 30 мегабайт в секунду. Примерно столько даёт FB на фуллскане.
16 июн 06, 15:55    [2780656]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Andrew Sagulin
Member

Откуда: г. Старый Оскол
Сообщений: 70
Alexander A. Sak
Про инсталлятор PG.
Мне он как раз показался логичным.
...
Мне, кстати, инсталлер сам все сделал: и юзера создал и службу от его имени запустил.


Беру свои слова назад. Видимо, что-то я не то вовремя установки делал. Сейчас попробовал на другом компьютере - действительно поставилось без проблем. Прошу прощения за дезинформацию.
16 июн 06, 16:02    [2780702]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Andrew Sagulin
Сравнивал я, конечно, с файловым копированием

вот именно. Разные же вещи. GBAK надо именно со скриптом сравнивать. Это не придирка, а скорее уточнение.

Andrew Sagulin
включился bitmap scan и я получил при индексном скане более 30 мегабайт в секунду. Примерно столько даёт FB на фуллскане.

любопытно, т.к. битмапы реализованы схоже. Попробую у себя проверить.
16 июн 06, 17:02    [2781140]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Михаил Михайлович
Member [заблокирован]

Откуда: Москва(Зеленоград)
Сообщений: 955
dimitr
Для ваших задач партишенинг - то, что доктор прописал.



Если бы всё так просто. В любой момент могут прийти дяди из
органов и потребовать отследить транзакции звонков по конкретной карте.
16 июн 06, 17:42    [2781420]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Михаил Михайлович
Member [заблокирован]

Откуда: Москва(Зеленоград)
Сообщений: 955
И делать копирование рабочего файла вместо бэкапа всёравно очень стрёмно.
А, кстати, сборку мусора не забываете отключать, когда Вам надо сделать
"быстро" :) ?
16 июн 06, 17:45    [2781440]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Попробуйте и DB2 Express-C.
16 июн 06, 19:59    [2781979]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

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

Victor Metelitsa пишет:

> Попробуйте и DB2 Express-C.

Ну вот, сейчас каждый предложит что-нибудь попробовать :) Человек не
спрашивает, что выбрать, а просто поделился своим опытом выбора для
своей задачи из 3-х упомянутых СУБД. Конечно, за кадром осталась
мотивация выбора претендентов (возможно выбирались Open source или
просто "бесплатные" серверы), может при более широком охвате выбор был
бы другим, но нельзя объять необъятное. Выбор сделан и вполне здраво.

Posted via ActualForum NNTP Server 1.3

16 июн 06, 21:28    [2782179]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Михаил Михайлович
Если бы всё так просто. В любой момент могут прийти дяди из органов и потребовать отследить транзакции звонков по конкретной карте.

это ты к чему? Что мешает иметь индекс по номеру карты в довесок к партициям по диапазону дат?
16 июн 06, 23:01    [2782369]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун

Victor Metelitsa пишет:

> Попробуйте и DB2 Express-C.

Ну вот, сейчас каждый предложит что-нибудь попробовать :) Человек не
спрашивает, что выбрать, а просто поделился своим опытом выбора для
своей задачи из 3-х упомянутых СУБД. Конечно, за кадром осталась
мотивация выбора претендентов (возможно выбирались Open source или
просто "бесплатные" серверы), может при более широком охвате выбор был
бы другим, но нельзя объять необъятное. Выбор сделан и вполне здраво.

Ну вот, сейчас каждый начнёт мне указывать, предлагать мне кому-либо что-либо или нет. Считаю, что "человека" для СУБД скорее интересовала бесплатность, чем "open source", а выбор тут совсем не необъятный. Учитывая железо, нагрузку и требуемый объём данных, кроме MySQL, Firebird, PostgreSQL и DB2 Express-C, я уже и не знаю, что ещё назвать. И у меня есть большие подозрения (хотя и не увереность), что именно DB2 и окажется лучшим выбором.
17 июн 06, 12:58    [2783006]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Ближе к уверенности, чем к подозрениям.
17 июн 06, 13:13    [2783028]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Например:

Данные на диске (судя по моему опыту с tpc-r) будут занимать лишь чуть больше места, чем в Firebird, и определённо меньше, чем в Postgres. При этом имеется специальный вид партишионирования (под названием MDC - MultiDimentional Clusters). Возможно, также пригодятся MQT (Materialized Query Tables).

Бекапы с компрессией!

Скоро (где-то месяц остался) выйдет DB2 v9; если там в Expess-C включат опцию компрессования данных в таблицах, то предыдущая тройка вообще не будет конкурентноспособна по скорости выполнения запросов на больших таблицах...
17 июн 06, 13:32    [2783066]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
guest_20040621
Guest
Вы, Andrew Sagulin, всю вкуснятину пропустили. ;) Поставьте PostgreSQL на продакшн Linux на нормальном железе - удивитесь еще больше.
17 июн 06, 13:42    [2783083]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Victor Metelitsa

Считаю, что "человека" для СУБД скорее интересовала бесплатность, чем "open source", а выбор тут совсем не необъятный. Учитывая железо, нагрузку и требуемый объём данных, кроме MySQL, Firebird, PostgreSQL и DB2 Express-C, я уже и не знаю, что ещё назвать. И у меня есть большие подозрения (хотя и не увереность), что именно DB2 и окажется лучшим выбором.

Может быть, не знаю - сам не пробовал. Вызывают сомнение несколько моментов:
1. Стоимость сопровождения
2. Дальнейшая судьба этой "бесплатности":
Victor Metelitsa

Скоро (где-то месяц остался) выйдет DB2 v9; если там в Expess-C включат...

Вот это вот "если" и смущает. У кого-то есть уверенность в том, что IBM выпустил DB2 Express-C из благотворительных побуждений?
guest_20040621

Вы, Andrew Sagulin, всю вкуснятину пропустили. ;) Поставьте PostgreSQL на продакшн Linux на нормальном железе - удивитесь еще больше.

Ну, про железо изначально сказано "увы" в 6-ом пункте, но вообще, не спора ради, а из любопытства: сильно ли отличается производительность PG на одинаковом железе под Windows и Linux? Я понимаю, что PG изначально разрабатывался под unix-системы, а недавное появление порта под windows носило скорее всего маркетинговый характер (если такой термин применим для open source). Но тем не менее, весьма любопытно было бы узнать, делал ли кто-нибудь сравнительные тесты?
17 июн 06, 14:15    [2783125]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
guest_20040621
Guest
> про железо изначально сказано "увы"

Да, я обратил внимание.

> сильно ли отличается производительность PG на одинаковом железе

До performance тестов руки не дошли. Было так: java приложение (JBoss, AMQ) на примитивном железе (dual P3, 1Гб памяти, одиночный IDE, база данных ~5Гб) под SLES9 и w2k соответственно; PostgreSQL as is. Внешний эмулятор нагрузки. По тестам получилось, что для этого конкретного приложение SLES на ~80% производительнее (время отклика меньше заданного для почти вдвое большей нагрузки). Оценка PostgreSQL косвенная: очередь сообщений (пре- и постпроцессинг (в т. ч. запись/извлечение из БД)) на SLES была в три раза короче, чем на w2k; дисковую не мониторили.

Сложно сказать, какой именно (в цифрах) прирост производительности обеспечила СУБД; тогда мне была более важна общая оценка.
17 июн 06, 15:40    [2783235]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун
Victor Metelitsa

Считаю, что "человека" для СУБД скорее интересовала бесплатность, чем "open source", а выбор тут совсем не необъятный. Учитывая железо, нагрузку и требуемый объём данных, кроме MySQL, Firebird, PostgreSQL и DB2 Express-C, я уже и не знаю, что ещё назвать. И у меня есть большие подозрения (хотя и не увереность), что именно DB2 и окажется лучшим выбором.

Может быть, не знаю - сам не пробовал. Вызывают сомнение несколько моментов:
1. Стоимость сопровождения

Фикспаки до сих пор были бесплатны. Посмотрите на ftp://ftp.software.ibm/ps/products, сколько фикспаков ко скольким продуктам IBM за сколько лет там накопилось. Не вижу причин, почему это должно измениться.

Что-то сверх того (открытие PMR; т.е. официальные жалобы разработчикам), наверное, потребуют покупки DB2 Express (где-то $150 на юзера при минимуме в 5 юзеров или $5k на процессор; плюс какая-то допплата за техподдержку), но вы можете надеяться, что если вы натолкнулись на ошибку, то и другие тоже, и PMR откроет кто-то другой, после чего это будет поправлено в очередном фикспаке (периодичность примерно 4 раза в год).


2. Дальнейшая судьба этой "бесплатности":

Для 9-й версии DB2 Express-C обещали. Т.е. лет на 5 должно хватить.

Victor Metelitsa

Скоро (где-то месяц остался) выйдет DB2 v9; если там в Expess-C включат...

Вот это вот "если" и смущает.

Что же смущает? "Если" во фразе "если в DB2 Express-C добавят ещё одну возможность, то она станет недосягаемой (на некоторое время) по производительности для бесплатных конкурентов"? К сожалению, пока неясно, сколько фич будет в очередной бесплатной версии, но вы вполне можете познакомиться и с текущей, v.8.2.

У кого-то есть уверенность в том, что IBM выпустил DB2 Express-C из благотворительных побуждений?


Странное замечание. Откуда у вас мысли про какую-то там благотворительность?

Вот, к примеру, смотрю я рекламу женских прокладок - совершенно бесплатно, а ведь производитель вбухал на неё немалые деньги и никак не может рассчитывать, что от меня ему они когда-нибудь вернутся. Но разве это благотворительность?

DB2 Express-C - это реклама, причём, я полагаю, недорогая для IBM и довольно эффективная.
17 июн 06, 16:33    [2783305]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

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

Victor Metelitsa пишет:

>> 1. Стоимость сопровождения
> Фикспаки до сих пор были бесплатны. Посмотрите на

Я, наверное, немножко некорректно выразился. Имелась в виду сложность
обслуживания, требования к наличию и квалификации DBA. DB2 не щупал,
поэтому сей вопрос для меня неведом, могу судить только по мнению
третьих лиц:

Картинка с другого сайта.



> DB2 Express-C - это реклама, причём, я полагаю, недорогая для IBM и
> довольно эффективная.

Вот и я о том же. Первая доза бесплатно :)

Posted via ActualForum NNTP Server 1.3

17 июн 06, 16:52    [2783338]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун

> DB2 Express-C - это реклама, причём, я полагаю, недорогая для IBM и
> довольно эффективная.

Вот и я о том же. Первая доза бесплатно :)


На данный момент нет признаков того, что последущие дозы DB2 Express-C будут платными.

Как я понимаю, "серьёзные люди" пожелают настоящей поддержки от разработчиков, а потому всё равно купят коммерческий продукт с коммерческой поддержкой, так что особо больших потерь у IBM не будет. А тех, которые пользуются бесплатными продуктами вроде тройки, перечисленной выше, не заставить купить коммерческую версию DB2, так почему бы не дать им бесплатную? Большая известность, больше знакомых с программированием и администрированием DB2 людей - это ведь полезно.
17 июн 06, 18:54    [2783436]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун

Victor Metelitsa пишет:

>> 1. Стоимость сопровождения
> Фикспаки до сих пор были бесплатны. Посмотрите на

Я, наверное, немножко некорректно выразился. Имелась в виду сложность
обслуживания, требования к наличию и квалификации DBA. DB2 не щупал,
поэтому сей вопрос для меня неведом, могу судить только по мнению
третьих лиц:


Лично мне администрирование DB2 не кажется таким уж страшным. Хотя подводные камни, конечно, есть. С другой стороны, IBM сейчас занимается автоматизацией настройки и обслуживания, что особенно будет заметно в v9. "Сейчас" (в v8) имеется автоматизация бекапов, сбора статистики, дефрагментации. В v9 прибавляется автонастройка буферных пулов, памяти под сортировку. (я ещё что-то упустил в перечислении, но лень смотреть доки).
What's new for V9.1: Highlights of Version 9.1
17 июн 06, 19:04    [2783445]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

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

Victor Metelitsa пишет:

> Как я понимаю, "серьёзные люди" пожелают настоящей поддержки от
> разработчиков, а потому всё равно купят коммерческий продукт с

IBM оказывают поддержку только покупателям коммерческих версий?

А по первому вопросу что? Как лично вы оцениваете пригодность DB2 для
организаций, имеющих в штате ну максимум сисадмина (и то не всегда) и уж
никак не выделенного высококвалифицированного DB2 DBA?

Posted via ActualForum NNTP Server 1.3

17 июн 06, 19:08    [2783452]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Александр Гoлдун
Member

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

Запостил вопрос позже, чем пришел ответ :)

Victor Metelitsa пишет:

> Лично мне администрирование DB2 не кажется таким уж страшным.

А если в сравнении, скажем с Oracle или ASE?

Posted via ActualForum NNTP Server 1.3

17 июн 06, 19:11    [2783458]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Yo.!!
Guest
2Александр Гoлдун

db2 это не asa, на свете сотни тысяч спецов по db2, покажи деньги и будет у вас и супорт и удаленное администрирование и черт лысый в любой точке мира.
17 июн 06, 19:15    [2783465]     Ответить | Цитировать Сообщить модератору
 Re: MySQL, Firebird, PostgreSQL или как я выбирал СУБД  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Александр Гoлдун

Victor Metelitsa пишет:

> Как я понимаю, "серьёзные люди" пожелают настоящей поддержки от
> разработчиков, а потому всё равно купят коммерческий продукт с

IBM оказывают поддержку только покупателям коммерческих версий?

Фикспаки и ответы на вопросы в ibm-овских форумах - это уже поддержка. Но коммерческие юзеры, естественно, имеют больше.

А по первому вопросу что? Как лично вы оцениваете пригодность DB2 для
организаций, имеющих в штате ну максимум сисадмина (и то не всегда) и уж
никак не выделенного высококвалифицированного DB2 DBA?

Если организация имеет максимум сисадмина, то программный продукт, который она использует - сторонний, делали его такие люди, которые этого DBA имеют, и эти люди оказывают организации поддержку. Как установить DB2 и создать базу, какие параметры задать, как бекап настроить - советуют разработчики. Ничего особенного - несколько скриптов, чуточку рекомендаций. Именно так я это понимаю.
17 июн 06, 19:19    [2783470]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить