1 что такое субд. Базы данных и субд

Финансовый аспект внедрения 1С на ORACLE

Первый вопрос, который мне хотелось бы рассмотреть - это финансовый аспект внедрения 1С на ORACLE. У большинства сложилось такое мнение, что внедрение 1С на ORACLE очень дорогое, и что в принципе, если в проекте использовать СУБД ORACLE, то стоимость проекта вырастет на порядок. Это не совсем необоснованное мнение, однако, все-таки хотелось бы разобраться подробнее, из чего будет складываться стоимость проекта, если для его реализации будет выбрана СУБД ORACLE.

Первое - это, конечно, лицензии. Поскольку я не эксперт по лицензированию, я просто набрал в интернете ORACLE и MSSQLServer, посмотрел стоимость лицензий для одного человека (не по SOCKET, не по памяти, не по серверам - а в наиболее упрощенном варианте) и получил приблизительно такие суммы. Как видим, одна лицензия ORACLE стоит даже дешевле, чем аналогичная ей лицензия MSSQL . Для сравнения использую редакции StandartEditionONEORACLE и StandartEditionMSSQLServer, потому что это начальные редакции, и 1С нам большинство «фич», которые есть в Enterprise версиях, запрещает к использованию.

OC на сервер для ORACLE вообще бесплатна (условно бесплатна, конечно) - это LINUX . Дело в том, что ORACLE - это продукт, который изначально разрабатывался под LINUX, и он изначально «линуксовый» - посмотрите на структуру каталогов, на кучу настроечных файликов, на JAVA-интерфейс, - вы сразу это заметите. Для Microsoft - это, соответственно, WindowsServer (другого варианта у нас нет), но даже в StandartEdition версии он все равно стоит 1000 руб.

Сам сервер (железо) - конечно, составит большую долю стоимости проекта, но для сравнения стоимости внедрения СУБД его стоимость нас волновать не будет.

А вот последний пункт (наличие DBA - ORACLEDBAилиMSSQLDBA) - он самый интересный. Если мы говорим о внедрении на MSSQL - то все-таки у большинства были внедрения, в которых можно было обойтись без DBA, поскольку MSSQLServer - это продукт не такой сложный, у него хорошее usability, хорошая методология Microsoft, с его администрированием более-менее можно разобраться самому. Для ORACLE - на маленьких проектах, конечно, есть шанс - на больших проектах (от 100 пользователей), конечно, уже необходим отдельный человек, который будет следить за работой СУБД , который будет администрировать ее работу, будет ею управлять. Графические средства администрирования СУБД ORACLE не такие мощные, не такие красивые и не такие замечательные, как в MSSQLServer.

Первое понятие - это схема ORACLE и база данных.

Очень часто, при обсуждении работы 1С на ORACLE, принимается за правило такое упрощение, что для ORACLE база данных это схема. Это самое популярное заблуждение. В нем корень всех проблем (очень многих проблем работы 1С с СУБД ORACLE).

Схема - это логическая сущность. Это группа таблиц. База данных - это физическая сущность. Это группа файлов. Ставить между ними знак равенства - никоим образом не правильно!

Поэтому в ORACLE есть проблемы с резервным копированием, с ведением логов, с перемещением баз данных на отдельный диск и т.д.

1С, для упрощения себе жизни, выбрала схему как инструмент для создания в консоли кластера. Чтобы можно было из 1С создать базу данных, они выбрали вместо нее схему. Дело в том, что создание базы данных в ORACLE - это нетривиальный процесс. Каждая база данных в Oracle - это отдельный сервис, отдельный instance. 1С все это упростила, и для отдельной базы данных использует отдельную схему. Мне кажется, что 1С выбрала неправильную политику. Это некоторый такой обман пользователей. Нет знака равенства между понятиями Схема и База данных. Крупное решение на ORACLE может нормально функционировать только в том случае, если у вас на одном сервере, на одном Instance есть только одна база 1С. Другого варианта нет.

Версионность.

Не буду подробно останавливаться. Скажу только, что есть версионные СУБД и блокировочные СУБД.

В блокировочных СУБД, если одна транзакция уже начала изменять данные, то другая транзакция в этот момент вынуждена ждать. В версионных СУБД другая транзакция может прочитать данные.

Версионная СУБД - это хорошо, блокировочная СУБД - плохо. Однако, версионная СУБД - это не панацея от всех бед, потому что если вы в результате ее использования получите предыдущую версию остатков - вы не очень обрадуетесь. Все равно приходится накладывать управляемые блокировки, все равно параллельно записать ничего не сможете - чудес не бывает!

Блокировочные СУБД - это IBMDB2 и MSSQLServer (надо признать, что в MSSQLServer есть режим Read_Commited_Snapshot, - некая пародия на версионирование - его используют в версии платформы 1С 8.3, еще его используют в MicrosoftDynamics AX). Версионные СУБД - это ORACLEи PostgreSQL. Про Postgre ничего плохого сказать не хочу, это бесплатная СУБД, проект энтузиастов. Лично я не рассматриваю его как СУБД для серьезных проектов. Мне кажется, что среди версионных СУБД, поддерживаемых платформой 1С, ORACLE - единственный полноценный вариант.

За что же любят ORACLE ?

Сразу скажу, что в статье будет много плохого про эту СУБД, но есть некоторые положительные моменты, характерные чисто для ORACLE.

Обычно - с СУБД ORACLE связывают качества высокой производительности, unbreakable и т.д.

По моему мнению, суть тут немножко в другом. В Oracle применяются две прогрессивные технологии - RACи ASM.

RAC (кластер типа «активен» - «активен») - это полноценный кластер . Именно полноценный, не как мы привыкли в MSSQLServer. Я сомневаюсь, что кто-то смог реализовать распараллеливание запросов в MSSQLServer по разным серверам (или что это в ближайшее время появится). В ORACLE это появилось давно. Это уже обкатанная на крупных системах технология (для действительно больших систем это необходимо). Вoraclestandardeditionone кластеризация RAC в полной мере не поддерживается.

ASM как правило используется совместно с RAC. Это отдельно устанавливаемый на каждый узел кластера мини-экземпляр Oracle, предоставляющий сервисы работы с дисками и позволяющий избежать обращения к диску (позволяющий работать на RAWdevices - дисках без файловой системы - всю работу по кэшированию данных выполняет сам Oracle)

ASM повышает производительность путем автоматического рассредоточения объектов базы данных по большому количеству устройств, увеличивает доступность базы данных, так как позволяет добавлять в базу данных новые дисковые устройства, не останавливая ее.

ASM автоматически, с минимальным вмешательством в работу производит выравнивание распределения файлов по устройствам.

По сути, управление дисками и ФС автоматизировано и отдано на откуп DBA. В случае использования SAN и большого числа дисков - очень актуально.

Логгирование

С логгированием все достаточно сложно. Единственное, на что хотелось бы обратить внимание, что если мы работаем в режиме ArchiveLog - мы можем делать полноценные Backup-ы, а если мы работаем в режиме NoArchiveLog - мы полноценных Backup-ов делать не можем (только средствами impdp и expdp).

