- •Введение.
- •Лекция1.Введениевклиент-серверныеСубд.
- •InterbaseSqlServer.Общиесведения.
- •Платформы
- •Типыприложений
- •ФайлыбазыданныхInterBase
- •Лекция3.Триггерыихранимыепроцедуры
- •Хранимыепроцедуры(StoredProcedures)
- •Терминаторы
- •Заголовок
- •Телопроцедуры
- •Блоккодапроцедуры
- •Операторприсваивания
- •УсловныйоператорIf…then…else
- •ОператорSelect
- •ЦиклForselecTиSuspend
- •ЦиклWhile…do
- •ОператорыInsert,update,delete
- •ОператорExecuteprocedure
- •Исключения
- •СобытияиоператорPost_event
- •Измененияиудаленияхранимыхпроцедур
- •Примерысозданияивызовахранимыхпроцедур
- •Генераторы
- •Увеличениешагагенератора
- •Триггеры
- •ПеременныеNeWиOld
- •Реализацияавтоинкрементныхключевыхполей
- •Лекция4.Транзакции.Механизмтранзакций
- •Атомарность(Atomicity)
- •Согласованность(Consistency)
- •Изолированность(Isolation)
- •Устойчивость(Durability)
- •Неявныйиявныйстарттранзакций
- •Кактранзакцияработает
- •Уровниизолированноститранзакций
- •Параметрытранзакций
- •Компонентыдоступакданнымивизуальныекомпоненты МеханизмыдоступакБд
- •ПроблемырусскихбукввInterBase
- •Лекция5. Основы языка php. Функции php для работы с субд ИсторияPhp
- •ВозможностиPhp
- •Основнойсинтаксис
- •Разделениеинструкций
- •Комментарии
- •Переменные,константыиоператоры
- •Переменные
- •Константы
- •Операторы
- •Типыданных
- •Типboolean(булевилилогическийтип)
- •Типinteger(целые)
- •Типfloat(числасплавающейточкой)
- •Типstring(строки)
- •Одинарныекавычки
- •Двойныекавычки
- •Типarray(массив)
- •Определениеприпомощиarray()
- •Определениеспомощьюсинтаксисаквадратныхскобок
- •Типobject(объекты)
- •Типresource(ресурсы)
- •Решениезадачи
- •Построениеинтерфейсадлядобавленияинформации
- •Установкасоединения
- •Выборбазыданных
- •Получениеспискаполейтаблицы
- •Отображениеспискаполейвhtml-форму
- •Записьданныхвбазуданных
- •Отображениеданных,хранящихсявMySql
- •Заключение
Платформы
Начинаясмоментасвоеговыхода,т.е.1985года,InterbaseбылUnix-ориентированнымсерверомбазданных.Кмоментувыхода5.0(1997год)множестворанееподдерживаемыхоперационныхсистем(около15)илипрекратилисвоесуществование,илисталиэкзотическими,поэтомуосновныхпортовосталось6.К2000годуихчислоуменьшилосьдо3-Windows,Solaris(SPARC),иLinux.ПортыподNetWare,SCOиHP-UXбылипрекращеныкакнеперспективные.
КромеуменьшенияколичестваподдерживаемыхвариантовОСпривыпускеInterbase6.5былорешеноотказатьсяотстаройархитектурыClassic(пользователь-процесс)впользуболеесовременной-SuperServer(пользователь-thread).
Firebird,какOpenSourceСУБД,преследовалаиныецели,аименнообеспечитьработунамаксимальноразличныхплатформах.ПоэтомуархитектураClassicбыласохранена(какединственная,способнаяобеспечитьмасштабированиенамногопроцессорныхкомпьютерахподUnix),ивдополнениекосновнымплатформамбыливыпущеныдистрибутивы(готовыекомплектыдляустановки)дляFreeBSD,HP-UX,AIX,Solaris(Intel),идажедляDarwin(MacOSX).ВнастоящеевремяведутсяработыпопортированиюFirebirdнаWinCE(покасуществуеттолькоклиентскаячастьFirebirdдляWinCE).
Yaffil,какужеупоминалосьвыше,выпускаетсятолькодляWindows,исейчаснаходитсявзавершающейстадиитестированиеYaffilforWindowsсархитектуройClassic(дляработынаSMP-машинах).
Типыприложений
Конечно,самыеразнообразные.Interbaseдавноужераспространенвнашейстране,изавоевалпопулярностьвпервуюочередьуразработчиков,использующихинструментальныесредыразработкиBorland-Delphi,C++Builder,Jbuilder.Впоследнеевремявсебольшеразработчиков,использующихVisualC,MSAccessидругиесредства,такжеприходяткиспользованиюInterbase.ЭтовпервуюочередьобусловленопоявлениемрядакачественныхODBC-драйверов,атакжеOLE-DB-провайдеров(внастоящеевремяихобщеечислооколо12-ти),позволяющихтесноинтегрироватьработуInterbaseиофисныхсистем.
Благодарятому,чтоInterbaseтребуетналичияминимумафайловдляустановки(6файлов,и2ключавRegistry),атакжевесьманетребователенкресурсам,максимальноеколичествоприложений,егоиспользующих-офисныесистемыобщегоназначения.Этоскладскойучет,бухгалтерия,зарплата,автоматизацияотделовпродаж,имногоедругое.
Такиесистемыкакправилопообъемухранимыхданныхнепревышают300-500мегабайт,атакжеработаютлибоводнопользовательском,либовмногопользовательскомрежимесколичествомпользователейот2до15-ти,илегкопереносятсяскомпьютеранакомпьютер.ОперационнаясистемавданномслучаечащевсегоWindows95или98.Ксожалению,онадежностивэтомслучаесерьезноговоритьнельзя,однакотакиетребованияобычнообусловленыфинансовымипричинами,покоторымпользователиприложенийнемогутустановитьWindowsXP/2Kиз-застарыхпроцессоровилинебольшогоколичестваоперативнойпамяти-32мегабайтRAMдляподобныхсистемвполнедостаточнодажеприработесневыделеннымсерверомдо15-20-типользователей.
Болеесерьезныеприложения,кактовнутрикорпоративныесистемы,системыуправленияпредприятием,биллинговыеит.п.,разумеетсяработаютсбольшимиобъемамиданных(от500мегабайтдо8гигабайт)икакправилоиспользуютUnixвкачествесервернойОС,иникогданеработаютводнопользовательскомрежиме.Приколичествепользователейдо50насерверобычноиспользуютWindows,авслучаяхдо300-400пользователей-обязательноUnix(RedHatLinuxилиFreeBSD)икакправилонадвух-,режечетырех-процессорныхсистемах.ВпроцентномотношениидляданныхсистемвкачествеоперационнойсистемысервераWindowsиспользуетсяв30%случаев,Unix-70%.
ClassicиSuperServer
НаданныймоментсуществуютдвавариантаархитектурыInterBase,которыезначительноотличаютсядруготдругаметодамиработысклиентами,организациейвзаимодействиясобственныхмодулейидажесоставоммодулей,входящихвопределениюреализациюархитектуры.УсловноэтидверазличныхархитектурыназвалиClassicиSuperServer.Рассмотримглавныеособенностиэтихархитектур.
АрхитектураClassicкраткохарактеризуетсяследующейфразой:"каждомуклиенту-собственныйсервер".Этоозначает,чтонакаждоеклиентскоесоединениенакомпьютере-серверезапускаетсясерверныйпроцесс,которыйобслуживаетодногоклиента.Сколькоунасбудетклиентов,установившихсоединения,столькоэкземпляровсерверазапуститсядляихобслуживания(имейтеввиду,чтооднаклиентскаяпрограммаможетоткрыватьсколькоугодносоединенийссервером).
АрхитектуруSuperServerможнопоаналогииохарактеризоватькак"навсехклиентов-одинсервер".Этоозначает,чтовсеклиентскиесоединенияобслуживаютсяоднимсервернымпроцессом,гдекаждымконкретнымклиентомзанимаютсяотдельныепотоки(threads).
Следуетзаметить,чтоделениенаClassicиSuperServerнеозначает,чтоимеютсядвавариантаисходныхкодовдлякаждоговидаархитектуры-одиндляClassicидругойдляSuperServer(иначесовременемполучилисьбыдваразныхсервера).Обаэтивариантаархитектуры(ивсереализацииподразныеОС)производятсяизобщегонабораисходныхкодовспомощьюдирективIfdef,разделяющихплатформенно-иархитектурно-зависимыеучасткикодадруготдруга.Спомощьюнабораэтихдирективопределяют,какойвариантидлякакойплатформысобирать.Естественно,дляразныхОСсборкаосуществляетсясиспользованиемразныхбиблиотекввода-вывода,управленияпамятьюит.д.
ClassicилиSuperServer
Следуетзаметить,картинаскладываетсядовольноинтереснаянакаждыйнедостатокClassicуSuperServerнаходитсядостоинство.Classicрасточителен-SuperServerэкономен,ClassicбезServicesAPI-уSuperServerонесть.
Однако,какивезде,здесьмыимеем"палкуодвухконцах",т.е.,определенныенедостаткиClassicпереходятвопределенныхситуацияхвегодостоинства,апреимуществаSuperServerпревращаютсявнедостатки.Например,рассмотримслучай.когдаNнасимеется,скажем,мощныйдвухпроцессорныйкомпьютер-серверсбольшимколичествомОЗУ,например2Гбайт.ЕслимыустановимнатакуюсистемуInterBaseввариантеSuperServer,тобудемнаблюдатьнеускорение,азамедлениепосравнениюсоднопроцессорнымвариантомтогожесервера!Болеетого,спамятьюбудуттворитьсясплошные"недоразумения"-экономныйSuperServerбудет"отказываться"отогромногоОЗУ.пытаясьвсяческисэкономитьоперативнуюпамять.Какжетак,мощныепроцессоры,многопамяти,aInterBaseSuperServerнеочень-тобыстроработает?
ВотздесьипроявляютсянедостаткиSuperServer.ПроблемусмасштабируемостьюInterBaseархитектурыSuperServerнамногопроцессорныхкомпьютерахдавнопризналивкомпанииBorland.Деловтом,чтоядроSuperServerнерасчитанонаиспользованиенесколькихпроцессоров.СерверInterBaseSuperServerнеможетуправлятьраспределениемпотоковпопроцессорам.ВрезультатеОСпринарастаниинагрузкиначинаетперебрасыватьглавныйсерверныйпроцесс(ibserver.exe)содногопроцессоранадругой.Наэтотратятсясистемныересурсыивремя,чтозамедляетработуInterBase.Стакойситуациейнамногопроцессорныхсистемахборютсяпутем"привязки"(affinity)InterBaseвариантаSuperServerкодномуопределенномупроцессоруиигнорированияостальных.
Надотакжеотметить,чтосраспределениемпамятиуSuperServerтожеимеютсянекоторыепроблемы.Еслимырассмотрим,какSuperServerобслуживаетмножествонебольшихклиентскихзапросов,тоувидимдовольнопривлекательнуюкартину:высокуюпроизводительностьприотносительнонебольшомиспользованииоперативнойивиртуальнойпамяти.Многочисленныеклиентскиезапросысовместно(бездублирования)используюткешированнуюинформациюSuperServer.ЭтаособенностьделаетвариантInterBaseсархитектуройSuperServerособеннопривлекательнымдляWeb-приложений,ориентированныхименнонатакойстильработысбазамиданных.Таккакзапросынебольшие,тоонибыстроотрабатываютиосвобождаютпамятьдляследующихзанимизапросов.
Инаяситуацияскладывается,еслипостановказадачитребуетнарядуспростымидействиямипорегистрацииданныхипросмотруданных,относящихсяккакому-тодокументуилиобозримомумножествудокументов,выполнениязапросованалитическогохарактера,связанныхсосканированиембольшихисложныхвыборокипостроениемнаихосноверазличныхагрегатов.
Эти"тяжелые"запросы"проходятся"побольшомуколичествузаписейитребуютзначительныхресурсовпамятиипроцессорадляихвыполнения.Мыпытаемсяпредусмотретьподобнуюситуациюииспользуеммощноеаппаратноеобеспечение:высокопроизводительныйкомпьютер-серверсбольшимколичествомОЗУ.Однако,SuperServer"непонимает"нашейпредусмотрительностиипривыполнении"тяжелого"запросапытаетсяобращатьсяснимкакснебольшим,т.е.отдаетемудоступнуюкеш-памятьиресурсы,вытесняяприэтомостальныезапросы.Результатпечален-покавыполняетсязапрос-тяжеловес,остальныезапросы"топчутсявочереди".ВсвязисфактическипоследовательнымобслуживаниемпотоковкритическимиучасткамикодаядраInterBaseсерверпростонеимеетдругоговыбора.
ОстаетсясказатьодостоинствахClassic,проявляющихсявэтойситуации.
Во-первых,масштабируемостьархитектурыClassicнанесколькопроцессоров.Из-затогочтокаждыйклиентобслуживаетсянезависимымпроцессом,ОСспокойно"рассаживает"этипроцессыпоразличнымпроцессорам,динамическираспределяянагрузкуприпомощисистемныхсредствуправленияприоритетамипроцессов,стоящихвочередьзаиспользованиемресурсовпроцессора.Врезультатедействительноможнополучитьзначительныйвыигрышотмногопроцессорнойсистемы,соответствующийзатратамнаэтооборудование.
Во-вторых,использованиепамятиипроцессорапривыполнении"тяжелых"запросов.Еслимызапускаемкакой-тооченьинтенсивноработающийсбазойзапрос,тоонвыполняетсяврамкаходногосерверногопроцесса,обслуживающегоданногоклиента,неостанавливаяприэтомостальные.Приоритет"тяжелого"запроса(фактическипроцесса)падаетпомереувеличениявременииспользованияимресурсовпроцессораионначинает"уступатьдорогу"болееприоритетнымпроцессамдругихсоединений,выполняющимкороткиезапросы,т.е.процессорзанятна90%,нонадолю"долгожителя"приходится80-70-60-50-40%...Онзамедляетостальные,этозаметно,нотерпимо,иглавное-упользователяневозникаетощущения"подвешенности".
Вотгденедостаток"избыточность"перетекаетвпреимущество"нагрузочнаяспособность".Какбытонибыло,архитектураClassicзначительнолучшеSuperServerсправляетсястяжелымизапросамиприодновременномобслуживаниинесколькихклиентовиболеекорректнореализуетвытесняющуюмногозадачность,чтопозволяетэффективнеесправлятьсясзапросами-"тяжеловесами".