Oracle арм кис возможности настройки для склада

Обновлено: 06.07.2024

Стоит задача организовать хранилище данных на базе Oracle. Исходная OLTP-система работает под управлением Oracle 10.2.0.5, имеет размер почти 7 Тб, ежедневная нагрузка до 3-4 млн. транзакций в сутки (прирост до 100 Гб в сутки). Объёмы данных приличные, нагрузка на OLTP предельная, поэтому хочется отсадить хранилище на отдельный экземпляр.

Задача для меня новая, опыта построения хранилищ нет. Сейчас читаю "Oracle® Database Data Warehousing Guide". Проблема в том, что документация имеет описательный характер, где предлагается куча альтернатив, мол, можно делать так, а можно так. Чётких критериев, какой способ выбрать, нет. :(

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

Доступность
Необходима дневная доступность данных по времени мск (7:00 - 21:00).

Жизненный цикл данных
Данные доступны за любой период времени, старые данные не архивируются. Должна быть реализована возможность архивации и выноса исторических данных, что может потребоваться через 3-4 года эксплуатации DWH.

Замечания
- Объём данных довольно большой, в день имеем до 3-4 млн авторизаций в OLTP.
- Источник данных - OLTP-система, работающая под управлением Oracle 10.2.0.5.
- На начальном этапе хотим сделать хранилище на том же экземпляре Oracle, что и OLTP-система. Если будут проблемы с вводом-выводом, то DWH отсаживается на отдельную дисковую группу от OLTP-системы.
- В идеале хочется сделать хранилище независимым от OLTP, т.е. необходимо разработать механизм переноса изменённых данных (а не перекачивать полные снимки таблиц).

В данный момент имеется логический дизайн хранилища, согласованный с аналитиками. Требуется:
- грамотная реализация физического дизайна (таблицы фактов, измерений, индексы, MV и т.д.);
- разработка процедуры переноса данных (ETL).

автор
Доступность Необходима дневная доступность данных по времени мск (7:00 - 21:00).

на какой промежуток времени вы согласны не видеть новые данные? Например если вам достаточно <= вчерашние данные то это другое , если <= сейчас это другое.

автор
Замечания - Объём данных довольно большой, в день имеем до 3-4 млн авторизаций в OLTP. - Источник данных - OLTP-система, работающая под управлением Oracle 10.2.0.5. - На начальном этапе хотим сделать хранилище на том же экземпляре Oracle, что и OLTP-система. Если будут проблемы с вводом-выводом, то DWH отсаживается на отдельную дисковую группу от OLTP-системы. - В идеале хочется сделать хранилище независимым от OLTP, т.е. необходимо разработать механизм переноса изменённых данных (а не перекачивать полные снимки таблиц).

автор

не советовал б в такой объеме. Как минимум в одном дисковом группе 100% будет тормоза. Во вторых если испортится это группа потеряети всё. Там рейды мейды всё это головоломка. лучше у админами посоветоваться.

PranT
В данный момент имеется логический дизайн хранилища, согласованный с аналитиками. Требуется: - грамотная реализация физического дизайна (таблицы фактов, измерений, индексы, MV и т.д.); - разработка процедуры переноса данных (ETL). К сожалению, знаний по этим двум пунктом у меня не достаточно, поэтому и прошу дать совета. :)

PranT

оч. хорошо, что начинаете формализовать задачу.

1) Поднять отдельную базу в отдел ном серваке , создание схемы под оддной структурой с ОЛТП с учетом всех финансовых таблиц в ОЛТП системе , с полями "from date" с какой даты изменился, "to date" до какой даты не изменялся , (если запись актуальная то эту дату можете поставить какое то фикивное значение например "01.01.4000"). Еже ночная накат данных по измененным записям.
2) Создание схемы OLAP и ежедневная консолидация отчетов. (обьем зависит от отчетов и их по трудоемкости)

Открываем тему — потому что в рамках одной статьи рассказать про восемь различных программно-аппаратных комплексов Oracle можно только в формате «открытия темы». Поэтому сегодня мы «пробежимся» по Exadata, Exalogic, SuperCluster, Exalytics, Database Appliance, Big Data Appliance, Private Cloud Appliance и Zero Data Loss Recovery Appliance, а в других материалах будем обсуждать каждую продуктовую линию отдельно и детально.

