![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Большие базы в InterBase/FireBird [IB6.x, FireBird]
Kombat © (2002-05-30 13:39:00)Уважаемые Мастера, выскажите своё мнение! Есть задача автоматизации расчетов, в БД содержатся данные о клиентах и их операциях (~50000 записей операций в месяц). Через некоторое время возникает проблема производительности, нужно проводить архивирование записей, перенос их в другую таблицу, архив. Вопрос: эту таблицу можно держать в этой же базе или её необходимо переместить в отдельный gdb файл, а в программе использовать два соединения с двумя БД (рабочая и архив)? Если таблицу оставить в основной БД, то не будет ли её рост влиять на производительность всех операций с БД, на выборки из других таблиц (объем базы растет)?
icu (2002-05-31 09:17:00) [1]Мое мнение - надо использовать любой блокировщик, а не копировщик. То есть сервер БД блокирующий транзакции, а не сервер подобный IB с его копированием записей. Любые запросы в IB при числе записей от 500 000 и выше будут выполняться много медленней, чем в том же SQL Server или Ora, где индексы используются много эффективней. IB управляет танками (A1M1, например), там не до миллионов записей... =)
Kombat (2002-05-30 22:34:00) [2]Оракл конечно если не лучше, то мощнее. Но за мощь приходится платить (и явно побольше чем 0$ за IB :), кроме того не каждый админ в состоянии поднять Оракл. Но вопрос скорее не в том как быстро будут обрабатываться 20 млн. записей переговоров, а не будет ли мешать это табличкам с 20-30 тыс записей, ведь база IB это все таки один или несколько файлов, а их надо читать, перемещатся по ним. И как быть с backup\restore? Ведь те 20 млн. это полностью статическая информация, т.е. она никогда не меняется (факт телефонного разговора)
Anatoly Podgoretsky (2002-05-30 22:01:00) [3]Kombat (30.05.02 13:39)
Не знаю, как у тебя с объемом, но есть сведения об базах размером 980 гб
Johnmen (2002-05-30 21:33:00) [4]Если количество записей измеряется млн-ми, то лучше, видимо, Oracle...
Kombat (2002-05-30 18:45:00) [5]с руками все вроде нормально, индексы есть, просто это один месяц 50000, а месяцев много :)) начисление может пройти в 01 месяце а его оплата (другая табличка) в 12, а нужно показать карточку клиента и его историей. Если 50000 это не объём, то как база отнесется к 1 000 000 ежемесячно (месячный объем переговором маленькой телекоммуникационной компании)?
Fareader (2002-05-30 15:35:00) [6]~50000 записей операций в месяц - это не объем, у меня несколько сотен тысяч записей в месяц заносится и нормально. Пробовал индексы пересоздавать (если они есть конечно ;) ) или делать базе backup\restore?
Johnny Smith (2002-05-30 15:02:00) [7]2Alexandr © (30.05.02 14:18)
У вас мания "кривых рук"?
Alexandr (2002-05-30 14:18:00) [8]не будет.
Можешь в этой же базе оставить.
Кстати, а чего это проблема производительности возникает? Ты уверен, что это не от твоих кривых рук?