Повышение скорости работы с БД

Вопросы программирования БД, их оптимизации, резервирования и восстановления данных.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Повышение скорости работы с БД

Сообщение ВТБ! » 11 ноя 2002, 11:39

:rupor: From Administrator: ветка форума выделена из темы RAID U320 SCSI-to-SCSI
BLEEM писал(а):немного про софт (прямого доступа) ???
Например, доступ через ODBC, а дальше - любой удобный инструментарий. Ускорение за счёт фильтрации на сервере и за счёт пакетного доступа (сразу пересылается набор записей). Если установить на сервере SSQL/P.SQL - тогда можно прямо на сервере вязать таблицы (надстройка над Бетривом кривоватая, но если запросы не слишком сложные, то отрабатывает корректно).
Если есть "тяжёлая" отчётность по неактуальным данным, то можно сделать реплику базы на нормальный SQL-сервер (хоть от MS), а синхронизацию делать ночью или днём с некоторой периодичностью (монопольный доступ к базе не требуется).
Как вариант - прилинковать набор ODBC к MS-SQL, чтобы не ставить пользователям клиентскую часть от Первасей, и работать через него.

Аватара пользователя
setar
Site Admin
Site Admin
Сообщения: 1984
Зарегистрирован: 22 авг 2002, 12:03
Откуда: St. Petersburg

Сообщение setar » 11 ноя 2002, 11:52

Могу добавить, что весьма эффективным средством повышения производительности работы с БД является вынесение процедур
(фильтры, отчеты, вычисления) на сторону SQL сервера.

Насчёт "пакетности" обработки данных (если мы говорим об одном и том же) эффективно применение "отображений" или процедур выдающих результат запроса блочно (например постранично).
То есть незачем тянуть по сетке данные за весь период, когда видим на экране лишь один день, пролистывание вызывает подгрузку данных. А так как данных передаётся мизер - визуально задержек не обнаруживается.

BLEEM
member
Сообщения: 21
Зарегистрирован: 30 окт 2002, 13:35
Откуда: Владивосток
Контактная информация:

Сообщение BLEEM » 11 ноя 2002, 12:07

Боюсь, что данный подход не применим, просто софт очень древний и мало того что под Novell. Так ведь и вся клиентская часть это запускаемый на клиентской машине exe-шник !!!

Но в целом наш железный форум переходит в програмерский и связан скорее не с выбором железа, а с методами оптимизации запросов БД для различных случаев. (что тоже не совсем плохо).

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 11 ноя 2002, 12:08

setar писал(а):Могу добавить, что весьма эффективным средством повышения производительности работы с БД является вынесение процедур
(фильтры, отчеты, вычисления) на сторону SQL сервера.
Проблема в том, что SQL-надстройка над Btrieve - штука весьма кривая, ей можно доверять только простейшие вещи. А без надстройки Btrieve и вовсе умеет делать только некоторые простейшие фильтры. Но даже это выйдет много быстрее фильтрации на клиенте, особенно при отсутствии подходящего индекса.
setar писал(а):То есть незачем тянуть по сетке данные за весь период, когда видим на экране лишь один день, пролистывание вызывает подгрузку данных. А, так как данных передаётся мизер - визуально задержек не обнаруживается.
Насколько я понял, с интерактивной работой особых проблем нет.
К тому же переписывать этот софт не имеет смысла вообще - тогда лучше сразу разработать новый на нормальной платформе.

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 11 ноя 2002, 12:16

BLEEM писал(а):Боюсь, что данный подход не применим, просто софт очень древний и мало того что под Novell. Так ведь и вся клиентская часть это запускаемый на клиентской машине exe-шник !!!
Я именно этот случай и имел ввиду.
У меня точь в точь такая же ситуация, отягощённая использованием в Btrieve типа данных decimal(31, 10) (ODBC и SQL-надстройка decimal длиннее 10 байтов на дух не переносят - а тут 16) и разнесением архивов по отдельным таблицам (переключение между ними с прилинкованного сервера выглядит неэстетично).