На самом деле термин «программно-аппаратные комплексы», которым мы будем пользоваться в этой статье, не вполне корректен, ведь любые вычислительные системы по определению являются программно-аппаратными комплексами. Правильнее говорить об оптимизированных программно-аппаратных комплексах. Потому что каждый программно-аппаратный комплекс — это результат тщательнейшего проектирования, подбора компонентов, настройки программного обеспечения, комплектации решения функциональностью и, конечно, оптимизации.

Аппаратное обеспечение и программное обеспечение проектируются, тестируются и отлаживаются совместно. И если вы знаете, на каком оборудовании будут работать приложения, то вы можете добиться высочайшей производительности, вероятность «сюрпризов» от несовместимости компонентов при этом становится меньше, а оказание поддержки — проще. Заказчикам не приходится подбирать и оптимизировать компоненты — серверы, диски, процессоры, сетевые компоненты, память и т.п. Устанавливать и настраивать программное обеспечение, тестировать работоспособность каждого сервера, заниматься их последующим обновлением и т.п. тоже не нужно. Существенно упрощается обслуживание ИТ-инфраструктуры. Именно в этом заключается идея программно-аппаратных комплексов, которые компания Oracle начала создавать с 2008 г. — самостоятельно разрабатывать программно-аппаратные конфигурации для достижения наивысшей производительности.

Машины Exadata были дебютом Oracle в жанре программно-аппаратных комплексов. Exadata — это машина, предназначенная исключительно для выполнения СУБД Oracle. Она используется для OLTP-нагрузок, для хранилищ данных, для смешанных нагрузок, для консолидации приложений на базе Oracle Database. На аппаратном уровне Exadata в зависимости от конфигурации — это и быстрая дисковая подсистема и 40-гигабитная сеть Infiniband, а также многотерабайтная оперативная память и FLASH-память на десятки терабайт. То есть, с аппаратной точки зрения — это очень быстрые и мощные машины.

Но важнейшей особенностью архитектуры Exadata являются так называемые ячейки (рис. 1). Каждая ячейка Exadata — это самостоятельный сервер с 12 дисками и специальным ПО Exadata Software. Ячейки Exadata — это не просто серверы хранения, они умеют выполнять множество операций самостоятельно. Это операции, которые в традиционной архитектуре делает сама СУБД Oracle — тем самым серверы баз данных разгружаются для других операций. Не всегда очевидный, но очень важный момент — многие ресурсоемкие запросы требуют перекачки больших объемов данных с дисков по сети на сервера СУБД Oracle для обработки. В случае использования ячеек, зачастую удается отфильтровать заведомо ненужные данные прямо на системе хранения, чтобы передавать в СУБД требовалось только ничтожную часть первоначального объема данных. Это позволяет в некоторых случаях увеличивать производитльность запросов в десятки и сотни раз. Ячейки не связаны между собой непосредственно, что позволяет распараллеливать запросы без накладных расходов. Количество ячеек в системе неограниченно, при этом данные «размазаны» между многими ячейками Exadata.

Важно понимать, что даже если самостоятельно собрать похожий аппаратный комплекс на оборудовании Oracle или других производителей, создать на его основе систему, аналогичную Exadata не получится. Дело в том, что программное обеспечение Exadata, которое отвечает за большую часть преимуществ Exadata, включая гибридно-колоночную компрессию, индексы хранения, работа c FLASH-картами и т.д., поставляется только с Exadata. Благодаря оптимизации, которую проходят комплексы Exadata и использованию Exadata Software, система в целом работает в разы быстрее, чем любые аналогичные, но обычные, неоптимизированные конфигурации.

Как вы понимаете, на такой конфигурации могут работать довольно серьезные базы данных, так что малый бизнес для Database Appliance — далеко не предел. С другой стороны, если для вашего бизнеса 72 процессорных ядра много, то не нужно платить сразу за все — можно для начала лицензировать меньшее количество ядер (минимально два ядра), все остальные будут временно заблокированы. Когда с течением времени вашему бизнесу потребуются дополнительные вычислительные мощности, можно приобрести лицензию на необходимое количество ядер — и они будут активизированы. Так Database Appliance оптимизирует затраты клиентов.