В режиме ArchiveLog если у вас на сервере есть более 1 БД 1С и вы хотите использовать полнофункциональные бэкапы - понадобится вторая БД, созданная специальным образом, для восстановления бэкапа, чтобы потом средствами datapump перенести в основной сервер. Вообще в 90% случаев для 1С будет NoArchiveLog. Всё зависит от выбранной стратегии резервного копирования и SLA (если таковой имеется). По сути ArchiveLog - банальная ротация, но без неё online резервное копирование невозможно. Если кончится место для ArchiveLog, 1С тупо упадёт.

Табличные пространства в Oracle

Интересная тема. В MSSQLServer-е табличные пространства - это просто группа файлов. В ORACLE это понятие сильно расширили, т.к. в ORACLE по традиции для файлов нужно увеличивать начальный размер и приращение, т.е. для ТП можно задать размер блока, bigfile, ведение логов. Если не bigfile, то ограничение 32 ГБ.

Табличные пространства 1С:

Data - Сами таблицы
Index - индексы
Index_Big - размер блока 16КБ. Если индекс не удаётся создать в Index, платформа пытается создать его в Index_big. Еще нужно установить размер кэша для 16 КБ блоков. Собственно, размер блока можно варьировать. Чем меньше - тем быстрее запись. Чем больше, тем быстрее чтение больших объемов
LOB - хранилища значений и строки неограниченной длины. Очень хорошо, что разделили. Теперь можно, не нарушая лицензионного соглашения, вынести весь мусор на отдельный диск
Temp - tempdb. Нужен очень быстрый дисковый массив.

Хотелось бы обратить внимание на табличное пространство 1С V81C_LOB. ORACLE на данный момент времени единственная СУБД, в которой есть полноценное хранение файлов и строк неограниченной длины. В ORACLE мы можем файлы и строки неограниченной длины переложить на отдельный диск. Что это значит? Мы можем, к примеру, внедрять 1С:Документооборот в больших компаниях, на больших объемах данных и при этом не ставить эту галочку, которую все любят - «хранение файла во внешнем хранилище». ORACLE позволяет нам хранить все наши файлы непосредственно в базе данных (эта база данных будет размещена на нескольких дисках). Самое интересное, что не только ORACLE - любая СУБД нам позволяет это сделать, просто лицензионное соглашение 1С накладывает ограничения - для любых других СУБД стандартных средств переноса файлов и строк неограниченной длины на отдельное дисковое пространство сервера у нас нет. А в случае с ORACLE 1С догадались выделить для этого отдельное табличное пространство V81 C_ LOB . Замечательная «фича».

Еще несколько основных понятий:

REDOLOG (текущий лог) - Нужно следить за размером свободного пространства. Можно отключать. Oracle «не прощает ошибки». Если заканчивается место под логи - просто «падает». Если нет Backup-ов, то и логи не нужны
ALERTLOG(технологический журнал) - / u01/ app/ oracle/ diag/ rbms/ main/ OID/ alert смотреть в него придётся даже если есть dba
LISTENER (организация сетевого доступа) - при работе с MSSQLServer мы не привыкли, что сетевой доступ к базе - это отдельное приложение
SYSDBA (режим работы с базой) - root для oracle - обычные действия в этом режиме недоступны. Режим только для администратора.

С основными понятиями разобрались. Теперь перейду к «основной статье» - буду рассказывать конкретно о работе ORACLE с 1С.

Проблемы разработки 1С на ORACLE

Первая и самая главная - специфичная лингвистическая сортировка . Если мы говорим о работе в ORACLEс текстовыми строками, то это, наверное, главная проблема .

Платформа 1С использует одинаковые механизмы работы со всеми вариантами СУБД (в том числе с файловой версией). Соответственно, сортировку строковых значений в таблицах баз данных платформа 1С реализует по своим правилам. В частности, если в строке присутствуют точка или запятая, то для 1С это будет влиять на сортировку. В ORACLE, которая ориентирована на стандарты, точка или запятая на сортировку не влияют. Из-за такой элементарной проблемы 1С пришлось городить целый «огород» - использовать функцию NLSSORT для того, чтобы была своя сортировка. А уже использование этой функции повлекло существенные модификации.

Любой индекс и любая сортировка по строке, которые у вас есть, будут использовать функцию NLSSORT (неявно ее вызывать) . Использование этой функции вызывает также обязательность установки для работы ORACLE с 1С специфичного приложения Lbuilder (это единственное, что отличает установку ORACLEдля 1С от простой установки ORACLE).

Чем это грозит для разработчиков? А для разработчика это грозит тем, что у вас (по умолчанию) не будут работать регистры, имеющие более 3-х строковых измерений. И еще тем, что размер строкового индекса будет очень большой. Короче - любая длинная строка в регистре сведений либо в регистре бухгалтерии, либо в регистре накопления - это очень плохо. Любой индекс по строке - это тоже плохо, и сортировка по строке - это тоже плохо . Однако, в целом, функциональный индекс работает быстро. То, что такие строковые индексы в табличном пространстве V81C_INDEX_BIG занимают большие объемы, конечно, не очень хорошо, но не критично. Просто нужно знать, что в целом регистр накопления с измерением типа «Строка» - это архитектурная ошибка . В частности, ORACLE просто об этом напоминает.

Дальше - еще одна очень неприятная новость. ORACLE не использует кластерные индексы. То есть ORACLE, конечно, использует кластерные индексы - они там называются IOT - это более правильное название для кластерных индексов в ORACLE. Просто 1С на ORACLE кластерные индексы не использует, а создает обычные индексы.

Чем это нам грозит? При работе 1С на ORACLE скорость записи у нас увеличивается, в отличие от других СУБД - кажется, что это плюс. С другой стороны - скорость чтения снижается . При работе с другими СУБД 1С строит кластерный индекс для любых ссылочных типов по ссылке - это наиболее быстрый способ выбора данных. А при реализации движка работы с ORACLE 1С пришлось от кластерных индексов отказаться. И мне иногда интересно наблюдать в интернете тесты, где красиво представлено, что когда решение работает на ORACLE, оно так быстро записывается, а читается чуть-чуть медленнее. На самом деле - это не совсем проблема ORACLE - это просто логика работы 1С. Если об этой логике знать - то ничего удивительно в этом нет.

Еще два неприятных момента

по типу NULL у всех СУБД, кроме MSSQLServer, ведется обратный порядок сортировки .
Временные таблицы - мы все уже привыкли к ним. Все разработчики с ними работают, но в случае использования ORACLE - временные таблицы становятся не совсем временными . Я считаю, что у разработчиков 1С это была методологическая ошибка - поскольку временные таблицы в ORACLE предназначены совсем для другого. Вцелом ORACLE не рекомендует использовать временные таблицы для сохранения промежуточных результатов. Там промежуточный результат сохраняется во вьюшках. 1С хранит этот промежуточный результат во временных таблицах, а эти временные таблицы создаются в базе как обычные таблицы и ничем от них не отличаются. Создаются, потом используются…. Очищаются. Но в словаре остаются . Кроме того, временные таблицы в ORACLE ориентированы на жесткую структуру, разве что данные из них используются только в рамках сеанса. Разделяются для каждой сессии, поэтому даже с включенным dynamic_sampling никто не обещает корректного плана выполнения запроса . Это не говорит о том, что не надо использовать временные таблицы, их надо использовать. Просто если, например, я сам писал запрос, в котором временные таблицы генерировались программно при сборе запроса, то это при работе на ORACLE вызовет существенные проблемы : если у вас в запросе 200 временных таблиц, то запрос при первом выполнении на ORACLE - хорошо, если выполнится, а может выполняться очень долго.

