Выбор сервера БД?

← →
sw (2004-10-24 18:51) [0]

Есть программа для работы c Interbase базой,
на данный момент в ней уже порядка 5000-6000 тыс. записей.
На одном компьютере оставлена база, остальные (еще 5 комп-ров) обращаются как к сетевому.
В последнее отчеты (QR 1-2 страница) генерируются вообще по минут 5-6, а так как объем базы
в будующем будет нарастать возникли вопросы:
Какие коренные изменения можно(нужно) сделать чтобы как то повлиять на эту ситуацию.
Может быть бросить IB и пока не поздно переписать под MySQL или еще что-нибудь(измениться ли что-то от этого?)
Очень хочеться услышать советы от тех кто разрабатывал подобные проекты.

← →
sniknik © (2004-10-24 19:00) [1]

5-6 тысяч для любого sql-го движка это несерьезно. если 5-6мин генерируется 1 отчет то чтото явно не так в логике построения, и смена одного движка на другой ничего не изменит.

← →
Sergey_Masloff (2004-10-24 19:10) [2]

Бросай все на фиг пока не поздно ;-)

← →
Nikolay M. © (2004-10-24 19:58) [3]

> 5-6 тысяч

Не 5-6 тысяч, а 5000-6000 тыс.
Правда, что такое 5 млн в БАЗЕ - мне лично это непонятно. 1 000 таблиц по 5 000 записей в каждой? Или 5 таблиц по миллиону в каждой?

> если 5-6мин генерируется 1 отчет то чтото явно не так в
> логике построения

В общем случае, оно, конечно, так, но бывает, что начальство в один прекрасный момент начинает хотеть какой-нибудь исторический отчет лет за 5 с (не)реализованными прибылями/убытками, движением LIFO/FIFO и чтобы еще всякие рюшечки на каждый день считались - тут не создавая парочу дополнительных таблиц такое быстро не построить :(

← →
sw (2004-10-24 21:54) [4]

> Не 5-6 тысяч, а 5000-6000 тыс.

сорри ввел вас в заблуждение, я имел в виду конечно 5-6 тыс.

> 5-6 тысяч для любого sql-го движка это несерьезно. если
> 5-6мин генерируется 1 отчет

просто база то на одном компе, а когда по сети сразу 5 отчетов надо вот и задумывается.

Просто учитывая то что объем данных будет увеличиваться, чтановиться страшно, что будет через месяц.

← →
DrPass © (2004-10-24 22:38) [5]

> сорри ввел вас в заблуждение, я имел в виду конечно 5-6
> тыс.

У меня, например, 700 000 записей на P4-1.7, одновременно работают до 30 пользователей. Никаких проблем со скоростью. Скорее всего, у тебя просто неправильно построена логика

← →
Nikolay M. © (2004-10-25 09:53) [6]

> я имел в виду конечно 5-6 тыс.

Несерьезная цифирь. Если, конечно, это все не крутится на каком-нибудь 486-м компе с Вынь95 и мозгами на 64МБ.

← →
Romkin © (2004-10-25 11:02) [7]

Nikolay M. © (25.10.04 09:53) [6] На любом компе несерьезно :))
sw (24.10.04 21:54) [4] Так. А что, на компьютере с БД тоже есть приложение, и соединяется локально? Так нельзя. Все соединения с БД должны быть одинаковыми, то есть, соединяются по сети -> и локально тоже, плиз, через localhost. Второе: IB - не файл-сервер, и запросы выполняются на компьютере с сервером, по сети идет только результат.
Третье: Откуда такой старый сервер?! ужас...
Кстати, а действительно, БД не на 486 установлено? Сколько памяти?

← →
Карелин Артем © (2004-10-25 12:14) [8]

Наверняка в отчете много связей master-detail и с индексами напряженка.

← →
sw (2004-10-25 13:55) [9]

по порядку:

> Так. А что, на компьютере с БД тоже есть приложение, и
> соединяется
> локально Все соединения с БД должны быть одинаковыми, то есть, > соединяются по сети -> и локально тоже, плиз, через localhost.

да. хорошо на локальном поменяем на localhost.

> Кстати, а действительно, БД не на 486 установлено? Сколько
> памяти?