Изначально Oracle Database Appliance задумывали, как машину для базы данных Oracle, но затем заказчики получили возможность устанавливать на эту конфигурацию виртуальную машину Oracle и разворачивать на ней полноценные решения — со слоями приложений, базы данных и т.д. А поскольку виртуальная машина Oracle поддерживает частичное лицензирование, можно лицензировать одни процессорные ядра только для виртуальной машины и серверов приложений, другие — только для слоя базы данных и т.д.

Oracle Exalogic — это Exadata «наоборот», аналогичная машина, оптимизированная для выполнения слоя приложений Oracle. Exalogic, построенная на архитектуре Intel, предлагает высочайшую производительность для Oracle Fusion Middleware, приложений Oracle (таких как Oracle E-Business Suite, Utilities, Siebel и т.д.) и виртуальных машин, она оптимизирована для приложений WebLogic.

Exalogic — это очень мощная машина. У нее до 30 вычислительных узлов, до 1080 ядер Xeon, встроенное хранилище для огромных объемов данных — дисковый массив ZFS на 80 ТБ. Конечно, заказчик может создать подобную конфигурацию сам, но тогда у него не будет главного — флажка «Enable Exalogic Optimizations» на панели администратора (рис. 2). А он включает многочисленные оптимизации и специальныое ПО, которое позволяет, как и в случае Exadata, значительно ускорить систему, по сравнению с обычными конфигурациями.

Oracle SuperCluster — это машина, которая сочетает в себе возможности Exadata и Exalogic на платформе SPARC. Фактически это машина для консолидации — на нее можно установить базу данных, слой приложений и настроить все это для совместной работы с использованием всех преимуществ SPARC-платформы, включая виртуализацию, отказоустойчивость и т.д. При этом на SuperCluster используются ячейки Exadata для ускорения работы базы данных. Но самое большое преимущество можно получить, когда на одном SuperCluster разворачивается целиком целая система, например, система Oracle E-Business Suite, или система SAP, которая состоит из серверов приложений и базы данных Oracle.

Сейчас существуют две продуктовые линии SuperCluster: одна на процессоре Т5, вторая — на процессорах М6. На рис. 3 приведено сравнение конфигураций SuperCluster Т5-8 и М6-32. Одно из основных преимуществ SuperCluster М6-32 — это огромный объем оперативной памяти, до 32 ТБ, а также 384 процессорных ядра. Если ваша бизнес-система требовательна к количеству процессоров, к объему оперативной памяти и, возможно, не слишком хорошо приспособлена для работы в кластере, то SuperCluster М6-32 закроет все потребности даже такой «капризной» системы.

Машина Oracle Exalytics предназначена для ускорения слоя бизнес-аналитики. Ее главные возможности — это ускорение работы Oracle Business Intelligence и Oracle Essbase благодаря использованию большого объема оперативной памяти, интеграция с Exadata, ускорение отчетов и задач планирования и бюджетирования, поддержка большого количества пользователей, использование технологий In-Memory технологий: Oracle TimesTen или Oracle Database с опцией ln-Memory.

Exalytics версии X5-4 имеет до 3 ТБ оперативной памяти, 72 процессорных ядра Intel, FLASH-хранилище объемом 4,8 ТБ и жесткие диски суммарным объемом 7,2 ТБ. Exalytics версии T5-8 — еще более «богатая» машина, у нее 4 ТБ оперативной памяти, 128 процессорных ядер SPARC T5 и 3,2 ТБ FLASH-памяти. Эту огромную вычислительную мощь имеет смысл использовать с огромным количеством одновременно работающих пользователей аналитической системы, в том числе для поддержки хранилищ данных, работающих на альтернативных платформах, и испытывающих проблемы с производительностью.

