Alexey Pechnikov wrote:
В сообщении от Monday 12 November 2007 12:14:26 Max V. Kotov написал(а):
Alexey Pechnikov wrote:
Утр добрый!
У нас ситуация похожая: прирост ~800Мб/мес. База пока 32Гб. Oracle 9. По
началу не планировали тоже ни базу пересматривать, ни железо. IBM 3U, 4
двухядерных камня, 8Гб оперативки.
В итоге часть процедур переработали+оптимизировали часть селектов и ко
всему прочему вынуждены переползать на SUN сервера. Так что если база
действительно серьёзная, думаю, вопрос не в выборе базы данных.
А если _хорошо_ оптимизировать, то этого железа хватит. У вас в ОЗУ
четверть базы можно разместить или все данные за год, это немало.
Конечное, многое зависит от специфики приложения, но, имхо, железо менять
рано вы надумали. Если у вас более 1000 одновременных пользователей,
тогда возможно, и стоит.
P.S. Если вас не затруднит привести дополнительные показатели, это будет
весьма интересно.
Какие конкретно?
Количество одновременных пользователей, число запросов в секунду, метод
подключения к базе (на java, наверно, раз речь идет о серваке ibm и работе с
oracle), тип задач, соотношение запросов insert/update/select.
Да, клиентская сторона преимущественно на яве. Клиентов ~30. Процентов
80-90 - инсерты в схему + процедуры их обработки. База обсчитывает
телематические услуги ~1000 пользователей.
При обработке данных за месяц (билинговании) возникают как раз те
проблемы, от которых желаем избавиться - сейчас на обсчёт уходит
несколько часов. С половины суток это время снизили до 3х часов примерно.
Узкое место сейчас io_wait, доступ к винтам (они 7200, sata, raid-5,
аппаратный на LSI ). Смотрим в сторону внешнего сановского сториджа c FC
интерфейсом и сановского сервака.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