Конфигурация машин: клаас 6 машин: P4 2,8 HT включено, HDD 80GB(FAT32) ОЗУ 256MB

> Второе: IB - не файл-сервер,

еще раз тысяча извинений, мы совсем недавно убрали IB6.5 и поставили Firebird 1.5.0
Еще такой симптом был, и на локальных машинах и на сетевых когда открывали прогу, ооочень долго соединялся с базой потом на сервере когда запустили IBExpert зерегестировали там нашу базу, соединение стало происходить мгновенно. Ну а вот в последнее время чего-то отчеты стали задерживаться.

← →
DSKalugin © (2004-10-25 20:10) [10]

Причины может быть 2е:
0-отсутствие индексов
1-если они есть - Разбаллансировка индексов
2-поломалась сама БД

решения
для 0 : проанализировать грузовые запросы и построить индексы по полям таблиц, для которых выполняется сортировка в этих запросах (order by ...)

для 1 для всех таблиц в крайнем случае только для частомодифицируемых и больших выполнить
alter index <имя_индекса> inactive;
alter index <имя_индекса> active;
т.е перестроить их

протестируй базу на предмет ошибок утилиой gfix, если они имеются - лечи. Но это уже отдельная большая тема :-))
Удачи

← →
DSKalugin © (2004-10-25 20:16) [11]

да, и еще. На МуСКуЛ переходить не стоит - однозначно :-))
СУБД FireBird мощней на порядок.

При правильной организации структуры БД и клиентского ПО все летает со свистом. Вот у меня самая большая табличка прайсов содержит 4млн с гаком записей и она не одна такая большая. Сам файлик БД=900Мб ... Работаем в сети из 8 чел без тормозов :-))

← →
DrPass © (2004-10-25 21:44) [12]

> 0-отсутствие индексов
> 1-если они есть - Разбаллансировка индексов
> 2-поломалась сама БД

0 и 1 - исключено. 5-6 тыс. записей - это ничтожное количество. На P4-2.8 они будут без единого индекса обрабатываться за доли секунды, каким бы сложным не был запрос.
2 - тоже маловероятно, и трудно не заметить. Зато вполне вероятен вариант, что человек использует в своей программе IBTable да еще в связках мастер-деталь, и таким образом при каждом подключении гоняет всю базу взад-вперед по сети

← →
DSKalugin © (2004-10-26 12:56) [13]

2 DrPass
Здравствуй дорогой земляк, Женя :-)))
Согласен вполне с твоим замечанием. Но с "каким бы сложным не был запрос" позволь не согласиться. Если делать внешние объединения, а тем более full outer join то они тормознут любую машину. У меня кстати тоже П4 2,8

← →
msguns © (2004-10-26 13:08) [14]

А как вообще-то сама сеть ? Простое копирование идет нормально по скорсти ? Какие винды стоят ? Если старше 98, то правильно ли прописаны учетные записи и т.д.

← →
Sergey13 © (2004-10-26 13:34) [15]

2sw (24.10.04 18:51)
>В последнее отчеты (QR 1-2 страница) генерируются вообще по минут 5-6
Может все таки последует описание хотя бы одного такого отчета.

← →
Romkin © (2004-10-26 18:03) [16]

Это какой же должен быть запрос, чтобы так долго выполняться?
Кстати, если сервер ХР или 2003, то расширение файла БД надо бы поменять на fdb. Дело в том, что gdb эти системы считают защищаемым файлом, и при каждом изменении копируют. Поэтому так долго соединяется обычно :)
Примечание: у меня тяжелейщий отчет, который крутит несколько раз выборку из таблиц по полтора миллиона записей, выполняется за несколько секунд на PIII-600 :)

← →
sw (2004-10-27 16:16) [17]

> А как вообще-то сама сеть ?

сеть правда 10Мбит/с(именно 10 а не 100).

> Какие винды стоят ?

Win XP Proff. RUS учетная запись у всех одинаковая admin (права администратора) Доступ к дисками открыт.

> Кстати, если сервер ХР или 2003, то расширение файла БД
> надо бы поменять на fdb. Дело в том, что gdb эти системы
> считают защищаемым файлом, и при каждом изменении копируют.
> Поэтому так долго соединяется обычно :)