Не хочется произносить слова «баги», но всё-таки придётся. Слайд отчасти дублирует предыдущие.

Если вы разрабатывали хотя бы раз конфигурации под управляемое приложение - вы, безусловно, знаете, что такое БСП. БСП на ORACLE даже не запускается … Проблема копеечная - быстро решается, можно было бы просто немного переписать запрос или внести маленькую модификацию в платформу, но - до сих пор эта проблема не решена (три последних релиза БСП эта проблема существует ). Вызвана эта проблема тем, что в перечислениях обращение к реквизиту «порядок» приводит к ошибке. Напомню, что БСП - это основа всех последних решений 1С. 1С позиционирует БСП как «основной инструмент разработчика» и «флагманский продукт», не обращая внимания на эту ошибку. Это значит, что даже первичного тестирования работоспособности на ORACLE не проводится.
Про проблему с БД (с ее резервным копированием и обслуживанием из-за использования схемы как БД) уже сказал. Резервное копирование в ORACLE - либо у вас одна база на Instance - Production, либо у вас резервное копирование осуществляется только средствами импорта (нет дифференциального, нет разностного резервного копирования).
С временными таблицами и чтением данных из 1С в oracle всё плохо.
Технологический журнал 1С от ORACLE не получает плана запросов - пока что эта фича не работает.
Нормального Профайлера , как в MSSQL, нет - не найдёте. Есть куча различных LogAnalizer-ов. В т.ч. умеют Toad и Spotlight, о которых речь пойдёт ниже. Но Online, графического плана запроса, полноценной фильтрации не найти. Конечно, профессиональные ORACLEDBA умеют анализировать загруженность - они запускают консольные средства, генерируют html-файлики… Но это уже не «два клика» - следовательно, если на проекте идет речь об анализе производительности, то обязательно необходим ORACLEDBA .
Оптимизатор Oracle не ориентирован на обширное использование вложенных запросов и, как правило, выбирает достаточно простой план выполнения для соединений (NASTEDLOOPS).

На этом слайде я собрал все то, что нарушает лицензионное соглашение 1С (1Сзапрещает нам использование данных возможностей). Тут есть некоторые важные моменты:

Секционирование (в ORACLE его 6 видов, таблицу можно разбить на 2 диска) - 1С использование секционирования не предусматривает
Storedoutline - «подсказки» оптимизатору. Насколько я знаю, в MSSQLServer мы можем повлиять на план запроса только косвенно (то есть мы раньше, чтобы блокировок в базе MSSQLServer не было, добавляли в регистр 2000 записей) - в ORACLE все гораздо проще. Oracle позволяет управлять планами запросов. 1С использование этой возможности не предусматривает
Mat. View - индексированные представления, которые могут использоваться вместо таблиц. 1С также не использует эту возможность
Сжатие
Битовые индексы - вкратце - индекс по организации. Все, кто отслеживал историю становления прикладных решений фирмы 1С, могли обратить внимание: сначала реквизит «Организация» во всех документах был индексированным. Потом - развитие конструкторской мысли архитекторов прикладных решений 1С привело к тому, что реквизит «Организация» перестал быть индексированным. Логично. Организаций обычно 3-4 штуки, селективность маленькая, индекс не используется, он лишний. Потом опять появились рекомендации о том, что этот реквизит нужно добавлять в индекс. Это, что называется, «на безрыбье и рак рыба». Реквизит «Организация» - это типичный случай битового индекса. Когда у вас низкая селективность, но - при этом он везде используется, по нему везде есть отборы… К сожалению, эту возможность Oracle мы тоже не можем использовать… То есть можем, конечно, НО…

Параметры

По умолчанию Oracle подойдёт только для тестовой среды. Обязательно при первичной настройке необходимо выставить следующие параметры:

Sessions>230 иProcesses>200 . SessionsиProcesses всегда почти не хватит. В production не преступно увеличить до 200. Сессий может быть чуть больше. По сути, процесс - это соединение, но есть куча внутренних процессов
Trace_ enabledFALSE (расширенный технологический журнал) не SQLTrace конечно, но всё равно не нужен постоянно… да и нам не поможет
RecyclebinOFF (Корзина) - можно только поулыбаться. По умолчанию, в ORACLE включено очень много всего. Корзина тоже по умолчанию включена - что правильно - потому что, если вы удаляете таблицу, то она помещается в корзину, а не удаляется. Очень радует, что она работает не на удаление строк - только на удаление таблиц. А в 1С любая реструктуризация - удаление таблиц… 1С вообще оригинально работает с базой данных в случае реструктуризации. Если вы реструктуризируете базу, то у вас таблица удаляется и создается заново. Добавили критерий отбора или общий реквизит и объём базы вырос в 2 раза J. Поэтому - конечно, корзину надо отключать
Почтовые оповещения - оповещают о проблемах, заканчивающемся месте и т.п., если вовремя отреагировать, можно предотвратить «падение» Оракла. Обязательно включите !
Cursor_ sharing - управляет механизмом поиска запроса в кэше запросов. Чтобы уменьшить время на распарсивание запросов, надо сразу ставить exact . Менять нельзя - перестанут использоваться функциональные индексы. Т.е. все…
EXACT - ищется запрос, точно совпадающий с вашим. Никакой перезаписи вашего запроса (использование переменных связывания) для возможного использования другими сессиями не производится. С одной стороны, куча мелких запросов со сложными конструкциями - типичная ситуация для 1С: тратится много времени на их компиляцию
FORCE - ищется запрос, совпадающий с вашим запросом с точностью до связных переменных. Перезапись осуществляется: все литералы заменяются на связные переменные, план создается для «усовершенствованного» запроса
SIMILAR (появилось в 9i) -выполняются те же действия, что и при FORCE, но к тому же осуществляется проверка: можно ли подобрать аналогичный уже разобранный запрос, который не должен изменить план вашего запроса. То есть, если оптимизатор решит, что для выполнения вашего запроса нужен другой план, нежели в уже разобранном, то ваш запрос будет полностью разбираться
Статистика очень важна для CBO. Но в 10 версии Job сбор статистики есть уже системный, притом собирает статистику только по тем таблицам, по которым нужно. Тем не менее,сбор статистики можно запустить и вручную.

Параметры Backup-ов

Дальше - параметры Backup-ов. В ORACLE, если, не дай бог, нет администратора базы данных, нужно обязательно включить автоматическое управление памятью (AMM) , иначе через какое-то время Oracle работать перестанет, а также в случае использования средств impdp и expdp - обычных средств импорта/экспорта отключить ArchiveLog и RedoLog ограничить.

Тонкая настройка

Вот еще один интересный параметр - optimizer_ index_ cost_ adj - существенная настройка. Если мы поставим его в значение 1, то ORACLE будет использовать все индексы, которые только может. Чем меньше, тем ниже порог использования индексов . То есть, если у нас в справочнике всего 3 значения, то при значении этого параметра 1 у нас все равно все индексы будут использоваться. Если мы оставим значение по умолчанию (100) - то у нас будут использоваться индексы только в том случае, если мы выбираем одну запись из миллиона. Очень хорошо, что мы можем этим варьировать - в SQLServer, например, нельзя. Лучше всего выставить в 30 , т.к индексы у нас только штатные
Fileststemio_ options = SETALL - отменяет использование файловой системы (можно использовать дисковые устройства без файловой системы: существенно повышается производительность, выполняется прямое обращению к диску - всю работу по кэшированию данных выполняет сам Oracle).
Redo log group members > 2 Redo log groups > 1 - уменьшить число переключений