Аватара пользователя
alias
Junior member
Сообщения: 9
Зарегистрирован: 24 авг 2002, 01:03
Откуда: Питер
Контактная информация:

Сообщение alias » 13 ноя 2002, 14:19

Господа!
Нельзя так!
Для начала нужно определиться что вы хотите ускорить и на какой СУБД (для каждой свой подход), а уж потом флейм раздувать.

Аватара пользователя
setar
Site Admin
Site Admin
Сообщения: 1984
Зарегистрирован: 22 авг 2002, 12:03
Откуда: St. Petersburg

Сообщение setar » 13 ноя 2002, 14:28

alias писал(а):Господа!
Нельзя так!
Для начала нужно определиться что вы хотите ускорить и на какой СУБД (для каждой свой подход), а уж потом флейм раздувать.
Есть вопрос - то alias
Имеется Interbase Server (Firebird), крутится на 2х процовой ксеоновой машине с 512М памяти, отдельный SCSI винт. ОС - RedHat 7.3 (SMP)
Дык вот недавно выяснилось что WIN server такой же версии поставленный на средненькую тачку P4 1.4 / 512м / IDE HDD работает быстрее процентов на 30% :ups:
Что бы это означало, и как оптимизить работу Firebird`a под linux :?:

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 13 ноя 2002, 15:48

Уважаемый alias!
Просьба не выдвигать в дальнейшем необоснованных обвинений (во флейме, например), не ознакомившись до того с содержимым ветки (начало ветки - см. ссылку в первом посте данной ветки).
setar
Можно я отвечу ? ;)
Все зависит от конкретных настроек и конкретной базы. Однако, есть кое-что навскидку:
1.Для IB(Firebird) под Linux есть два типа архитектуры: Classic и SuperServer. Разница - Classic организует под каждого клиента процесс, SuperServer - нить (thread). Firebird под Windows - только SuperServer. Для Linux есть и то и другое, но, насколько мне известно, чаще применяется именно Classic.
2. Настройка всей связки - ОС, файловая система ОС, файловый кэш ОС, сервер IB (приоритет, выделение памяти). Есть статья на www.ibase.ru - конфигурирование памяти и семафоров для архитектуры Classic (unix), ну и можно еще просмотреть раздел Для разработчика на том же сайте - много полезного по IB вообще и FB в частности.

Аватара пользователя
alias
Junior member
Сообщения: 9
Зарегистрирован: 24 авг 2002, 01:03
Откуда: Питер
Контактная информация:

Сообщение alias » 14 ноя 2002, 14:34

to setar
a_shats полностью прав.
но есть такой серверок клон IB YAFFIL называется под LINUX не нашел
а под M$ есть вот он фору практически в любом варианте даст LINUX серверу.
какой тип сервера лусше поставить неплохо описано в книге "Мир InterBase"

Рекомендации по выбору архитектуры: Classic или SuperServer?
Прочитав предыдущий раздел, читатель может ощутить необходимость немедленно перейти на сервер InterBase с архитектурой Classic. Однако стоит побороть это иррациональное стремление и хорошенько все взвесить. Ведь нельзя сказать, что Classic (или SuperServer) - однозначно лучший выбор. У каждой архитектуры есть своя «весовая категория», в которой ее использование даст наилучшие результаты. Поэтому задача разработчика - правильно определить эту категорию.
Никакой разницы в структуре базы данных и в логике проектирования клиентских приложений при использовании различных вариантов архитектуры InterBase нет. При разработке можно спокойно воспользоваться SuperServer-сервером как наиболее экономичной версией InterBase. Это особенно важно, когда сервер стоит прямо на рабочей станции у разработчика.
Необходимость выбора той или иной архитектуры InterBase становится актуальной, когда разработка приложений базы данных близится к концу и готовая база данных и программное обеспечение, работающее с ней, готовятся к передаче заказчику.
Избежать больших проблем с выбором архитектуры позволяет нам гибкость InterBase. Выбирая любую из архитектур, можно быть уверенным, что этот выбор не является фатальным и его всегда можно изменить.
Итак, что выбрать? Для начала давайте условимся, что речь идет о действительно серьезных задачах, содержащих большое количество данных, для которых критична производительность. Ведь если речь идет о программе учета накладных, которой одновременно пользуется не более пяти человек, то выбор очевиден - это SuperServer. Это сэкономит ресурсы компьютера-сервера и даст отличную производительность. Можно сказать, что SuperServer - это выбор по умолчанию, т. е., если вы не знаете, что выбрать, выбирайте SuperServer, и скорее всего он удовлетворит потребностям 80% задач.
Но есть и такие 20 % задач, для которых критически важна масштабируемость при большом количестве обслуживаемых клиентов. Именно для них нужно осознанно производить выбор между архитектурами Classic и SuperServer.
Первым критерием выбора является выполняемая задача. Ответьте для себя на следующий вопрос: каково максимальное число клиентов будет единовре-менно подсоединено к вашей базе данных? Помните, что это число не равно числу пользователей системы, поскольку обычно даже в пиковые моменты одновременно подсоединяются к базе данных около 70-80 % от общего числа пользователей. Затем выясните, запросы какого характера выполняются в вашей системе. Это сильно зависит от того, ближе ли разработанный вами продукт к системе OLTP (on-line transaction processing), которая рассчитана на обработку множества небольших одновременных операций по занесению в базу данных, или же он ближе к системе DSS (decision support system), где преобладают дли-тельные запросы, затрагивающие большое количество данных. В первом случае важно обработать множество запросов за короткий промежуток времени, ром - |ибко распределить нагрузку, чтобы сервер хорошо отрабатывал «тяжелые» запросы, т. е требуется не быстрота а нагрузочная способность
(быстро не надо: никто не требует быстроты от аналитических выборок
и годовых отчетов). гстроты от аналитических выборок
Если у Вас OLTP-подобная система, то добовляем плюс в пользу SuperServer,
если DSS, то Classшc. Также поступаем и с количеством активных пользователей: если это число более 50, то Classic становится однозначно оптимальнее - ведь скорее всего систему такого масштаба будет обслуживать высокопроизводительный многопроцессорный сервер.
Следующим критерием является оборудование. Если вы счастливый обладатель многопроцессорного сервера, то на этом муки выбора заканчиваются: однозначно следует выбрать Classic, вне зависимости от количества других плюсов и минусов. Classic в полной мере позволит ощутить преимущества нескольких процессоров.
Если процессор один, то надо продолжать выбирать. Сколько у вас оперативной памяти? Если больше 1 Гбайт, то ставим плюс Classic-архитектуре, если меньше - плюс SuperServer. Каков объем базы данных? Если он невелик, т. е. может 2-3 раза целиком поместиться в оперативной памяти компьютера-сервера, то следует поставить плюс SuperServer: его совместно используемый кеш позволит загрузить базу данных практически целиком в ОЗУ.
Теперь давайте подсчитаем плюсы. Большее количество у той или иной архитектуры следует рассматривать как возможный признак того, что она больше подойдет для вашей задачи. Но в любом случае (за исключением многопроцессорных систем, где однозначно выигрывает Classic) необходимо протестировать производительность обеих архитектур с вашей базой данных на конкретно конфигурации аппаратного обеспечения (тому, как настроить и оптимизиров ваш конкретный компьютер-сервер и функционирующий на нем InterBase, по-священа глава «Оптимизация работы InterBase» (ч. 4)). Никто не может заранее предсказать, какая именно архитектура станет наилучшим решением
конкретной системы СУБД, но тот факт, что у вас есть выбор, представляет соб-бой несомненное достоинство InterBase... для тех, кто сумеет воспользоваться этим выбором.


to a_shats извеняюсь был не внимателен
== Рожденный в СССР ==

Аватара пользователя
setar
Site Admin
Site Admin
Сообщения: 1984
Зарегистрирован: 22 авг 2002, 12:03
Откуда: St. Petersburg

Сообщение setar » 14 ноя 2002, 14:42

:lol:
Если вы счастливый обладатель многопроцессорного сервера, то на этом муки выбора заканчиваются: однозначно следует выбрать Classic, вне зависимости от количества других плюсов и минусов. Classic в полной мере позволит ощутить преимущества нескольких процессоров.
Вот оно то самое - у нас стоит SuperServer :?
Будем менять :)

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 15 ноя 2002, 11:20

Имхо, не стоит так категорично: разница между архитектурами Classic и SuperServer втом, что Classic выделяет под каждого пользователя процесс, SuperServer - нить(thread). Если дело только в этом, то получится, что в Windows нити лучше реализованы, нежели в Linux ;) .
Дело, скорее, в тонкой настройке работы с памятью (лучше зафиксировать в оперативке весь блок памяти, выделенный IB), размера страниц (чем больше размер страницы БД - тем быстрее будут работать отчеты и медленнее - сбор данных и наоборот) и т.п. На сайте, который я назвал в посте выше, можно найти все необходимые материалы по настройке.

Аватара пользователя
setar
Site Admin
Site Admin
Сообщения: 1984
Зарегистрирован: 22 авг 2002, 12:03
Откуда: St. Petersburg

Сообщение setar » 18 ноя 2002, 19:03

:D Простой переход на архитектуру ClassicServer даже без тюнинга параметров запуска дал прирост производительности 20% - это субъективная оценка полученная с секундомером в руке на выполнении тяжелого отчёта (По нашим представлениям этот отчёт уже достаточно оптимизирован, и упирается лишь в производительность сервера)
:?: Кстати каким образом можно оценить скорость работы БД более правильными методами

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 21 ноя 2002, 13:59

www.tpc.org
См. TPC-C (OLTP) и TPC-D (OLAP)
Это насчет "правильных" методов ;)
А так - все верно - измеряется производительность сервера на задачах, характерных именно для этой БД (разница лишь в том, что при измерении производительности на аналитике (отчетах) запускаются 2-4 отчета параллельно, а на сборе данных - столько клиентских скриптов, сколько должно быть - по максимуму - активных пользователей данного приложения БД.

BSD
Junior member
Сообщения: 2
Зарегистрирован: 10 мар 2003, 06:23

Сообщение BSD » 27 мар 2003, 02:23

alias писал:
... Если вы счастливый обладатель многопроцессорного сервера, то на этом муки выбора заканчиваются: однозначно следует выбрать Classic, вне зависимости от количества других плюсов и минусов. Classic в полной мере позволит ощутить преимущества нескольких процессоров.
........ Но в любом случае (за исключением многопроцессорных систем, где однозначно выигрывает Classic) ....
Eto sovsem ne ochevidno:
V sluchae Linux, threads realizovani s pomoshiu system call 'clone'
(ochen' gibkaia variatsia na temu 'fork'). T.e. na kajdii potok
sozdaiotsa novii process. Tak-chto dlia SMP v dannom sluchae
gorazdo bolshuu rol' igraet strategia ispolzovania shared memory.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 27 мар 2003, 10:52

BSD
Загляните на http://firebird.sourceforge.net
Там (оттуда копать ;) ) лежат исходники Firebird (одного из нынешних диалектов Interbase).
Сейчас, если я правильно помню, под Linux оставили только Classic.
Однако, насколько мне помнится, там (в SuperServer) всю жизнь пользовали именно fork(). Вроде бы это было связано с желанием сохранить многоплатформенность.

Ответить

Вернуться в «Серверы - ПО, Базы Данных и их использование»