Попробовали так сделать. Изменили расширение, снова прописали в IBExpert, в программе изменили сервер на remote(localhost). Реакции ноль, соединяется также долго.
По началу когда IBExpert только поставили мгновенно открывал.
После того, как раза два рубанули свет, вот и пошло. Хотя при запуске только связь с базой данных (Connect & Open ) и запуск транзакции (программно).

В базе используется 19 таблиц между ними установлены связи "Главный- подчиненный" проиндексированны соответственно по первичным и вторичным ключам. В программе при построении запросов используются компоненты IBQUERY (есть ли какая-нибудь альтернатива?) Все компоненты (IBTable(19 шт. ) и IBQuery ( в кол-ве 20 шт.) и т.д.) помещены в DataModile(модуль данных).

ну а вот этот отчет (писали не сами (SQL Builder))

SELECT DISTINCT Students.SURNAME, Students.NAMESTUD, Vedomost.KOMPONENTA1, Vedomost.KOMPONENTA2, Vedomost.KOMPONENTA3, Vedomost.KOMPONENTA4, Vedomost.KOMPONENTA5, Vedomost.KOMPONENTA6, Vedomost.KOMPONENTA7, Vedomost.SUMBAL, Students.SHIFRSP, Vedomost.MAXBAL
FROM TEACHERS Teachers
INNER JOIN VEDOMOST Vedomost
ON (Teachers.PAROLTEACH = Vedomost.PAROLTEACH)
INNER JOIN ZAYAVKIKAZ_CHOISE ZayavkiRUS_CHOISE
ON (ZayavkiKAZ_CHOISE.PAROLTEACH = Teachers.PAROLTEACH)
INNER JOIN TOTALDISCIPL Totaldiscipl
ON (Vedomost.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN STUDENTS Students
ON (Students.PAROLSTUD = Vedomost.PAROLSTUD)
INNER JOIN REGISTER_COURSES Register_courses_1
ON (Register_courses_1.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN ChoiseDiscipl choiseDiscipl
ON (choiseDiscipl.CODEDISCIPL = Totaldiscipl.CODEDISCIPL)
INNER JOIN SPESIALNOSTI Spesialnosti
ON (Spesialnosti.SHIFRSP = Students.SHIFRSP)
INNER JOIN SPES_KORPUS Spes_korpus
ON (Spes_korpus.SHIFRSPES = Spesialnosti.SHIFRSP)
WHERE (Teachers.FAMILIA = :prmFamTeach)
AND (Teachers.NAME = :prmNameTeach)
AND (Totaldiscipl.NAMEDISRUS = :prmNameD)
AND (Students.LANGUAGE = :prmLang)
AND (Vedomost.NBLOCK = :prmNBlock)
AND (Vedomost.SEMESTR = :prmSem)
AND (ZayavkiKAZ_CHOISE.KORPUS =:prmKorpus)
AND (Spes_korpus.KORPUS =:prmKorpusS)

← →
Sergey13 © (2004-10-27 16:24) [18]

2[17] sw (27.10.04 16:16)
>После того, как раза два рубанули свет, вот и пошло
А B/R нормально?

>ну а вот этот отчет (писали не сами (SQL Builder))
И что показывает план?

← →
Erik1 © (2004-10-27 17:31) [19]

IBTable нахрен выкинуть, переходи на компоненты FIB.

← →
sw (2004-10-28 08:13) [20]

> IBTable нахрен выкинуть, переходи на компоненты FIB.

это повлияет на ситуацию?

← →
Zacho © (2004-10-28 11:03) [21]

Змена TIBTable на TIBDataSet - вполне возможно, повлияет. Переход с IBX на FIBPlus сам по себе большого "ускорения" не даст.
И всё-таки, ответь на вопрос Sergey13 © (27.10.04 16:24) [18]

← →
vv_fran (2004-10-28 14:23) [22]

Базу полечить, сделать bacup-restore.
Переписать запрос без INNER JOIN , от него и от DISTINCT - основные тормоза. Проверить план. Он может сначала выбирать из самой большой таблицы, а потом из мелких - сделать наоборот. У меня была такая проблема, вылечилось внесением плана в SQL.

← →
sw (2004-10-29 13:55) [23]

> А B/R нормально?

не совсем понимаю о чем идет речь ?

Запустили вышеуказанный отчет с параметрами из IBExpert с сетового комп-ра: получена 21 запись:

Plan
PLAN SORT (MERGE (SORT (SPES_KORPUS NATURAL),SORT (JOIN (TOTALDISCIPL INDEX (TOTALDISCIPL_IDX1),VEDOMOST INDEX (VEDOMOST_IDX1,RDB$FOREIGN27),TEACHERS INDEX (RDB$PRIMARY4),ZAYAVKIKAZ_CHOISE INDEX (RDB$FOREIGN48),STUDENTS INDEX (RDB$PRIMARY13),SPESIALNOSTI INDEX (RDB$PRIMARY6),CHOISEDISCIPL INDEX (RDB$FOREIGN21),REGISTER_COURSES_1 INDEX (RDB$FOREIGN24)))))

Adapted Plan
PLAN SORT (MERGE (SORT (SPES_KORPUS NATURAL),SORT (JOIN (TOTALDISCIPL INDEX (TOTALDISCIPL_IDX1),VEDOMOST INDEX (VEDOMOST_IDX1,FK_VEDOMOST),TEACHERS INDEX (PK_TEACHERS),ZAYAVKIKAZ_CHOISE INDEX (FK_ZAYAVKIKAZ_CHOISE),STUDENTS INDEX (PK_STUDENTS),SPESIALNOSTI INDEX (PK_SPESIALNOSTI),CHOISEDISCIPL INDEX (FK_CHOISEDISCIPL1),REGISTER_COURSES_1 INDEX (FK_REGISTER_COURSES)))))

------ Performance info ------
Prepare time = 16ms
Execute time = 1s 546ms
Avg fetch time = 73,62 ms
Current memory = 1 436 348
Max memory = 1 879 972
Memory buffers = 2 048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 51 959

самая большая таблица здесь это REGISTER_COURSES_1, остальные на порядок меньше.

> вылечилось внесением плана в SQL.

никогда с этим не сталкивались, как это сделать?

← →
AZDesign (2004-10-29 14:28) [24]

Начни с мелочей:
Установи файловую систему NTFS, а то на FAT32 удивительно что ты не потерял всю БД, да еще после выключения питания.
И на сервак нужно поставить нормальный UPS, чтобы аккуратно остановить.

Проводи переодически дефрагментацию - судя по твоим словам, систему поставил по умолчанию и не задумываясь. Посмотри в diskeepere как выглядит диск после установки системы - мрак

Конечно 5-6 тысяч записей - это мелочи,
Но все-таки посмотри структуру таблиц, а после запросов, при правильной структуре таблиц и запросы простые, и выполняются быстро. У тебя много сравнений по текстовым полям

То что INNER JOIN - тормоз написано еще у М.Грабера

> То что INNER JOIN - тормоз написано еще у М.Грабера

Чушь. Так можно сказать, что любой JOIN - тормоз, давайте делать БД в одной таблице.

2 sw : Почитай статьи на http://www.ibase.ru/develop.htm

>То что INNER JOIN - тормоз написано еще у М.Грабера

Можно привести выдержку ?

Слушай, да??? В IBExpert есть утилита генерации набора данных. Я специально генерировал по 10000 тыс в главной, 20000 в подчиненной, и по 200 в 4 иерархических справочниках. Консолидация осуществлялась за 1,5 с. Но пока добился этого, поменял полностью архитектуру подсчета. Кроме того, для отчётов я бы лучше использовал ХП, быстрее будет.

← →
sw (2004-10-31 15:06) [28]

так все таки есть еще какие то мнения ?

← →
sw (2004-11-01 19:06) [29]

и все таки как "внести план в SQL" ?

>sw (01.11.04 19:06) [29]

См.полный синтаксис SELECT.

[23] sw (29.10.04 13:55)
> > А B/R нормально?
> не совсем понимаю о чем идет речь ?

B/R = Backup/Restore
только, восстанавливай, на всякий случай, в другое место, бывают такие базы, бакап с которых - нерабочий.

Выбор сервера БД? Найти похожие ветки