Средства администрирования ORACLE

Если обслуживаемая база ORACLE не имеет ORACLEdba, то без средств администрирования не обойтись (если вы конечно, не фанаты консоли и не горите желанием много писать в черном экране).

EnterpriseManager

Один из наиболее любимых инструментов администрирования ORACLE - это EnterpriseManager. Бесплатный, Web интерфейс и т.п. В нем достаточно много функционала и 80% задач администрирования этот инструмент успешно покрывает. Единственная проблема в том, что язык интерфейса - английский.

SQLDeveloper

Другой инструмент для администрирования СУБД ORACLE - это SQLDeveloper. Этот инструмент больше всего похож на ManagementStudioMSSQL. Но реально этот инструмент можно использовать только для построения запросов и создания таблиц вручную.

Кроме того, по моему субъективному мнению, все графические приложения, написанные на Java, имеют большие недостатки интерфейса. Также как и ЕМ - бесплатный.

Для администрирования СУБД ORACLE есть также платные продукты - например, TOAD. Может обойтись дороже самого Oracle. Очень много функциональности (не всегда востребованной). Режим BestPractice выставляет настройки в наиболее оптимальные. Стоит хотя бы посмотреть на работу этого продукта, чтобы понять, какие настройки он предложит (правда - некоторые из выставленных этим режимом настроек не подходят для работы Oracle с 1С, на это нужно обращать внимание. Я в своих предыдущих слайдах указал нужные значения критичных параметров).

Spotlight

Еще один удобный инструмент мониторинга работы СУБД Oracle - Spotlight (производит та же компания, что и TOAD). Красивый. Не очень дорогой (около 37 т.р.). Удобный.

Очень красиво, правильно и быстро выявляет все текущие проблемы, даже вариант решения предложит. Показывает на одном экране все аспекты производительности.

Техническая поддержка

Техническая поддержка: при покупке ORACLE год поддержки бесплатный.

Как видите, разнообразие поддерживаемых языков поражает. По поддерживаемым языкам можно сделать вывод, в каких странах располагается основная масса специалистов oracle.

Собственно, специалистов высокого уровня ожидать там трудно. Просто могут хорошо покопаться во внутренней БД и внутренних ресурсах.

Обычно ответ приходит в течение дня.

Кроме сервиса обращений там же доступ к БД техподдержки и доступ к скачиванию обновлений.

Но сами обновления - целая история. Обновления включают перекомпиляцию схемы, пересоздание некоторых таблиц. Обновления выполняются только в консоли. Это не MSSQLServer и не WindowsUpdate, где «нажали кнопочку и все обновилось». Это целый день работы dba.

Последний вопрос, на который каждый из вас уже, наверное, сам себе ответил - это вопрос о том, когда же нам все-таки нужен ORACLE, когда от его использования на проекте будут какие-то преимущества?

Если у вас есть ORACLEDBA, тогда все озвученные мною проблемы - они все небольшие, они все решаемые, а ORACLEDBA - это такой человек, который может сделать работу вашего решения на Oracle красивым и корректным. Особенно если вам удастся в чем-то договориться с 1С или 1С разрешит нам использовать какие-то фичи из тех, которые я перечислил. Грамотный DBA может ускорить запуск и правильную работу вашего решения раза в два. Потому что количество средств, которые ORACLE нам предоставляет, действительно поражает.

Кластер в ORACLEпоявился уже давно - RAC - очень продуктивная технология, проверенная временем. Она используется в крупных организациях. Если у вас проект, в котором планируется несколько тысяч (несколько десятков тысяч) подключений - даже через разделитель, то RAC - это единственный вариант, который позволит вам полноценно это организовать с точки зрения СУБД. В частности, если 1С сейчас ориентируется на «облака», и у вас уже есть свое «облако» или вы планируете его сделать - то в этом случае, наверное, ORACLE - это самый полноценный выбор.

Однако решение на ORACLE - это специфичное решение. Если вы захотите использовать секционирование, захотите использовать math. view, захотите использовать какие-то другие «фичи» ORACLE, то тут конечно, надо будет постараться «договориться с 1С», поскольку на данный момент эти «фичи» 1С нам использовать не разрешает. Однако - решения, использующие такие «фичи» есть, и эти решения даже получили «1С:Совместимо» - например, решение, использующее прямую запись проводок.

А в других случаях лучше обойтись MSSQL.

*******

Статья написана на основе доклада, прочитанного на Конференции IE 2012 (15-16 ноября 2012 года). Также она опубликована в журнале Инфостарта №1

Приглашаем вас на новую конференцию .

4.СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ 1

4.1.Классификация СУБД 1

4.2.Правила Кодда для реляционной СУБД (РСУБД) 2

4.3.Основные функции реляционной СУБД 4

4.4.Администрирование базы данных 5

4.5.Словарь-справочник данных 6

Система управления базами данных (СУБД) – это важнейший компонент АИС, основанной на базе данных. СУБД необходима для создания и поддержки базы данных информационной системы в той же степени, как для разработки программы на алгоритмическом языке – транслятор. Программные составляющие СУБД включают в себя ядро и сервисные средства (утилиты).

Ядро СУБД – это набор программных модулей, необходимый и достаточный для создания и поддержания БД, то есть универсальная часть, решающая стандартные задачи по информационному обслуживанию пользователей. Сервисные программы предоставляют пользователям ряд дополнительных возможностей и услуг, зависящих от описываемой предметной области и потребностей конкретного пользователя.

Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных для множества приложений, поддержания её в актуальном состоянии и обеспечения эффективного доступа пользователей к содержащимся в ней данным в рамках предоставленных им полномочий.

Принципиально важное свойство СУБД заключается в том, что она позволяет различать и поддерживать два независимых взгляда на БД: "взгляд" пользователя, воплощаемый в "логическом" представлении данных, и "взгляд" системы – "физическое" представление (организация хранимых данных).

Для инициализации базы данных разработчик средствами конкретной СУБД описывает логическую структуру БД, её организацию в среде хранения и пользовательские представления данных (соответственно концептуальную схему БД, схему хранения и внешние схемы). Обрабатывая эти схемы, СУБД создаёт пустую БД требуемой структуры и предоставляет средства для наполнения её данными предметной области и дальнейшей эксплуатации.

Классификация СУБД

По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).

СУБД ОН не ориентированы на какую-либо предметную область или на конкретные информационные потребности пользователей. Каждая система такого рода является универсальной и реализует функционально избыточное множество операций над данными. СУБД ОН имеют в своём составе средства настройки на конкретную предметную область , условия эксплуатации и требования пользователей. Производство этих систем поставлено на широкую коммерческую основу.

Специализированные СУБД создаются в тех случаях, когда ни одна из существующих СУБД общего назначения не может удовлетворительно решить задачи, стоящие перед разработчиками. Причин может быть несколько:

не достигается требуемого быстродействия обработки данных;
необходима работа СУБД в условиях жёстких аппаратных ограничений;
требуется поддержка специфических функций обработки данных.

СпСУБД предназначены для решения конкретной задачи, а приемлемые параметры этого решения достигаются следующим образом:

за счёт знания особенностей конкретной предметной области,
путём сокращения функциональной полноты системы.

Создание СпСУБД – дело весьма трудоёмкое, поэтому для того, чтобы выбрать этот путь, надо иметь действительно веские основания. В дальнейшем будут рассматриваться только СУБД общего назначения.

По методам организации хранения и обработки данных СУБД делят на централизованные и распределённые . Первые работают с БД, которая физически хранится в одном месте (на одном компьютере). Это не означает, что пользователь может работать с БД только за этим же компьютером: доступ может быть удалённым (в режиме клиент–сервер). Большинство централизованных СУБД перекладывает задачу организации удалённого доступа к данным на сетевое обеспечение, выполняя только свои стандартные функции, которые усложняются за счёт одновременности доступа многих пользователей к данным.

По модели данных различают иерархические , сетевые , реляционные , объектно-реляционные и объектно-ориентированные СУБД.

Для реляционных СУБД Э.Ф. Кодд предложил и обосновал 12 правил, которым должна удовлетворять реляционная СУБД данных (РСУБД).

Правила Кодда для реляционной СУБД (РСУБД)

Явное представление данных (The Information Rule). Информация должна быть представлена в виде данных , хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.
Гарантированный доступ к данным (Guaranteed Access Rule). К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.
Обработка неизвестных значений (Systematic Treatment of Null Values). Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных – как пустые строки.
Динамический каталог данных, основанный на реляционной модели (Dynamic On-Line Catalog Based on the Relational Model). Каталог (или словарь-справочник ) данных должен сохраняться в форме реляционных таблиц, и РСУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
Полнота подмножества языка (Comprehensive Data Sublanguage Rule). РСУБД должна поддерживать единственный язык, который позволяет выполнять все операции над данными: определение данных (DDL, Data Definition Language), манипулирование данными (DML, Data Manipulation Language), управление доступом пользователей к данным, управление транзакциями.
Поддержка обновляемых представлений (View Updating Rule). Представление (view) – это хранимый запрос к таблицам базы данных. Обновляемое представление должно поддерживать все операции манипулирования данными , которые поддерживают реляционные таблицы: операции вставки, модификации и удаления данных.
Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete). Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке таблицы, но по отношению к любому множеству строк произвольной таблицы.
Физическая независимость данных (Physical Data Independence). Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютера, на котором находится БД. РСУБД должна предоставлять некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения изменений в логическое представление данных. Это позволяет оптимизировать среду хранения данных с целью повышения эффективности системы, не затрагивая созданных прикладных программ, работающих с БД.
Логическая независимость данных (Logical Data Independence). Это свойство позволяет сконструировать несколько различных логических взглядов (представлений) на одни и те же данные для разных групп пользователей. При этом пользовательское представление данных может сильно отличаться не только от физической структуры их хранения, но и от концептуальной (логической) схемы данных. Оно может синтезироваться динамически на основе хранимых объектов БД в процессе обработки запросов.
Независимость контроля целостности (Integrity Independence). Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных. Это реализуется с помощью ограничений целостности и механизма транзакций.
Независимость от распределённости (Distribution Independence). База данных может быть распределённой (может находиться на нескольких компьютерах), и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияние на приложения.
Согласование языковых уровней (Non-Subversion Rule). Не должно быть иного средства доступа к данным, отличного от стандартного языка для работы с данными. Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и целостности , которые поддерживаются языком более высокого уровня.

Основные функции реляционной СУБД

Основные функции реляционной СУБД определяются правилами Кодда. Но потребности пользователей обуславливают также следующие функции:

Поддержка многопользовательского режима доступа.

База данных создаётся для решения многих задач многими пользователями. Это подразумевает возможность одновременного доступа многих пользователей к данным. Данные в БД являются разделяемым ресурсом, и РСУБД должна обеспечивать разграничение доступа к ним.

Обеспечение физической целостности данных.

Проблема обеспечения физической целостности данных обусловлена возможностью разрушения данных в результате сбоев и отказов в работе вычислительной системы или в результате ошибок пользователей. Развитые РСУБД позволяют в большинстве случаев восстановить потерянные данные. Восстановление данных чаще всего основано на периодическом создании резервных копий БД и ведении журнала регистрации изменений (журнала транзакций).

Управление доступом.

Для многопользовательских систем актуальна проблема защиты данных от несанкционированного доступа. Каждый пользователь этой системы в соответствии со своим уровнем (приоритетом) имеет доступ либо ко всей совокупности данных, либо только к её части. Управление доступом также подразумевает предоставление прав на проведение отдельных операций над отношениями или другими объектами БД.

Настройка РСУБД.

Настройка РСУБД обычно выполняется администратором БД, отвечающим за функционирование системы в целом. В частности, она может включать в себя следующие операции:

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

Задачи администратора БД (АБД) достаточно важны, поэтому на них следует остановиться несколько подробнее.

Администрирование базы данных

Основные задачи администрирования базы данных – обеспечение надежного и эффективного функционирования системы БД, адекватности содержания БД информационным потребностям пользователей, отображения в БД актуального состояния ПО.

Администрирование БД возлагается на администратора (или персонал администрирования, если система БД велика). В задачи администратора входит выполнение нескольких групп функций:

Администрирование предметной области: поддержка представления БД на концептуальном уровне архитектуры СУБД (общем для всех приложений); адекватное отображение в БД изменений, происходящих в ПО. Последнее требование может подразумевать реструктуризацию (изменение схемы) БД и последующее приведение содержимого БД в соответствие с новой схемой.
Администрирование БД: поддержка представления БД в среде хранения, эффективная и надежная эксплуатация системы БД. Если на этом уровне проводится реорганизация БД (с целью повышения эффективности работы), то она заключается в следующем:

изменения в структуре хранимых данных, например, выведение в отдельную таблицу редко используемых данных ;
изменения способов размещения данных в памяти, например:

разбиение таблицы на части для распределения её по различным физическим носителям с целью распараллеливания доступа к ней;
построение кластеров;
изменение физических параметров среды хранения, например, размера блока данных в пространстве памяти.

изменения используемых методов доступа к данным, например, построение индексов или введение хеширования.

Администрирование приложений: поддержка представлений БД для различных групп пользователей механизмами внешнего уровня СУБД. При изменении концептуальной схемы БД или схемы хранения может потребоваться внесение соответствующих изменений в приложения.
Администрирование безопасности данных: предоставление пользователям прав на доступ к БД и настройка системных средств защиты от несанкционированного доступа.

В состав СУБД обычно включаются вспомогательные средства (различные утилиты), упрощающие администрирование БД.

Словарь-справочник данных

Словарь-справочник данных (ССД) – это программная система, предназначенная для централизованного хранения и использования описания объектов БД (метаданных). Иногда ССД называют каталогом данных . Эта система содержит сведения:

о владельцах объектов данных, пользователях ресурсов данных и полномочиях их доступа;
о составе и структуре базы данных;
об ограничениях целостности;
о вспомогательных объектах и компонентах информационной системы.

ССД обеспечивает непротиворечивость метаданных, единую точку зрения на базу данных всего персонала разработчиков , администраторов и пользователей системы. Метаданные в словаре–справочнике реляционной СУБД обычно организованы в виде набора таблиц и представлений.

Словарь БД служит для поддержки функционирования компонентов программного обеспечения – СУБД и прикладных программ, работающих с БД. Словарь содержит сведения об организации БД, её составе и структуре, описание данных: форматы представления, структуру, методы доступа, способы размещения данных в памяти и т.п. Информация в словаре представлена в виде, удобном для программного использования.

Справочник БД содержит сведения о семантике данных, способах их идентификации, источниках данных и т.п. Справочник предназначен главным образом для документирования разработки БД и справочного обслуживания её пользователей. Информация в справочнике представлена в виде, удобном для восприятия человеком.

Множества метаданных словаря и справочника в значительной мере пересекаются. Более того, они могут реализовываться совместно: во многих РСУБД словарь состоит из таблиц (table), содержащих описание объектов БД, а справочник реализуется с помощью представлений (view) над таблицами словаря.

Определения База данных (БД) именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Система управления базами данных (СУБД) совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Использование СУБД позволяет создавать программы независимые от способов реализации хранения данных на внешних носителях. Для работы с базой данных СУБД должна обеспечивать: возможность использования средств доступа и манипуляции данными БД; работу с большим объемом данных; быстроту поиска данных; логическую целостность данных (их непротиворечивость); надежность хранения данных (возможность восстановления из-за различных сбоев); возможность авторизации и разграничения полномочий пользователей (защиту от несанкционированного доступа). 2

Основные функции СУБД 1. Непосредственное управление данными во внешней памяти Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). что в развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. 2. Управление буферами оперативной памяти В развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов. 3. Управление транзакциями Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД. Поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). Но понятие транзакции гораздо более важно в многопользовательских СУБД. 3

Основные функции СУБД 4. Журнализация Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД, иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. 5. Поддержка языков БД язык определения схемы БД (SDL - Schema Definition Language) язык манипулирования данными (DML - Data Manipulation Language) язык SQL (Structured Query Language): позволяет определять схему реляционной БД и манипулировать данными (реализует SDL и DML) содержит специальные средства определения ограничений целостности БД производит авторизацию доступа к объектам БД 4

Компоненты СУБД ядро, которое отвечает за управление данными во внешней и оперативной памяти, и журнализацию, процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно- независимого исполняемого внутреннего кода, подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД а также сервисные программы (внешние утилиты), обеспечивающие ряд дополнительных возможностей по обслуживанию информационной системы. 5

Архитектура СУБД Трехуровневая модель системы управления базой данных, предложенная ANSI (American National Standards Institute) Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных. Уровень внешних моделей Физический уровень 6

Уровень внешних моделей самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Концептуальный уровень центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработки, особенности объектов реального мира. Физический уровень собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации. 7

Архитектура "файл-сервер" 9

Файл-серверные СУБД Файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере. Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок. Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера. Недостатки: потенциально высокая загрузка локальной сети; затруднённость централизованного управления; затруднённость обеспечения таких важных характеристик как высокая надёжность, доступность и безопасность. Применяются чаще всего в локальных приложениях, которые используют функции управления БД. Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxProMicrosoft AccessParadoxdBaseFoxProVisual FoxPro 10

Архитектура "клиент – сервер" 11

Клиент-серверные СУБД Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно. Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу. Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность. Примеры: Oracle, Firebird, Interbase, IBM DB2, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Caché, ЛИНТЕР.OracleFirebirdInterbaseIBM DB2MS SQL ServerSybase Adaptive Server EnterprisePostgreSQLMySQLCachéЛИНТЕР 12

Встраиваемые СУБД Может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Физически чаще всего реализована в виде подключаемой библиотеки. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы. Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.OpenEdgeSQLiteBerkeleyDBFirebird EmbeddedMySQLSav Zigzag Microsoft SQL Server CompactЛИНТЕР 13

Разграничение функций между сервером и клиентом Функции приложения-клиента: Посылка запросов серверу. Интерпретация результатов запросов, полученных от сервера. Представление результатов пользователю в некоторой форме (интерфейс пользователя). Функции серверной части: Прием запросов от приложений-клиентов. Интерпретация запросов. Оптимизация и выполнение запросов к БД. Отправка результатов приложению-клиенту. Обеспечение системы безопасности и разграничение доступа. Управление целостностью БД. Реализация стабильности многопользовательского режима работы. 14

Современные локальные СУБД используются для сравнительно небольших задач (небольшой объем обрабатываемых данных, малое количество пользователей) имеют относительно упрощенную архитектуру, в частности, функционируют в режиме файл-сервер, поддерживают не все возможные функции СУБД (например, не ведется журнал транзакций, отсутствует возможность автоматического восстановления базы данных после сбоев и т. п.) dBase III – PLUS, Clipper (фирма Nantucket Inc.), FoxPro (фирма Fox Software), FoxBase+ (фирма Fox Software), Visual FoxPro (фирма Microsoft), PARADOX (фирма Borland International) Microsoft Access (фирма Microsoft). 15

Администрирование БД Администрирование базы данных – это функция управления базой данных (БД). Лицо ответственное за администрирование БД называется Администратор базы данных (АБД) или Database Administrator (DBA). Администратор базы данных (АБД) или Database Administrator (DBA) – это лицо, отвечающее за выработку требований к базе данных, её проектирование, реализацию, эффективное использование и сопровождение, включая управление учётными записями пользователей БД и защиту от несанкционированного доступа, а так же поддержку целостности базы данных. 17

Задачи администратора БД 1. Проектирование базы данных. 2. Оптимизация производительности базы данных. 3. Обеспечение и контроль доступа к базе данных. 4. Обеспечение безопасности в базе данных. 5. Резервирование и восстановление базы данных. 6. Обеспечение целостности баз данных. 7. Обеспечение перехода на новую версию СУБД. 18

Специализации администратора БД 1. Системный администратор. 2. Архитектор БД. 3. Аналитик БД. 4. Разработчик моделей данных. 5. Администратор приложении. 6. Проблемно-ориентированный администратор БД. 7. Аналитик производительности. 8. Администратор хранилища данных. 19

Каждый владелец сайта знает, что для правильного функционирования сайта нужны не только файлы с кодом страниц, но и базы данных. Для взаимодействия с базами данных используются системы управления базами данных (СУБД). В данной статье я хочу рассказать о базах данных и СУБД, о том, какие разновидности существуют, и чем они отличаются друг от друга.

База данных

База данных представляет собой определенный набор данных, которые, как правило, связаны объединяющим признаком либо свойством (или несколькими). Эти данные упорядочены, например, по алфавиту. Обилие различных данных, которые могут быть помещены в единую базу, ведет к множеству вариаций того, что может быть записано: личные данные пользователей, записи, даты, заказы и так далее. К примеру, если у вас интернет-магазин, то база данных вашего сайта может содержать прайс-листы, каталог товаров или услуг, отчеты, статистику и информацию о клиентах.