Oracle Private Cloud Appliance — это инфраструктура для быстрого развертывания виртуальных машин на базе Oracle VM. Это удобный в использовании комплекс, который позволяет вам очень быстро развертывать виртуальные машины и управлять ими. Виртуальные машины создаются вручную из ISO-образов или из шаблонов Oracle VM. В Private Cloud Appliance, можно, например, создать простую виртуальную машину вроде Oracle Linux VM или Solaris VM за одну минуту, а 16-узловой кластер Oracle RAC — примерно за 45 минут. Кроме того, в OPCA используется относительно недавно приобретенная Oracle система SDN (Software Define Network) для быстрого создания и управления виртуальными сетями.

Инфраструктура предназначена для работы с Intel-ориентированными виртуальными машинами (Linux, Solaris, Windows). Можно приобрести минимальную двухузловую конфигурацию и наращивать ее до 25 узлов. Число процессорных ядер в такой максимальной конфигурации составит 900 (по 36 на узел), объем памяти — 6,4 ТБ (по 256 ГБ на узел). У системы есть небольшое собственное хранилище (ZFS Storage), но предполагается, что виртуальные машины будут использовать системы хранения, которыми располагает заказчик.

Oracle Zero Data Loss Recovery Appliance — это первый в мире программно-аппаратный комплекс, созданный специально для защиты баз данных Oracle. Recovery Appliance обеспечивает непрерывную защиту бизнес-критичных баз данных, выполняя всю обработку процессов резервного копирования, чтобы минимизировать нагрузку на производственные сервера. Оно исключает риск потери данных и резко снижает накладные расходы, связанные с защитой данных на производственных серверах. Кроме того, Recovery Appliance масштабируется для защиты тысяч баз данных, гарантирует сквозную проверку достоверности данных, а также реализует полный жизненный цикл защиты данных, включая резервное копирование на диск, резервное копирование на магнитную ленту и дистанционную репликацию.

Новые возможности Oracle Zero Data Loss Recovery Appliance тесно интегрируются с функциями СУБД Oracle и утилитой Recovery Manager (RMAN) для резервного копирования. Recovery Appliance реализует архитектуру только инкрементного (incremental forever) резервного копирования, чтобы минимизировать нагрузку на производственные системы.

Основная цель Recovery Appliance — исключить потери критически важной информации в базе данных. Передача журналов транзакций Redo в режиме реального времени на резервную БД была впервые реализована в технологии Oracle Data Guard. Recovery Appliance распространяет эту технологию на все базы данных простым и экономически эффективным способом. Recovery Appliance предлагает такой же уровень защиты данных, как и Data Guard, для баз данных, где не требуется быстрое переключение на резервную БД.

Система Recovery Appliance «понимает» внутренние форматы блоков СУБД Oracle, что позволяет производить проверку целостности данных на глубоком уровне. Целостность данных во всех резервных копиях и блоках Redo автоматически проверяется при их получении системой Recovery Appliance.

Recovery Appliance автоматизирует и принимает на себя управление всеми процессами полного и инкрементного резервного копирования на ленты. В качестве опции в программно-аппаратном комплексе Recovery Appliance могут быть установлены адаптеры Fibre Channel 16 Гбит/с для пересылки данных непосредственно из Recovery Appliance на ленточные библиотеки с использованием входящего в комплект поставки высоко интегрированного ПО Oracle Secure Backup для управления.

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

И последнее на сегодня. Пожалуйста, не пользуйтесь калькой с английского, и не называйте программно-аппаратные комплексы «инженерными системами». Это неправильно, потому что в русском языке под инженерными системами понимают совсем другое — системы электро-, тепло- и газоснабжения, водоснабжения и канализации, вентиляции и кондиционирования, освещения и связи. Вот почему наши оптимизированные программно-аппаратные комплексы достойны того, чтобы называть их своим именем — ведь они могут управлять целыми городами инженерных систем.

За время работы с Oracle Database и Microsoft SQL Server Integration Services я собрал 2 FAQ-а. Первый — по Oracle Client — я публикую здесь, а второй — по коннекторам SSIS к Oracle, следующим постом.

Что такое Oracle Client?

Это промежуточное ПО, предназначенное для доступа к Oracle Database. Некоторые приложения имеют встроенного клиента. Встраиваемый клиент, предназначенный для разработчиков, называется Instant Client.

