Платформы

Начинаясмоментасвоеговыхода,т.е.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справляетсястяжелымизапросамиприодновременномобслуживаниинесколькихклиентовиболеекорректнореализуетвытесняющуюмногозадачность,чтопозволяетэффективнеесправлятьсясзапросами-"тяжеловесами".