В первую очередь это удобно тем, что информацию можно быстро заносить в базу данных и так же быстро ее извлекать при необходимости. Если на заре развития web-разработки все необходимые данные нужно было прописывать в коде страницы, то теперь такая необходимость отсутствует - нужная информация может быть запрошена из базы данных при помощи скриптов. Специальные алгоритмы хранения и поиска информации, которые используются в базах данных, позволяют находить нужные сведения буквально за доли секунд - а при работе в виртуальном пространстве скорость работы ресурса важна как ничто другое.

Немаловажной является и взаимосвязь информации в базе данных: изменение одной строчки может привести к значительным изменениям других строк. Работать с данными таким образом гораздо проще и быстрее, чем если бы изменения касались только одного места в базе данных.

Однако это не значит, что база данных обязательно должна быть у каждого сайта - к примеру, если у вас сайт-визитка, и никакой новой информации вы на сайте не размещаете, то база данных вам будет попросту не нужна. Самый легкий способ сделать простой сайт - создать .

Система управления базами данных

Как можно догадаться уже из названия, система управления базами данных (или сокращенно СУБД) представляет собой программное обеспечение, которое используется для создания и работы с базами данных. Главная функция СУБД - это управление данными (которые могут быть как во внешней, так и в оперативной памяти). СУБД обязательно поддерживает языки баз данных, а также отвечает за копирование и восстановление данных после каких-либо сбоев.

Что касается классификации баз данных, то тут возможны различные варианты.
К примеру, можно разделить базы по модели данных : иерархические (имеют древовидную структуру), сетевые (по своей структуре похожи на иерархические), реляционные (используются для управления реляционными базами данных), объектно-ориентированные (используются для объектной модели данных) и объектно-реляционные (некое слияние реляционного и объектно-ориентированного вида баз данных).

Либо, если деление идет по тому, где размещается СУБД , их можно разделить на локальные - вся СУБД размещается на одном компьютере, и распределенные - части системы управления базами данных находятся на нескольких компьютерах.

Файл-серверные, клиент-серверные и встраиваемые - такие названия носят СУБД, если разделить их по способу доступа к базам данных . Файл-серверные СУБД на данный момент уже считаются устаревшими; в основном идет использование клиент-серверных (СУБД, которые располагаются на сервере вместе с самой базой данных) и встраиваемых (не требующих отдельной установки) систем.

Информация, которая хранится в базах данных, не ограничивается только текстовыми или графическими файлами - современные версии СУБД поддерживают также форматы аудио и видеофайлов.

В этой статье я сделаю упор на СУБД, которые используются для хранения информации различных веб-ресурсов.

Зачем же нужны эти СУБД? Помимо основной своей функции - хранения и систематизации огромного количества информации - они позволяют быстро обрабатывать клиентские запросы и выдавать свежую и актуальную информацию.

Это касается и изменений, которые вносите вы - вместо того, чтобы менять информацию в каждом файле сайта, вы можете поменять ее в базе данных, и тогда на каждой странице сразу же будет отображена корректная информация.

Реляционные СУБД и язык SQL

Реляционные и объектно-реляционные СУБД являются одними из самых распространенных систем. Они представляют собой таблицы, у которых каждый столбец (который называется “field” или «поле») упорядочен и имеет определенное уникальное название. Последовательность строк (их называют “records” или «записи») определяется последовательностью ввода информации в таблицу. При этом обрабатывание столбцов и строк может происходить в любом порядке. Таблицы с данными связаны между собой специальными отношениями, благодаря чему с данными из разных таблиц можно работать - к примеру, объединять их - при помощи одного запроса.

Для управления реляционными базами данных применяется особый язык программирования - SQL. Сокращение расшифровывается как “Structured query language”, в переводе на русский «язык структурированных запросов».

Команды, которые используются в SQL, делятся на те, которые манипулируют данными, те, которые определяют данные, и те, которые управляют данными.

Схема работы с базой данных выглядит следующим образом:

MySQL

MySQL является одной из самых популярных и распространенных СУБД, которая используется во многих компаниях (например, Facebook, Wikipedia, Twitter, LinkedIn, Alibaba и других). MySQL представляет собой реляционную СУБД, которая относится к свободному программному обеспечению: она распространяется на условиях GNU Public License. Как правило, эту систему управления базами данных определяют как хорошую, быструю и гибкую систему, рекомендованную к применению в небольших или средних проектах. У MySQL есть множество различных преимуществ. Например, она поддерживает различные типы таблиц: как известные MyISAM и InnoDB, так и более экзотичные HEAP и MERGE; кроме того, количество поддерживаемых типов постоянно растет. MySQL выполняет все команды быстро - возможно, сейчас это самая быстрая СУБД из всех существующих. С этой системой управления базами данных может одновременно работать неограниченное количество пользователей, а число строк в таблицах может быть равно 50 миллионам.

Так как в сравнении с некоторыми другими СУБД MySQL поддерживает меньшее количество возможностей, то и работать с ней значительно проще, чем, к примеру, с PostgreSQL, о которой будет рассказано ниже.

Первая версия MySQL вышла в далеком 1995 году, и с тех пор состоялось несколько последующих релизов, каждый из которых нес в себе значительные изменения.

Для работы с MySQL используется не только текстовый, но и графический режим. Это возможно благодаря приложению phpMyAdmin: для работы в приложении вам даже не нужно будет знать SQL-команды, а администрировать свою базу данных можно прямо через браузер.

В целом можно отметить, что MySQL - это выбор тех, кому необходима СУБД для проекта небольшого или среднего размера, быстрая и удобная в работе и без сложностей с администрированием.

PostgreSQL

Эта свободно распространяемая система управления базами данных относится к объектно-реляционному типу СУБД. Как и в случае с MySQL, работа с PostgreSQL основывается на языке SQL, однако, в отличие от MySQL, PostgreSQL поддерживает стандарт SQL-2011. Эта СУБД не имеет ограничений ни по максимальному размеру базы данных, ни по максимуму записей или индексов в таблице.

Если говорить о преимуществах PostgreSQL, то, безусловно, это надежность транзакций и репликаций, возможность наследования и легкая расширяемость. PostgreSQL поддерживает различные расширения и варианты языков программирования, такие как PL/Perl, PL/Python и PL/Java. Также есть возможность загружать C-совместимые модули.

Многие отмечают, что в отличие от MySQL данная СУБД имеет хорошую и подробную документацию, которая дает ответы практически на все вопросы.

О том, что это более масштабная, чем MySQL, СУБД, говорит и тот факт, что PostgreSQL периодически сравнивают с такой мощной системой управления данных, как Oracle.

Все это позволяет говорить о PostgreSQL как об одной из самых продвинутых СУБД на данный момент.

SQLite

На данный момент это одна из самых компактных СУБД; также она является встраиваемой и реляционной. SQLite позволяет хранить все данные в одном файле и, благодаря своему небольшому объему, отличается завидным быстродействием. SQLite значительно отличается от MySQL и PostgreSQL своей структурой: движок и интерфейс этой СУБД находятся в одной библиотеке - и именно это позволяет выполнять все запросы очень быстро. Другие СУБД (MySQL, PostgreSQL, Oracle и т.д.) используют парадигму клиент-сервер, когда взаимодействие происходит через сетевой протокол.

Из недостатков можно отметить отсутствие системы пользователей и возможности увеличения производительности.

SQLite можно посоветовать к использованию в проектах, где нужно иметь возможность быстро перенести приложение, и нет необходимости в масштабируемости.