Откуда скачать Oracle Client?

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

Не перепутайте Oracle Client и Oracle Instant Client, предназначенный для разработчиков. Так же, не качайте Data Access Components, поскольку DAC, помимо Oracle Client, содержит много средств, нужных только для разработки приложений.

Установка клиента Oracle 12c 32-bit не проходит после установки Oracle 12c 64-bit клиента (или наоборот)

Если Вы только что установили одного из клиентов Oracle 12c и не перезагружались, перезагрузитесь.

Программа установки Oracle Client, называемая Oracle Universal Installer, создает службу OracleRemExecService, которая согласно неофициальному описанию нужна только для OUI и должна исчезнуть после перезагрузки. В реальности она не исчезает, но и не запускается при старте ПК. Является ли правильным остановить службу, я не знаю, но это тоже помогает.

Как настроить подключение к СУБД Oracle в приложении, использующем Oracle Client?

Со стороны прикладного программного обеспечения, работающего через Oracle Client, для указания БД может быть использовано имя сервиса TNS или строка конфигурации, содержащая часть объявления имени сервиса TNS.

В первом случае в папке Oracle Client в "\network\admin\tnsnames.ora" укажите:

При этом, в приложениях в поле TNS Service Name указывается имя подключения.

Следует иметь ввиду, что в приложении, запускаемом в 32-х битной среде, используется Oracle Client 32-bit, а в 64-х битной среде используется Oracle Client 64-bit, поэтому может потребоваться сделать "tnsnames.ora" в обоих клиентах.

Что такое SERVICE_NAME и SID?

Подключение к базе данных по сети со стороны сервера обслуживает промежуточное ПО, называемое Listener.

SID это уникальный идентификатор базы данных Oracle на машине, а SERVICE_NAME, это идентификатор базы данных, заданный в Listener. Таким образом, одна и та же база данных, может быть доступна под разными SERVICE_NAME, но только под одним SID. Вас, поскольку Вы находитесь снаружи Listener-а, волнует SERVICE_NAME.

Как адресовать таблицы в Oracle?

По-умолчанию пользователь Oracle обращается к таблицам в своей схеме. Для того, что бы запрос обращался к одним и тем же таблицам из под любого пользователя, нужно указывать имя схемы перед точкой. Например, BM9.BM_CUSTOMER_CONTACT адресует таблицу BM_CUSTOMER_CONTACT в схеме BM9.

Что такое схема и база данных в Oracle?

База данных в СУБД Oracle = отдельный набор процессов СУБД с общей памятью.

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

Таблицы с одинаковыми именами могут существовать одновременно в разных схемах.

Почему не удается определить OCI environment (например, в Attunity)?

Приложение использующее Oracle Client должно каким-то образом его найти. Путь установки Oracle Client добавляется в %PATH% Oracle Installer-ом при установке. Но следует иметь ввиду, что переменные окружения устанавливаются процессу при запуске и, к примеру, Visual Studio (BIDS, Data Tools) запущенная до установки клиента, требует перезапуска, что бы начать использовать новый %PATH%.

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

Как настроить символьную кодировку Oracle Client?

Неверно настроенная кодировка может влиять как на получаемые данные, так и на выполнение запросов. Это может проявляться в том, что REPLACE(table_column, 'А', 'Б') в одном инструменте работает, а в другом нет, потому, что литералы ‘А’ и ‘Б’, поступающие в БД, воспринимаются иначе в одном из инструментов.

Для 32-х разрядного клиента в реестре в [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE] установите параметр "NLS_LANG"="RUSSIAN_CIS.CL8MSWIN1251" (типа REG_SZ).

Для 64-х разрядного клиента в реестре в [HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE], аналогично, установите параметр "NLS_LANG"="RUSSIAN_CIS.CL8MSWIN1251" (типа REG_SZ).

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

Доступность
Необходима дневная доступность данных по времени мск (7:00 - 21:00).

автор
Доступность Необходима дневная доступность данных по времени мск (7:00 - 21:00).

