Максимальная скорость выборки

← →
Yuri Bezsonov © (2003-03-16 18:30) [0]

Добрый день! Существует задача, нужно создать БД и программу для обработки статистической информации. в БД будет 2 таблички, одна (главная):
Тел_А | Тел_Б |Нач. разговора|Оконч. разг.|Длительность |Тип
| |Дата | Время |Дата | Время|Мин|Сек|Тармин|
VCHR25 VCHR25 Date Time date Time Int Int Int Int

Тип разговора (около 5-10 типов)
Код | Наименование
Int VCHR32

В БД информация может вводится двумя способами:
1) каждые несколько дней по пакету
2) раз в месяц весь месячный объем (~2-3 млн. записей)
Данные уже есть за 16 мес., т.е. уже ~ 30 млн., и дальше будет расти.
Редактирование информации не будет, все пользователи (максимум 5) будут производить только выборки. Выборки по идее должны быть не более 1000 зап. (расшифровка переговоров), но возможны и агрегированные (отчеты) - сумма по направлениям за квартал и др.
Я примерно представляю что такие объемы лучше раскручивать Oracle или MSSQL, но альтернативы FireBird нет, ибо бесплатен.
Сейчас это нормально работает на FoxPro (один месяц - один файл, но это и есть основное ограничение, одним SQL не зделаешь выборку по номеру за год).
Вопросов собственно два:
1) По каким полям нужно построить индексы? (может по всем?) - искать пользователь может по всем полям.
2) При импорте месяца (2 млн.) стоит ли сразу удалить индексы, проимпортировать, а потом пересоздать индексы, или импортировать без удаления или отключения индексов?

Приношу извинения за многословность ))
Хотел бы улышать советы и предложения.

Заранее благодарен.

← →
Rad © (2003-03-16 18:57) [1]

1) Ну, насчёт искать по всем - это ты загнул: по минутам или, там, секундам искать вряд ли кто будет :))
А по поводу индексов - надо всё-таки погонять. Создай эту свою пару табличек, нагенери данных - и вперёд

2) Однозначно удалять - будет быстрее. 2 млн всё-таки...

← →
Yuri Bezsonov © (2003-03-16 19:23) [2]

попробую создать, давно хотел проверить FireBird на большие объемы

← →
big_rom © (2003-03-16 19:49) [3]

если можно раскажи как он у тебя ведет при таких объемах хотя выборка по телефону абонета будет вестись?
должна быть нормально
у меня похожая задача, но оракул. Хотя как ты сам понимаешь для таких объемов надо что-то более мощьное чем Fb

← →
Yuri Bezsonov © (2003-03-16 21:09) [4]

сейчас рисую БД и программу, завтра начну заливку данных и тогда посмотрю. Я однажды пробовал тектовыми данными залить (10 млн.), то бегало довольно шустро (выборка по тел. абонента около 5 сек.), теперь попробую с реальным биллингом.

← →
Rad © (2003-03-16 22:17) [5]

Просим, просим :)

В конференции ( http://www.ibase.ru/v6/conf/conf.htm) неоднократно была речь про биллинг. В целом, говорят, что вполне можно; у кого-то даже база в районе 18 Гб (почём купил, по том и продаю :)).
Но есть нюансы :) (с)
Например, все подключения желательно с запретом сборки мусора (который будет появляться при массовом удалении). А заливать - не напрямую insert в нужную таблицу, а через external table. Ну и т.д.

Yuri Bezsonov © (16.03.03 19:23)
Да нормально работает, есть сведения о базах размером в 980 Гб, для взлома RSA, правда платформа другая не Wintel

а можно подробнее о ключе "с запретом сборки мусора", где это выставляется (для IBX)? А то мною написан биллинг для пейджинговой/транкинговой компании (D7, FB) и при закрытии месяца и перемещении переговоров из временных таблиц в таблицы истории возникают капитальненькие задержки пока сервере там прочухается с удаленными данными.

Ну, я вот так вот сразу не могу вспомнить, поэтому RTFFAQ и FM ;))) на http://www.ibase.ru и в PDF от Interbase
Ключ выставляется, вроде как, у TIBDatabase (или TIBTransaction?) в Params

Максимальная скорость выборки Найти похожие ветки