Oracle

Эта СУБД относится к объектно-реляционному типу. Название произошло от названия разработавшей эту систему фирмы Oracle. Наравне с SQL СУБД использует процедурное расширение под названием PL/SQL, а также язык Java.

Oracle - это система, отличающаяся стабильностью уже не один десяток лет, поэтому ее выбирают крупные корпорации, для которых важна надежность восстановления после сбоев, отлаженная процедура бэкапа, возможность масштабирования и другие ценные возможности. К тому же эта СУБД обеспечивает отличную безопасность и эффектную защиту данных.

В отличие от других СУБД, стоимость покупки и использования Oracle достаточно высока, и именно это зачастую является значимым препятствием к ее использованию в небольших фирмах. Вероятно, именно это также является причиной того, что в рейтинге СУБД на 2016 год в России Oracle находится лишь на 6-м месте.

MongoDB

Эта СУБД отличается тем, что она предназначена для хранения иерархических структур данных, и поэтому ее называют документоориентированной (она представляет собой документное хранилище без использования таблиц или схем). MongoDB имеет открытый исходный код.

Используя идентификатор, вы можете производить быстрые операции над объектом; эта СУБД хорошо показывает себя и при сложных взаимодействиях. В первую очередь речь идет о быстродействии - в некоторых случаях приложение, написанное на MongoDB, будет работать быстрее, чем такое же приложение, использующее SQL, т.к. MongoDB относится к классу СУБД NoSQL и вместо SQL пользуется объектным языком запросов, который значительно легче SQL.

Однако этот язык имеет и свои ограничения, а поэтому MongoDB следует использовать в случаях, когда нет необходимости в сложных и нетривиальных выборках.

Вместо заключения

Выбор СУБД - это важный момент при создании своего ресурса. Отталкивайтесь от своих задач и возможностей, пробуйте и экспериментируйте, чтобы найти именно тот вариант, который будет наиболее подходящим.

Для успешного применения этого программного обеспечения необходимо правильно выбрать подходящий режим работы. Пригодятся на практике также знания о совместимости 1С с разными базами данных. Материалы этой статьи помогут точнее настроить функционирование приложений с учетом требований конкретного предприятия.

Режимы работы и клиентские приложения

В самом простом варианте конфигурации системы рекомендуется применение специального файла: «1Cv8.1CD». В нем хранится новая информация пользователей, фиксируются изменения в регистрах, сделанные индивидуальные настройки. Такой способ отличается удобством использования. Его функционал доступен без дополнительных затрат. Единственным существенным недостатком является ограниченное число пользователей, не более 10.

Важно! Для хранения самого файла «1Cv8.1CD» выделяют отдельный компьютер. К нему впоследствии организуют доступ всех пользователей по локальной сети, которые получают возможность работы с дисковым пространством. В данном случае происходит имитация режима «клиент-сервер».

Приведем сведения, которые позволят точнее оценить пригодность такого выбора для решения определенных задач:

Структура упомянутого выше файла является табличной. Размер каждого отдельного блока ограничен объемом 4 Гб;
Если используются «младшие» версии 1С, ниже чем 8.3, то корректное выполнение некоторых заданий в автоматическом режиме будет невозможно. Ограничением является необходимость подключения отдельных пользователей;
В этом варианте нельзя осуществлять одновременное проведение нескольких документов;
Он не обеспечивает высокий уровень безопасности. При желании любой пользователь в состоянии сделать копию основного файла, в котором хранится база данных предприятия.

Для более масштабных проектов лучше подходит полноценная организация работы в режиме «клиент-сервер». Перечислим его особенности:

Такой вариант разработан для одновременной работы большого количества пользователей. Для получения достаточной производительности применяют разные системы управления базами данных и сервера, объединенные в кластеры;
Его скоростные параметры лучше по сравнению с «файловым» вариантом, что позволяет обрабатывать быстрее большие массивы данных;
В данном случае проще установить и эксплуатировать современную защиту информации;
Для увеличения вычислительной мощности достаточно добавления нужного количества серверов в определенный кластер.

В режиме «клиент-сервер» применяют стандартно архитектуру из трех уровней. Самый нижний – это пользовательские программы. От них поступают обращения к серверам кластера. При необходимости, включается кэширование данных. Алгоритм обработки запросов предусматривает возможность немедленного получения ответов. Для получения информации под управлением менеджера процессов сервер формирует обращение к СУБД. Данные к клиенту поступают по обратной цепочке.

Совет! Если предполагаются пиковые нагрузки, то рекомендуется установить необходимое количество дополнительных рабочих серверов. К ним будут автоматически перенаправляться запросы пользователей.

Для перехода от файлового варианта, к более производительному, «клиент-серверному» режиму достаточно загрузить старые данные в специальный архив. Их далее хранят на сервере. В разделе «Конфигурация» программы 1С можно посмотреть, какой именно режим активизирован.

Клиентские приложения

В 1С предусмотрена работа с применением нескольких видов программного обеспечения. Отметим особенности этих трех клиентов:

Тонкий – прием/передача данных осуществляется на основе собственного протокола. Если используется https, то необходима соответствующая настройка сервера.
Толстый применяется только при достаточной производительности линий связи. С его помощью выполняют отладочные и вычислительные операции, обращаются к БД.
В Web используют программы, работающие в браузере.

Важно! Применение не пригодно для решения разработчиком практических вопросов.

Если используется «файловый» режим, то к данным в 1Cv8.1CD могут обращаться напрямую, а Web – только через сервер. При работе с тонким клиентом допустимо использование обоих путей. В «клиент-серверном» варианте применяются подобные схемы, но добавляется еще одно звено, объединенные в кластер сервера. Именно от него получают некоторые ответы оперативно. При необходимости запрос адресуется на более высокий уровень, в СУБД.

Применение разных систем управления базами данных

Файловая СУБД:
- Представление любой из таблиц следующими файлами: описания, записей, индексов и значений;
- Каждый из файлов занимает не более 4 Гб на диске;
- Длина ключа ограничена 1920 байтами;
- Для индексации допустимо использовать максимум 256 полей.
PostgreSQL:
- Если использован режим сортировки по возрастанию величин NULL располагаются в конце списка;
- Скорость обработки данных в этой СУБД уменьшается при существенном повышении интенсивности обращений пользователей;
- Показатели производительности сильно зависят от соответствующих технических параметров накопителей;
- Особый алгоритм фиксации каждой транзакции повышает уровень надежности;
- Предотвратить появление ошибок поможет комплексное использование источников бесперебойного питания и массивов RAID.
Microsoft SQL – наибольшее количество в одном запросе таблиц не должно превышать 256 ед.;
В Oracle DB, как и PostgreSQL после сортировки по возрастанию NULL устанавливается в конце списка. В этой СУБД запрещено «Упорядочить», или «Первые» размещать внутри конструкции «В «подзапрос». При ее использовании следует внимательно работать со статистическими данными планов запросов. Они оказывают заметное влияние на стабильность 1С;
IBM DB2:
- NULL не является типизированным показателем;
- Числовое значение не должно превышать 31 символ;
- Одно поле ограничено объемом 1 Гб;
- При увеличении количества подзапросов (в условии соединения) не исключено некоторое снижение производительности.