автор
Замечания - Объём данных довольно большой, в день имеем до 3-4 млн авторизаций в OLTP. - Источник данных - OLTP-система, работающая под управлением Oracle 10.2.0.5. - На начальном этапе хотим сделать хранилище на том же экземпляре Oracle, что и OLTP-система. Если будут проблемы с вводом-выводом, то DWH отсаживается на отдельную дисковую группу от OLTP-системы. - В идеале хочется сделать хранилище независимым от OLTP, т.е. необходимо разработать механизм переноса изменённых данных (а не перекачивать полные снимки таблиц).

автор

PranT
В данный момент имеется логический дизайн хранилища, согласованный с аналитиками. Требуется: - грамотная реализация физического дизайна (таблицы фактов, измерений, индексы, MV и т.д.); - разработка процедуры переноса данных (ETL). К сожалению, знаний по этим двум пунктом у меня не достаточно, поэтому и прошу дать совета. :)

PranT

оч. хорошо, что начинаете формализовать задачу.

Архитектура КИС

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

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

Первоначально системы такого уровня базировались на классической двухуровневой клиент-серверной архитектуре (Two-tier architecture) (рис. 3.1).

Рисунок 3.1 - Двухуровневая клиент-серверная архитектура

Данная клиент-серверная архитектура характеризуется наличием двух взаимодействующих самостоятельных модулей - автоматизированного рабочего места (АРМа) и сервера базы данных, в качестве которого может выступать Microsoft SQL Server, Oracle, Sybase и другие. Сервер БД отвечает за хранение, управление и целостность данных, а также обеспечивает возможность одновременного доступа нескольких пользователей. Клиентская часть представлена так называемым “толстым” клиентом, то есть приложением (АРМ) на котором сконцентрированы основные правила работы системы и расположен пользовательский интерфейс программы. При всей простоте построения такой архитектуры, она обладает множеством недостатков, наиболее существенные из которых - это высокие требования к сетевым ресурсам и пропускной способности сети компании, а также сложность обновления программного обеспечения из-за “размазанной” бизнес-логики между АРМом и сервером БД. Кроме того, при большом количестве АРМов возрастают требования к аппаратному обеспечению сервера БД, а это, как известно, самый дорогостоящий узел в любой информационной системе.

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

Рисунок 3.2 - Трехуровневая клиент-серверная архитектура (Three-tier architecture)

Плюсы данной архитектуры очевидны. Благодаря концентрации бизнес-логики на сервере приложений, стало возможно подключать различные БД. Теперь, сервер базы данных освобожден от задач распараллеливания работы между различными пользователями, что существенно снижает его аппаратные требования. Также снизились требования к клиентским машинам за счет выполнения ресурсоемких операций сервером приложений и решающих теперь только задачи визуализации данных. Именно поэтому такую схему построения информационных систем часто называют архитектурой “тонкого” клиента.

Но, тем не менее, узким местом, как и в двухуровневой клиент-серверной архитектуре, остаются повышенные требования к пропускной способности сети, что в свою очередь накладывает жесткие ограничения на использование таких систем в сетях с неустойчивой связью и малой пропускной способностью (Internet, GPRS, мобильная связь).

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

Рисунок 3.3 - Распределенная архитектура системы

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

Более 95 % данных, используемых в управлении предприятием, могут быть размещены на одном персональном компьютере, обеспечив возможность его независимой работы. Поток исправлений и дополнений, создаваемый на этом компьютере, ничтожен по сравнению с объемом данных, используемых при этом. Поэтому если хранить непрерывно используемые данные на самих компьютерах, и организовать обмен между ними исправлениями и дополнениями к хранящимся данным, то суммарный передаваемый трафик резко снизиться. Это позволяет понизить требования к каналам связи между компьютерами и чаще использовать асинхронную связь, и благодаря этому создавать надежно функционирующие распределенные информационные системы, использующие для связи отдельных элементов неустойчивую связь типа Интернета, мобильную связь, коммерческие спутниковые каналы. А минимизация трафика между элементами сделает вполне доступной стоимость эксплуатации такой связи. Конечно, реализация такой системы не элементарна, и требует решения ряда проблем, одна из которых своевременная синхронизация данных.

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

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

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

Читайте также: