Нажмите "Enter", чтобы перейти к содержанию

Сервер хранилище данных: Купить Сетевое хранилище (NAS) Zyxel NAS326 в интернет магазине DNS. Характеристики, цена Zyxel NAS326

Содержание

Построение бюджетной системы хранения данных

Зависимость бизнес-процессов предприятия от ИТ-сферы постоянно растет. На сегодня вопросу непрерывности работы ИТ-сервисов уделяют внимание не только крупные компании, но и представители среднего, а зачастую и малого бизнеса.

Одним из центральных элементов обеспечения отказоустойчивости является система хранения данных (СХД) – устройство на котором централизовано храниться вся информация. СХД характеризуется высокой масштабируемостью, отказоустойчивостью, возможностью выполнять все сервисные операции без остановки работы устройства (в том числе замену компонентов). Но стоимость даже базовой модели измеряется в десятках тысяч долларов. Например, Fujitsu ETERNUS DX100 с 12-ю дисками Nearline SAS 1Tb SFF (RAID10 6TB) стоит порядка 21 000 USD, что для небольшой компании очень дорого.

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

Для его реализации предлагаем использовать CEPH.

Что такое CEPH и как он работает?

CEPH – хранилище на базе свободного ПО, представляет из себя объединение дисковых пространств нескольких серверов (количество серверов на практике измеряется десятками и сотнями). CEPH позволяет создать легкомасштабируемое хранилище с высокой производительностью и избыточностью ресурсов. CEPH может использоваться как в качестве объектного хранилища (служить для хранения файлов) так и в качестве блочного устройства (отдача виртуальных жестких дисков).

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

Рисунок 1 — Распределение блоков данных

Если на серверах не используются отказоустойчивые дисковые массивы, для надежного хранения данных рекомендуется использовать более высокое значение фактора репликации. В случае выхода из строя одного из серверов CEPH фиксирует недоступность блоков данных (рисунок 2), которые на нем размещены, ожидает определенное время (параметр настраивается, по умолчанию 300 сек.), после чего начинает воссоздание недостающих блоков информации в другом месте (рисунок 3).

Рисунок 2 — Выход из строя одной ноды


Рисунок 3 — Восстановление избыточности

Аналогично, в случае добавления в кластер нового сервера происходит ребаллансировка хранилища с целью равномерного заполнения дисков на всех нодах. Механизм который контролирует процессы распределения блоков информации в кластере CEPH называется CRUSH.

Для получения высокой производительности дискового пространства в кластерах CEPH рекомендуется использовать функционал cache tiering (многоуровневое кэширование). Смысл его заключается в том, чтобы создать отдельный высокопроизводительный пул и использовать его для кэширования, основная же информация будет размещена на более дешевых дисках (рисунок 4).

Рисунок 4 — Логическое представление дисковых пулов

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

Рисунок 5 — Принцип работы кэш-тирринг


Рассмотрим реальные сценарии использования CEPH в организации для создания хранилища данных. В качестве потенциального клиента рассматриваются организации малого и среднего бизнеса, где будет наиболее востребована эта технология. Мы рассчитали 3 сценария использования описанного решения:

  1. Производственное или торговое предприятие с требованием к доступности внутренней ERP системы и файлового хранилища 99,98% в год, 24/7.
  2. Организация, которой для ее бизнес-задач требуется развернуть локальное частное облако.
  3. Очень бюджетное решение для организации отказоустойчивого блочного хранилища данных, полностью независимое от аппаратного обеспечения с доступностью 99,98% в год и недорогим масштабированием.

Сценарий использования 1. Хранилище данных на базе CEPH

Рассмотрим реальный пример применения CEPH в организации. Например, нам требуется отказоустойчивое производительное хранилище объемом 6 Тб, но затраты даже на базовую модель СХД с дисками составляют порядка $21 000.

Собираем хранилище на базе CEPH. В качестве серверов предлагаем использовать решение Supermicro Twin (Рисунок 6). Продукт представляет собой 4 серверные платформы в едином корпусе высотой 2 юнита, все основные узлы устройства дублируются, что обеспечивает его непрерывное функционирование. Для реализации нашей задачи будет достаточно использовать 3 ноды, 4-я будет в запасе на будущее.


Рисунок 6 — Supermicro Twin

Комплектуем каждую из нод следующим образом: 32 Гб ОЗУ, 4-х ядерный процессор 2,5 Ггц, 4 SATA диска по 2 Тб для пула хранения объединяем в 2 массива RAID1, 2 SSD диска для пула кэширования также объединяем в RAID1. Стоимость всего проекта указана в таблице 1.

Таблица 1. Комплектующие для хранилища на базе CEPH

Комплектующие Цена, USD Кол-во Стоимость, USD
Supermicro Twin 2027PR-HTR: 4 hot-pluggable systems (nodes) in a 2U form factor. Dual socket R (LGA 2011), Up to 512GB ECC RDIMM, Integrated IPMI 2.0 with KVM and Dedicated LAN. 6x 2.5″ Hot-swap SATA HDD Bays. 2000W Redundant Power Supplies 4 999,28 1 4 999,28
Модуль памяти Samsung DDR3 16GB Registered ECC 1866Mhz 1. 5V, Dual rank 139,28 6 835,68
Процессор Ivy Bridge-EP 4-Core 2.5GHz (LGA2011, 10MB, 80W, 22nm) Tray 366,00 3 1 098,00
Жесткий диск SATA 2TB 2.5″ Enterprise Capacity SATA 6Gb/s 7200rpm 128Mb 512E 416,00 12 4 992,00
Твердотельный накопитель SSD 2.5» 400GB DC S3710 Series. 641,00 6
3 846,00
ИТОГО 15 770,96

Вывод: В результате построения хранилища получим дисковый массив 6Tb c затратами порядка $16 000, что на 25% меньше чем закупка минимальной СХД, при этом на текущих мощностях можно запустить виртуальные машины, работающие с хранилищем, тем самым сэкономить на покупке дополнительных серверов. По сути – это законченное решение.

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

Сценарий использования 2. Построение частного облака

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

Построение даже небольшого облака состоящего из например из 3-х носителей примерно в $36 000: $21 000 – стоимость СХД + $5000 за каждый сервер с 50% наполнением.

Использование CEPH в качестве хранилища позволяет совместить вычислительные и дисковые ресурсы на одном оборудовании. То есть не нужно закупать отдельно СХД — для размещения виртуальных машин будут использоваться диски установленные непосредственно в серверы.

Краткая справка:
Классическая облачная структура представляет из себя кластер виртуальных машин, функционирование которых обеспечивают 2 основных аппаратных компонента:

  1. Вычислительная часть (compute) — серверы, заполненные оперативной памятью и процессорами, ресурсы которых используются виртуальными машинами для вычислений
  2. Система хранения данных (storage) – устройство наполненное жесткими дисками, на котором хранятся все данные.

В качестве оборудования берем те же серверы Supermicro, но ставим более мощные процессоры – 8-ми ядерные с частотой 2,6 GHz, а также 96 Гб ОЗУ в каждую ноду, так как система будет использоваться не только для хранения информации, но и для работы виртуальных машин. Набор дисков берем аналогичный первому сценарию.

Таблица 2. Комплектующие для частного облака на базе CEPH

Комплектующие Цена, USD Кол-во Стоимость, USD
Supermicro Twin 2027PR-HTR: 4 hot-pluggable systems (nodes) in a 2U form factor. Dual socket R (LGA 2011), Up to 512GB ECC RDIMM, Integrated IPMI 2.0 with KVM and Dedicated LAN. 6x 2.5″ Hot-swap SATA HDD Bays. 2000W Redundant Power Supplies 4 999,28 1 4 999,28
Модуль памяти Samsung DDR3 16GB Registered ECC 1866Mhz 1. 5V, Dual rank 139,28 18 2 507,04
Процессор Intel Xeon E5-2650V2 Ivy Bridge-EP 8-Core 2.6GHz (LGA2011, 20MB, 95W, 32nm) Tray 1 416,18 3 4 248,54
Жесткий диск SATA 2TB 2.5″ Enterprise Capacity SATA 6Gb/s 7200rpm 128Mb 512E 416 12 4 992,00
Твердотельный накопитель SSD 2.5» 400GB DC S3710 Series. 641 6 3 846,00
ИТОГО 20 592,86

Собранное облако будет иметь следующие ресурсы с учетом сохранения стабильности при выходе из строя 1-й ноды:

  • Оперативная память: 120 Гб
  • Дисковое пространство 6000 Гб
  • Процессорные ядра физические: 16 Шт.

Собранный кластер сможет поддерживать порядка 10 средних виртуальных машин с характеристиками: 12 ГБ ОЗУ / 4 процессорных ядра / 400 ГБ дискового пространства.

Также стоит учесть что все 3 сервера заполнены только на 50% и при необходимости их можно доукомплектовать, тем самым увеличив пул ресурсов для облака в 2 раза.

Вывод: Как видим, мы получили как полноценный отказоустойчивый кластер виртуальных машин, так и избыточное хранилище данных — выход из строя любого из серверов не критичен – система продолжит функционирование без остановки, при этом стоимость решения примерно в 1,5 раза ниже, чем купить СХД и отдельные сервера.

Сценарий использования 3. Построение сверхдешевого хранилища данных

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

Предлагаем рассмотреть следующую структуру: закупается 4 серверные ноды, в каждый сервер ставиться по 1 SSD-диску для кэширования и по 3 SATA диска. Серверы Supermicro с 48 ГБ ОЗУ и процессорами линейки 5600 можно сейчас купить примерно за $800.

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

Таблица 3. Комплектующие для стореджа

Комплектующие Цена, USD Кол-во Стоимость, USD
SUPERMICRO 2*Xeon 5645, 48 ГБ ОЗУ (б/у) 800 4 3200
Жесткий диск SATA 2TB Western Digital RAID EDITION 130 12 1560
Твердотельный накопитель SSD 2. 5» 400GB DC S3710 Series. 641 4 2560
ИТОГО 7324

Вывод: В случае необходимости в данном решении можно использовать диски большего объема, либо заменить их на SAS, если нужно получить максимальную производительность для работы СУБД. В данном примере в результате получим хранилище объемом 8 ТБ с очень низкой стоимостью и очень высокой отказоустойчивостью. Цена одного терабайта получилась в 3,8 раза дешевле, чем при использовании промышленной СХД за $21000.

Итоговая таблица, выводы

Конфигурация СХД Fujitsu ETERNUS DX100 + 12 Nearline SAS 1Tb SFF (RAID10) СХД Fujitsu ETERNUS DX100 + 12 Nearline SAS 1Tb SFF (RAID10) + Supermicro Twin Наш сценарий 1: хранилище на базе CEPH Наш сценарий 2: построение частного облака Нашсценарий 3: построение сверхдешевого хранилища
Полезный обьем, ГБ 6 000 6 000 6 000 6000 8 000
Цена, USD 21000 36000 15 770 20 592 7 324
Стоимость 1 ГБ, USD 3,5 6 2,63 3,43 0,92
Количество IOPs* (чтение 70%/запись 30%, Размер блока 4К) 760 760 700 700 675
Назначение Хранилище Хранилище + Вычисление Хранилище + Вычисление Хранилище + Вычисление Хранилище + Вычисление

*Расчет количества IOPs выполнен для созданных массивов из дисков NL SAS на СХД и дисков SATA на сторедже CEPH, кэширование отключалось для чистоты полученных значений. При использовании кэширования показатели IOPs будут значительно выше до момента заполнения кэша.


В итоге можно сказать, что на основе кластера CEPH можно строить надежные и дешевые хранилища данных. Как показали расчеты, использовать ноды кластера только для хранения не очень эффективно – решение выходит дешевле чем закупить СХД, но не на много – в нашем примере стоимость хранилища на CEPH была примерно на 25% меньше чем Fujitsu DX100. По-настоящему экономия ощущается в результате совмещения вычислительной части и хранилища на одном оборудовании — в таком случае стоимость решения будет в 1,8 раз меньше, чем при построении классической структуры с применением выделенного хранилища и отдельных хост-машин.

Компания EFSOL реализует данное решение по индивидуальным требованиям. Мы можем использовать имеющееся у вас оборудование, что ещё более снизит капитальные затраты на внедрение системы. Свяжитесь с нами и мы проведем обследование вашего оборудования на предмет его использования при создании СХД.

Корпоративные хранилища данных для начинающих » Администрирование серверов

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

Блочное хранилище

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

Дедупликация

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

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

Fibre Channel

Fibre Channel — технология, широко исполь­зуемая для высокоскоростной передачи данных в сетевых системах хранения. Название Fibre Channel указывает на использование оптоволоконного кабеля. Сегодня, однако, существуют стандарты, позволяющие реализовать коммуникации Fibre Channel и по кабелю Ethernet.

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

Флеш-массив

Массивы существовали всегда и, по сути, представляют собой комбинацию жестких дисков, под­готавливаемых к работе различными способами. Флеш- массив — это система хранения данных, состоящая из нескольких флеш-накопителей (как правило, твердотель­ных (SSD) дисков) вместо вращающихся жестких дисков.

Хост-адаптер шины

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

NAS

NAS, или «запоминающее устройство, подключаемое к сети», представляет собой массив хранения данных, который можно подключать напрямую к сети Ethernet. Доступ к хранилищу NAS обычно осуществляется по SMB или аналогичному протоколу. Устройства NAS, как правило, дешевле и проще, чем файловые серверы. Практически для каждого сценария использования существуют устройства NAS, от оборудования корпоративного класса до небольших устройств потребительского уровня.

Объектное хранилище

Объектное хранилище — это высо­комасштабируемая архитектура хранения, которая давно популярна у поставщиков общедоступных «облачных» решений, а сегодня находит применение и в корпоратив­ных средах. В отличие от блочного хранилища, объектное хранилище не использует ни файловую систему, ни блоки данных. Вместо этого файлы (и их метаданные) сохраняются в плоском адресном пространстве.

RAID

Термин RAID, или «избыточный массив независимых дисков», в обобщенном смысле применим к различным архитектурам хранения, где требуемая логическая структура реализуется путем комбинирования нескольких жестких дисков, физических или виртуальных. Например, комбинация дисков может решать задачу достижения дополнительного объема памяти, сохранения работоспо­собности в случае отказа одного или нескольких дисков либо повышения производительности.

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

SAN

SAN, или «сеть хранения данных», — это особый тип высокопроизводительной сети, используемой исключи­тельно для хранения данных. Хотя SAN обязательно требует подключения к основным сетевым ресурсам, в частности серверам, эта сеть обычно не используется для общего сетевого трафика, но лишь для трафика, относящегося к хранению данных. Вместо универсальных сетевых протоколов для трафика SAN часто применяются транспортные протоколы, как в системах хранения (например, SCSI).

SSD

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

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

Источник: журнал «Windows IT Pro/RE»

Внешнее хранилище данных ~ COOLHOUSING s.r.o.

Для Вам требуется больше пространства на диске для услуг хостинга? Вам понравилось бы отдельное хранилище данных для их резервирования? Или вам нужен для собственного сервера достаток места на диске с минимальными издержками на администрирование? Then this external data storage service is exactly what you need.

Объемы до 1 TБ для проектов небольшого масштаба в качестве замены недостаточного места на диске на виртуальном сервере или в качестве хранилища резервированных данных рекомендуем размещать в общих совместно используемых хранилищах данных. Для масштабных проектов или в качестве совершенно отдельных вариантов рекомендуем использовать соответствующие хранилища данных в виде выделенных NAS.


Совместно используемое хранилище данных

  • безопасное хранилище данных с дисками в RAID
  • поддержка протоколов SFTP, RSYNC, FTP, SMB, NFS
  • нулевые требования к администрированию и защите
  • простота использования

Отдельное хранилище данных

  • малый сервер с простым веб-администрированием
  • сервер для фалов, веб-сайта, e-mail, скачивания
  • доступность хранилища в любое время, из любого места и при помощи любого средства
  • возможность выкупа NAS за EUR 2

Совместно используемое сетевое хранилище данных

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

Доступ к хранилищу данных возможен при помощи протоколов SFTP, RSYNC, FTP, SMB и NFS, при этом первые два названные протокола могут быть зашифрованы и защищены посредством частного/общественного ключа. Все протоколы стандартным образом защищены именем доступа, паролем и ограничением доступа с конкретных IP адресов через сеть Coolhousing и через интернет. Доступ к одному хранилищу может быть разрешен для нескольких пользователей, включая возможность настройки прав только для чтения и записи.


25 GB € 2 /месяц
50 GB € 3,60 /месяц
100 GB € 6,40 /месяц
150 GB € 8,40 /месяц
250 GB € 12,80 /месяц
500 GB € 19,60 /месяц
Внешнее хранилище данных
25 GB € 2 /месяц
50 GB € 3,60 /месяц
100 GB € 6,40 /месяц
150 GB € 8,40 /месяц
250 GB € 12,80 /месяц
500 GB € 19,60 /месяц

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



Вы заинтересованы?
Свяжитесь с нами по электронной почте Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. или по телефону +420 220 000 900

Отдельное сетевое хранилище данных

Network Attached Storage, сокращенно NAS – это малый сервер, оснащенный слотами для жестких дисков, предназначенных для эксплуатации по схеме 24/7. К NAS нельзя присоединить клавиатуру, мышь и монитор – этот сервер управляется посредством очень простого веб-интерфейса, следовательно управлять им может почти каждый. NAS выполняет прежде всего функцию центрального хранилища ваших данных, в т.ч. резервированных, тем не менее в наше время он также может предложить целый ряд других специализированных функций. К их числу относятся, например, веб-сервер, сервер базы данных, почтовый сервер, он также может быть клиентом для автоматического скачивания данных в различных сетей P2P, например BitTorent.


Monthly fee from € 38,33 € 68,57 € 211,25 € 211,25
Setup fee € 0 € 0 € 0 € 0
Payment period
mon. / quar.
half. / yearly
/
/
/
/
/
/
/
/
Processor Marvell Armada 88F6707
(1C, 1T, 256k, 1.20 GHz)
Marvell Kirkwood 88F6282
(1C, 1T, 256k, 1.60 GHz)
Intel Celeron N3150
(4C, 4T, 2M, 1.60 GHz)
Intel Atom C2538
(4C, 4T, 2M, 2.40 GHz)
RAM 256 MB DDR3 512 MB DDR3 4 GB DDR3 6 GB DDR3
Hard drive 1× 1 TB SATA-6G 2× 1 TB SATA-6G 4× 1 TB SATA-6G 5× 1 TB SATA-6G
Maximum storage capacity 1 TB 2 TB 4 TB 5 TB
RAID support
(JBOD, RAID 0, 1)

(JBOD, RAID 0, 1, 5, 6, 10, 5 + spare)

(Hybrid RAID, RAID 0, 1, 5, 6, 10, 5 + spare)
Storage/File server
Web/FTP/Mail server
Surveillance/recording from IP cameras
Download server
Shared connectivity 100 Mbps 100 Mbps 100 Mbps 100 Mbps
Data transfers unlimited unlimited unlimited unlimited
Full HW service
Easy web management
NAS purchase price
(after 24 months)
€ 3 € 3 € 3 € 3
Order! Order! Order! Order!

Услугу по предоставлению отдельного хранилища данных можно заказать отдельно. На предоставление услуги распространяются те же правила, что и на услугу выделенного сервера, в т.ч. бесплатного сервисного обслуживания аппаратного оснащения в течение всего срока пользования услугой, а также возможности выкупа оборудования за 59 CZK после окончания действия двухлетнего договора.

Домашнее хранилище данных — возможные варианты

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

Суть проблемы

Думаю, практически у всех постепенно копятся какие-либо файлы, которые очень хочется сохранить, и чтобы с которыми ничего не произошло. Взять хотя бы домашний фото- и видеоархив. Мир меняется, и на смену альбомам с бумажными фотографиями пришли современные технологии. С ними же пришли и объемы, которые занимает все это «хозяйство». Фотографии «весят» все больше, видеоролики, снятые в FullHD (про 4K и выше даже говорить страшно) тоже все больше поражают количеством гигабайт.

Возникает два вопроса: где это хранить и… опять-таки, где хранить то же самое, но уже в виде резервных копий. Надеюсь, священная мантра «обязательно делайте бэкапы» для вас действительно священна.

Свежекупленный диск на 4 (6, 8 и т. д.) терабайт кажется бездонным. Поначалу. Если туда складировать коллекцию любимой музыки (особенно если вы почитатель действительно качественно звука и до MP3 не «опускаетесь»), аудиокниги, фильмы, сериалы и проч., то быстро оказывается, что диск то уже почти заполнен. А резервные копии? Их же надо хранить на ДРУГОМ носителе.

Значит, надо как минимум 2 диска, или надо распихивать все свое хозяйство по облачным хранилищам. Вот только бесплатно дается места там совсем немного. Правда, можно заплатить n-ую сумму и купить много сотен гигабайт или даже терабайты на одном-двух, но вы готовы на эти траты? А вдруг что-то произойдет, и доступ к данным прервется? Да и сам факт, что что-то личное лежит где-то там, неизвестно где…

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

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

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

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

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

Домашнее хранилище самолепное — из того, что удалось наскрести по сусекам

У многих после очередного апгрейда компьютера остаются комплектующие, которые уже морально (но не физически) устарели, современным реалиям не соответствуют, но вполне могут послужить для сборки чего-то… Да чего, собственно, думать то? Core i7 или AMD Ryzen для дискового хранилища избыточны. Правда, если у вас отработал свое старенький i5, то почему бы и нет.

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

Итак, основные требования к такому компьютеру несколько специфические. Высокая производительность не требуется, и тем более, если планируется работа собираемого хранилища в режиме 24/7, то чем менее мощной оно будет, тем меньше платить за электричество.

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

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

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

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

Скорее всего, не будет возможности «горячей» замены дисков. Насколько принципиально вам такое ограничение? Да, для вытаскивания вышедшего из строя накопителя и установки нового придется открыть корпус, выкручивать диск, ставить новый. Но как часто это приходится делать?

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

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

DAS – готовое, но недорогое

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

Упомянул я такие накопители не просто так, а потому, что они дают представление о том, что же такое DAS — Direct Attached Storage (устройства с прямым подключением к компьютеру). Способ подключения примерно тот же, с помощью USB, хотя в данном случае возможны варианты с использованием eSATA или что-то иное.

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

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

Из минусов следует отметить, что DAS – это не самостоятельное устройство в домашней сети, как собранное «на коленке» из подручных материалов домашнее хранилище или NAS, а подключаемое непосредственно к какому-либо компьютеру хранилище.

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

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

Еще один вариант – использовать DAS в качестве устройства, позволяющего расширить объем имеющегося в домашнем хозяйстве NAS. Проще говоря – подключить DAS к NAS, например, при помощи USB. Тут вполне могут возникнуть проблемы с совместимостью, и в каких-то сочетаниях эти накопители откажутся работать вместе, но это уже вопрос подбора конкретных моделей.

Кстати, в идеальной ситуации, имея небольшой, недорогой NAS на два или даже 1 диск, вполне можно будет обойтись без покупки более емкой модели, а «пристегнуть» к нему DAS. Для домашней «файлопомойки» решение вполне годное, да еще и экономящее средства.

NAS – круто, но недешево

Во многом – идеальный вариант решения задачи с устройством домашнего хранилища. NAS – Network-attached storage (хранилище, подключаемое по сети). Во многом напоминая рассмотренный ранее вариант, эта разновидность отличается наличием сетевого интерфейса, собственным, порой, весьма продвинутым софтом и, к сожалению, далеко не самой маленькой ценой.

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

Есть возможность установки ряда дополнительных приложений (например, торрент-клиентов, принт-серверов, медиаплееров и т. п.). Впрочем, все это часто имеется уже в комплекте. Остается только установить диски, собрать массив (естественно, поддержка RAID присутствует), настроить хранилище, раздать права – и все, можно пользоваться.

Одна беда у этого варианта – цена. На 4-дисковое устройства придется потратить не меньше 200 долларов, а более продвинутые, мощные NAS потребуют гораздо больших сумм. И это без учета самих дисков, которые тоже недешевы.

Заключение. Домашнее хранилище данных – удобно, нужно, но требует некоторых затрат

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

Если действительно дорожите тем, что хранится у вас на жестких дисках, то все же стОит задуматься о том или ином варианте защищенного от сбоев хранилища. Пусть даже это будет несколько дисков в системном блоке, но хотя бы собрать их в RAID.

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

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

Есть и альтернативные решения. Например, HP ProLiant MicroServer, благополучно добравшийся уже до 10-го поколения. Это действительно полноценный сервер, только микро. С RAID-контроллером и всеми прочими атрибутами для создания сервера для дома или небольшого офиса.

Я и сам сейчас раздумываю над приобретением небольшого устройства, правда пока не определился, раскошелиться ли на недорогой NAS — требования у меня к нему невысокие, потому и дорогое устройство с кучей функций мне не надо), или обойтись DAS.

Кстати, для установки в NAS (DAS, домашний сервер), особенно при создании RAID-массива, жесткие диски тоже надо подбирать соответствующие. Любые брать нежелательно. О выборе таких накопителей опять-таки поговорим как-нибудь в другой раз.

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

Кстати, а вы уже сделали бэкап?

Сетевые хранилища (NAS) — ROZETKA

Приобрести сетевое хранилище (NAS) не сложно, если правильно подобрать товар с нужными характеристиками. Многие задаются вопросом что это и как работает. Представляет систему хранения данных с неким дисковым массивом, который подключается к локальной сети и поддерживает функциональность по принятым протоколам.  

Какое изделие выбрать

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

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

Основные виды и технические показатели сетевых хранилищ (NAS)

Выделяют множество разновидностей. По виду форм-фактора различают стандартные и стоечные. Вторые достаточно надёжные, имеют высокую производительность и высокий показатель ёмкости хранения – как минимум четыре диска. В них есть два блока питания. Часто применяются в домашних условиях, на офисе, предприятиях.

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

Для хранения файлов используют параметры RAID, которые позволяют воспринимать несколько установленных дисков как единое целое. Обычно комплектуется 7 основными и 3 дополнительными видами массивов, каждый из которых имеет определённое значение. Основные: RAID 0-6, вспомогательные – RAID 10, 50, 60.

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

Такие типы сетевых хранилищ (NAS) потребляют не большое количество электроэнергии. Специальная программная платформа следит за администрированием, наличием нужных функций. Сегодня многие используют для подключения к управляемой панели браузеры. Они бывают двух типов — фирменные и сторонние. Первые пишутся представителями DiskStation Manager от Synology. Второй тип от изготовителей, которые не участвуют в комплектации и дальнейшем производстве продукции, например, как Microsoft.

Сколько портов, отверстий и интерфейсов зависит от модели. USB порты могут достигать от двух до шести или больше. Возможно подключение отдельных функций: твердотельных SSD, жёсткие диски, Wi-Fi, флэш память, принтеры и т.д. Портов Ethernet насчитывается до четырёх. Определённые типы комплектуются HDD, FireWire. Выделяют таких известных производителей, как Bufallo, D-Link, Seagate, Synology и другие.

Бывают с установленным Wi-Fi маршрутизатором, если нет такой функции, то приходится соединяться через роутер. Благодаря этому можно соединить всю технику, такую как ПК, планшет, телевиденье и хранилища, в единую локальную сеть. Если подключить интернет, то это позволит пользоваться личными файлами из глобальной сети. Многие модели имеют встроенный вентилятор, чтобы устройства не перегревались и для охлаждения жёстких дисков. Возможно наличие нескольких разъёмов для питания, что позволяет соединяться с источником бесперебойного питания.

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

Построение хранилища данных центра ЕСИМО на основе инструментов Oracle

Построение хранилища данных центра ЕСИМО на основе инструментов Oracle

А. А. Федорцов

Введение

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

В настоящий момент инфраструктура центрального узла ЕСИМО на площадке г.Обнинска ГУ “ВНИИГМИ-МЦД”, включает в себя четыре сервера баз данных (два основных DBServ, RealTime), хранилище данных – DBGlobal и резервный сервер БД Standby с управляющим сервером резервирования GridControl, сервер приложений портала ЕСИМО APServ, cервер интеграции — SI, cервер “Поставщик данных” — DP, отладочный комплекс APTest сервера приложений JBOSS. Состав серверов и программных средств представлен на рис.1.

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


Рис. 1. Состав серверов и программных средств.

1. Методика

Для того чтобы система ЕСИМО соответствовала заявленным требованиям (построение дополнительного узла) была спроектирована новая схема (рис. 2).


Рисунок 2. – Физическая схема взаимодействия серверов ЕСИМО.

Реструктуризация схемы направлена, в основном, на создание новых направлений потоков данных (репликаций, рис. 3). В новой схеме вся работа с изменением, обновлением, удалением данных ведется в Хранилище данных (сервер DBGLOBAL#1), которые впоследствии реплицируются в оперативные БД (БД WO, располагающиеся на сервере DBServ#1 и DBServ#2) . Оперативная БД, в свою очередь, предоставляет данные только для просмотра, никаких изменений в этих БД не допустимо. В дополнении, оперативные БД принимают реплицируемые данные из Хранилища данных по расписанию.


Рис.3 – направления потоков репликации данных БД ЕСИМО.

2. Репликация

Репликация в Oracle предоставляет метод тиражирования данных и объектов (таблицы, последовательности, объекты PL/SQL и т.д.) среди нескольких БД. Существуют два механизма: репликация снапшотов и репликация с несколькими ведущими узлами. Определение последнего в терминах Oracle звучит так: “репликация с несколькими ведущими узлами, также известная как равноправная (peer-to-peer) или n-маршрутная (n-way) репликация, предоставляет нескольким узлам, действующим на равноправных условиях, возможность управлять реплицируемыми объектами. Приложения могут модифицировать любую реплицированную таблицу на любом узле”. По существу, репликация с несколькими ведущими узлами позволяет создавать распределенные БД, где каждая ведущая БД (master database) содержит самые последние данные и самые последние изменения в схеме. Это отличает ее от репликации снапшотов, которая в определенный момент времени копирует данные с ведущего узла (master site).

2.1 Репликация схем

В соответствии с новой схемой построения централизованного хранилища данных, данные из Хранилища Данных в оперативные БД и тестовую БД необходимо реплицировать определенным перечнем схемам (рис. 4). Такой подход снижает риски отсутствия в целевой БД (БД в которую производят репликацию данных) новых объектов, которые были созданы в схеме БД источника (БД из которой реплицируют данные). Используя данную методику, после того, как в схеме источника появляется объект, он автоматически реплицируется в схему приемника.


Рис. 4 – репликация заданного перечня схем на примере хранилища и одной оперативной БД

2. 1.1 Репликация данных в оперативные БД

Источником данных для репликации в оперативные БД служит хранилище данных (сервер DBGLOBAL#1, БД Dbglobal). Репликации подвергается 30 схем.

Приемником реплицируемых данных выступают две идентичные оперативные БД “WO”, одна БД находится на сервере DBServ#1 в г. Обнинске, вторая на сервере DBServ#2 – г. Москва (рис. 2). Схематически потоки данных на рисунке 3 отмечены цифрами “(1)” и “(2)”.

2.1.2 Репликация данных в тестовую БД

Источником данных для репликации в тестовую БД служит хранилище данных (сервер DBGLOBAL#1, БД Dbglobal). Репликации подвергаются 30 схем.

Приемником реплицируемых данных выступает БД “DBTEST” на сервере APTest#1 в г. Обнинске. Схематически поток данных на рисунке 3 отмечен цифрой “(3)”.

2.1.3 Репликация данных в Хранилище данных

Источником данных для репликации в хранилище данных (сервер DBGLOBAL#1, БД Dbglobal) является база оперативных данных “WEB”, располагающаяся на сервере RealTime#1(рис2). Схематически поток данных на рисунке 3 отмечен цифрой “(4)”.

Поскольку в Хранилище данных уже существуют схемы с одинаковыми названиями, необходимо провести анализ существующих схем в приемнике (БД “DBGLOBAL”) и источнике (БД “WEB”). Требуется выявить, нет ли в источнике используемых объектов с такими же названиями, что и в приемнике, но с разным функционалом.

2.2 Организация потоков переноса данных

При внесении изменений в схему Хранилища данных, которая находится в списке схем, подверженных репликации, необходимо эти данные реплицировать не в одну БД, а несколько. Так некоторые схемы реплицируются не в одно место назначения, а как минимум в 3 (тестовая БД, оперативные БД на площадке г. Обнинска и г. Москвы). В связи с этим, патоки данных организовываются следующим образом:

первый поток : (STREAMS_CAPTURE_WO_OBNINSK_Q) реплицирует данные в оперативную БД “WO” на площадке г. Обнинска каждые 2 часа

второй поток: (STREAMS_CAPTURE_WO_MOSKOW_Q) реплицирует данные в оперативную БД “WO” на площадке г. Обнинска каждые 2 часа

третий поток: (STREAMS_CAPTURE_TEST_OBNINSK_Q) реплицирует данные в тестовую БД “DBTEST” на площадке г. Обнинска каждые 2 дня

3. Резервирование ХД

У любой производственной БД должна быть возможность восстановиться после сбоя. Хранилище данных выступает в роли важного стратегического объекта работы ЕСИМО и требует тщательного проектирования режима архивирования и восстановления. Для таких нужд, предлагается использовать возможности Oracle Recovery Manager.

Для работы RMAN необходимо чтобы БД работала в режиме архивирования (archive mod). Когда БД работает в режиме архивирования, СУБД Oracle создает журналы изменений (архивные журналы), которые сохраняются на диске сервера. Чем выше активность БД, тем больше суммарные суточные объемы архивных журналов. К примеру, оперативная БД WO на данный момент генерирует в среднем 10Гб журналов изменения. С такой скоростью роста журналов, свободного дискового пространства может надолго не хватит. Для этих целей организовывается передача журналов изменений с сервера Хранилища данных на ленточную библиотеку IBM Z900. После того, произведены соответствующие настройки для передачи архивных журналов и вспомогательных файлов, требуемых технологией RMAN для восстановления, у Хранилища данных появляется возможность восстанавливать данные при сбое.

Резервирование должно происходить по следующей схеме:

  • создание наборов для резервирования (восстановления) должно осуществляться каждый день в 20.00 при помощи утилиты Oracle RMAN
  • копирование наборов для резервирования (восстановления) должно осуществляться каждый день в 21.00 при помощи утилиты Tivoli Storage Manager
  • запуск скрипта по очистке наборов для резервирования (восстановления) должен осуществляться каждый день в 23,00
  • хранение наборов для резервирования (восстановления) на ленточной библиотеке должно составлять 40 дней
  • хранение наборов для резервирования (восстановления) на сервере должно составлять 4 дня

4. Именование Объектов БД

4.1 Именование СХЕМ

В хранилище данных есть 3 типа схем, содержащих в себе разные объекты по назначению и использованию. Такими типами являются пользователи, приложения и схемы, хранящие данные. Дабы повысить порядок в БД, необходимо разделить именование разных типов схем в соответствии с префиксами

  • app_ — для схем, через которые приложения обращаются к БД (например: арр_soi, app_storm)
  • dat_ — для схем, в которых хранятся сырые данные (например: dat_black_sea, dat_ship)
  • usr _ — для схем, через которые работают пользователи (например: usr_Fedortsov, usr_Puzova )

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

4.2 Именование Объектов

Для упрощения понимания и поиска объектов в БД необходимо именовать их осмысленным способом. Имена должны быть не слишком короткими и не слишком длинными, должны отражать коротким именем свое предназначение. Именоваться объекты в БД должны в единственном числе. Именование представлений предлагается с использованием префикса “V_” (например: V_CRUISE_GEO_M, V_CODE2_M) для отсутствия путаницы между таблицами и представлениями. Для именования материализованных представлений предлагается использовать префикс “MV_” (например: MV_INFORMER, MV_BUOY)

Заключение

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

Список литературы

1. Белов С.В., Вязилов Е.Д., Сухоносов С.В., Карпенко Г.А., Казельсий И.И. Технология и опыт построения единой системы информации об обстановке в мировом океане для комплексного информационного обеспечения пользователей//Научный сервис в сети Интернет: технологии распределенных вычислений :Труды Всероссийской научной конференции.

2. Менаске Д., Альмейда В. Производительность Web-служб. Анализ, оценка и планирование. –М.: Санкт-Петербург, ДиаСофт, 2003. -С. 69-111.

3. Кенни Смит, Стефан Хейсли Резервное копирование и восстановление. –М.: Москва, Тиль-2004, 2005. -444с.

4. Менаске Д., Альмейда В. Производительность Web-служб. Анализ, оценка и планирование. –М.: Санкт-Петербург, ДиаСофт, 2003. -С. 349-352.

5. Денис Шаша, Филипп Бонне Оптимизация Баз данных. Принципы, практика, решение проблем. –М.: Москва, Кудиц-Образ, 2004. –С. 93-133.

6. Brad M.M. Using Performance Monitor to Identify SQL Server Hardware Bottlenecks – Режим доступа: http://www.sql-server-performance.com/articles/audit1.aspx свободный. — Яз. англ.

Bare-metal сервер для хранения данных

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

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

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

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

  • Синхронизация данных и оптимизация рабочих процессов.

  • Облачное резервное копирование. Возможность расширить инфраструктуру с помощью полнофункциональной автоматизированной системы резервного копирования и восстановления данных. Клиенты безопасно создают резервные копии данных между серверами в одном или нескольких центрах обработки.

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

Дополнительные файловые хранилища

  • Использование файлового хранилища на основе NFS емкостью до 12 ТБ с одного LUN с возможностями моментальных снимков и репликации с требуемыми параметрами производительности, и высокой степенью надежности расширяет возможности для организации файловых хранилищ под бизнес-системы и среды виртуализации.

Дополнительные блочные хранилища

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

Преимущества облачного хранения данных

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

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

  • Доступность. Подготовка компонент и серверов в дата-центрах в кратчайшие сроки и с доступностью 24/7.

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

Хранилище данных управления

— SQL Server

  • 4 минуты на чтение

В этой статье

Применимо к: SQL Server (все поддерживаемые версии)

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

Инфраструктура сборщика данных определяет задания и планы обслуживания, необходимые для реализации политик хранения, определенных администратором базы данных.

Важно

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

Развертывание и использование хранилища данных

Вы можете установить хранилище данных управления на том же экземпляре SQL Server, на котором запущен сборщик данных. Однако, если ресурсы или производительность сервера являются проблемой на отслеживаемом сервере, вы можете установить хранилище данных управления на другом компьютере.

Необходимые схемы и их объекты для предопределенных системных наборов сбора создаются при создании хранилища данных управления. Создаваемые схемы — это основные и моментальные снимки.Третья схема, custom_snapshots, создается при создании пользовательских наборов сбора, включающих элементы сбора, использующие тип сборщика Generic T-SQL Query.

Схема ядра

Основная схема описывает таблицы, хранимые процедуры и представления, которые используются для организации и идентификации собранных данных. Эти таблицы являются общими для всех таблиц данных, созданных для отдельных типов коллекторов. Эта схема заблокирована и может быть изменена только владельцем базы данных хранилища данных управления.Имена таблиц в этой схеме имеют префикс «core».

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

Название таблицы Описание
core.performance_counter_report_group_items Хранит информацию о том, как отчеты хранилища управляющих данных должны группировать и агрегировать счетчики производительности.
core.snapshots_internal Обозначает каждый новый снимок. Новая строка вставляется в эту таблицу всякий раз, когда пакет выгрузки начинает выгрузку нового пакета данных.
core.snapshot_timetable_internal Хранит информацию о времени создания снимков. Время моментального снимка хранится в отдельной таблице, потому что многие моментальные снимки могут быть созданы почти в одно и то же время.
core.source.info_internal В этой таблице хранится информация об источнике данных.Эта таблица обновляется всякий раз, когда новый набор сбора начинает выгрузку данных в хранилище данных.
core.supported_collector_types_internal Содержит идентификаторы зарегистрированных типов коллекторов, которые могут выгружать данные в хранилище данных управления. Эта таблица обновляется только при обновлении схемы хранилища для поддержки нового типа коллектора. При создании хранилища данных управления эта таблица заполняется идентификаторами типов сборщиков, предоставленными сборщиком данных.
core.wait_categories Содержит категории, используемые для группировки типов ожидания в соответствии с характеристикой wait_type.
core.wait_types Содержит типы ожидания, распознаваемые сборщиком данных.
core.purge_info_internal Указывает, что был сделан запрос на прекращение удаления данных из хранилища данных управления.

Предыдущие таблицы используются с таблицами типов сборщиков для хранения информации.Например, тип сборщика Generic SQL Trace использует следующие таблицы для хранения данных трассировки:

Схема снимков

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

В следующих таблицах показана часть схемы хранилища данных управления, которая требуется для наборов сбора «Активность сервера» и «Статистика запросов».

Схема Custom_snapshots

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

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

Лучшие Лрактики

При работе с хранилищем данных управления мы рекомендуем следующие передовые практики:

  • Не изменяйте метаданные таблиц хранилища данных управления, если вы не добавляете новый тип сборщика.

  • Не изменяйте напрямую данные в хранилище данных управления. Изменение собранных вами данных лишает законности собранных данных.

  • Вместо прямого использования таблиц используйте документированные хранимые процедуры и функции, которые предоставляются со сборщиком данных, для доступа к данным экземпляра и приложения. Имена и определения таблиц могут меняться, изменяются при обновлении приложения и могут измениться в будущих выпусках.

История изменений

Обновленное содержание
В раздел «Схема ядра» добавлена ​​таблица core.performance_counter_report_group_items.
Обновлен список таблиц в разделе «Схема снимков». Добавлены snapshots.os_memory_clerks, snapshots.sql_process_and_system_memory и snapshots.io_virtual_file_stats. Удаленыsnapshots.os_process_memory и snapshots.distinct_query_stats.

См. Также

Хранимые процедуры хранилища данных управления (Transact-SQL)
Хранимые процедуры сборщика данных (Transact-SQL)
Сбор данных
Просмотр отчета о наборе сбора (SQL Server Management Studio)

Табличка хранилища данных SQL Server

То, что вам нужно знать, а не то, что вы хотите знать

Содержание

Введение

Одним из основных компонентов решения бизнес-аналитики (BI) SQL Server является хранилище данных.Действительно, хранилище данных в некотором смысле является связующим звеном, скрепляющим систему. Хранилище действует как центральное хранилище разнородных данных, которые будут использоваться для целей анализа и отчетности.

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

Примечание:
Цель этой статьи — предоставить обзор концепций хранилищ данных. Это не является рекомендацией для какого-либо конкретного дизайна. Кроме того, в статье предполагается, что у вас есть базовое понимание концепций реляционных баз данных, таких как нормализация и ссылочная целостность.Кроме того, используемые здесь примеры, как правило, специфичны для SQL Server 2005 и 2008, хотя основные принципы могут применяться к любой СУБД.

Хранилище данных

Хранилище данных объединяет, стандартизирует и упорядочивает данные для поддержки бизнес-решений, принимаемых посредством анализа и отчетности. Данные могут поступать из СУБД, таких как SQL Server или Oracle, электронных таблиц Excel, файлов CSV, хранилищ служб каталогов, таких как Active Directory, или других типов хранилищ данных, как это часто бывает в крупных корпоративных сетях.На рисунке 1 показано, как разнородные данные консолидируются в хранилище данных.

Рисунок 1. Использование хранилища данных для консолидации разнородных данных

Хранилище данных должно иметь возможность хранить данные из различных источников таким образом, чтобы такие инструменты, как службы аналитики SQL Server (SSAS) и службы отчетов SQL Server (SSRS), могли эффективно обращаться к данным. Эти инструменты, по сути, безразличны к исходным источникам данных и озабочены только надежностью и жизнеспособностью данных в хранилище.

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

Data Warehouse vs.Витрина данных

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

Реляционная база данных и размерная база данных

Поскольку SQL Server, как Oracle и MySQL, является СУБД, любая база данных, хранящаяся в этой системе, может рассматриваться в расширении как реляционная база данных. И здесь все может запутаться.

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

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

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

Размерная база данных против многомерной базы данных

Еще одним источником путаницы иногда является различие между хранилищем данных и базой данных SSAS. Путаница возникает из-за того, что в некоторой документации база данных SSAS упоминается как многомерная. Однако, в отличие от ядра СУБД SQL Server, которое поддерживает OLTP, а также хранилище данных, службы Analysis Services поддерживают оперативную аналитическую обработку (OLAP), которая предназначена для быстрой обработки аналитических запросов.Данные в базе данных OLAP хранятся в многомерных кубах агрегированных данных, в отличие от типичной модели таблицы / столбца, используемой в реляционных и многомерных базах данных.

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

OLAP-технологии обычно создаются с учетом пространственно-смоделированных хранилищ данных, хотя такие продукты, как SSAS, могут получать доступ к данным непосредственно из реляционной базы данных. Однако обычно рекомендуется использовать хранилище для поддержки более эффективных запросов, правильной очистки данных, обеспечения целостности и согласованности данных и поддержки исторических данных.Хранилище данных также действует как контрольная точка (в отличие от промежуточной базы данных!) Для устранения неполадок операций извлечения, преобразования и загрузки данных (ETL) и для аудита данных.

Модель данных

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

Существует два основных типа размерных моделей: схема «звезда» и схема «снежинка». Часто модель хранилища данных следует той или иной схеме. Однако обе схемы состоят из одних и тех же таблиц двух типов: фактов и измерений. Таблицы фактов представляют собой основной бизнес-процесс, например розничные продажи или банковские операции. В таблицах измерений хранятся связанные сведения об этих процессах, например данные о клиентах или продуктах. (Каждый тип таблиц более подробно описывается далее в статье.)

Схема звезды

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

Рисунок 2: Использование звездообразной схемы для данных о продажах

Таблица фактов ( FactSales ) объединяет всю информацию, необходимую для описания каждой продажи. Доступ к некоторым из этих данных осуществляется через столбцы внешнего ключа, которые ссылаются на измерения.Остальные данные поступают из столбцов самой таблицы, например Quantity и UnitPrice . Эти столбцы, называемые показателями , , обычно представляют собой числовые значения, которые вместе с данными в указанных измерениях предоставляют полную картину каждой продажи.

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

Измерения также могут использоваться в других таблицах фактов. Например, у вас может быть факт, который ссылается на измерения DimProduct и DimDate , а также ссылается на другие измерения, относящиеся к этому факту. Главное — убедиться, что измерение настроено так, чтобы поддерживать оба факта, чтобы данные были представлены последовательно по каждому из них.

Схема снежинки

Вы можете думать о схеме «снежинка» как о расширении звездообразной схемы. Разница в том, что в схеме «снежинка» иерархии измерений расширены (нормализованы) с помощью нескольких таблиц, чтобы избежать некоторой избыточности, обнаруженной в схеме «звезда».На рисунке 3 показана схема «снежинка», в которой хранятся те же данные, что и в звездной схеме на рисунке 2.

Рисунок 3. Использование схемы «снежинка» для данных о продажах

Обратите внимание, что иерархии измерений теперь расширены до нескольких таблиц. Например, измерение DimProduct ссылается на измерение DimProductSubcategory , а измерение DimProductSubcategory ссылается на измерение DimProductCategory . Однако таблица фактов по-прежнему остается центром схемы с теми же ссылками на внешние ключи и измерениями.

Схема «Звезда» и схема «Снежинка»

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

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

Таблица фактов

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

  • Дополнение: Тип меры, в котором значимая информация может быть извлечена путем агрегирования данных. В предыдущих примерах столбец SalesAmt является аддитивным, поскольку эти цифры можно агрегировать на основе указанного диапазона дат, продукта, продавца или покупателя. Например, вы можете определить общую сумму продаж для каждого клиента за последний год.
  • Неаддитивный: Тип меры, который не предоставляет значимую информацию посредством агрегирования.В приведенных выше примерах столбец UnitPrice можно считать неаддитивным. Например, суммирование столбца на основе продаж продавца за последний год не дает значимых данных. В конечном итоге мера считается неаддитивной, если ее нельзя агрегировать по каким-либо измерениям. (Если мера является аддитивной по одним измерениям, но не по другим, ее иногда называют полуаддитивной величиной .)
  • Вычислено: Тип меры, в котором значение получается путем выполнения функции для одной или нескольких мер.Например, столбец TotalAmt рассчитывается путем добавления значений SalesAmt и TaxAmt. (Эти типы столбцов иногда называют вычисляемыми столбцами.)

Если вы вернетесь к рисункам 2 или 3, вы увидите, что в таблице фактов не определен первичный ключ. Я видел различные рекомендации по работе с первичным ключом. Одна рекомендация — не включать первичный ключ, как я сделал здесь. Другая рекомендация — создать составной первичный ключ на основе столбцов внешнего ключа.Третья рекомендация — добавить столбец IDENTITY, настроенный с типом данных INT. Наконец, еще один подход — добавить столбцы из исходного источника данных, которые могут выступать в качестве первичного ключа. Например, исходные данные могут включать столбец OrderID. (Это подход, используемый хранилищем данных AdventureWorksDW2008.)

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

Измерение

Измерение — это набор связанных данных, которые поддерживают бизнес-процессы, представленные одной или несколькими таблицами фактов. Например, таблица DimCustomer в примерах, показанных на рисунках 2 и 3, содержит только информацию о клиенте, такую ​​как имя, адрес и номер телефона, а также соответствующие ключевые столбцы.

Суррогатный ключ

Обратите внимание, что измерение DimCustomer включает столбец CustomerKey и столбец CustomerBusKey . Начнем с CustomerKey.

Столбец CustomerKey — это первичный ключ измерения. В большинстве случаев ключ будет настроен как столбец IDENTITY с типом данных INT . В хранилище данных первичным ключом обычно является суррогатный ключ .Это означает, что ключ создается специально в контексте хранилища данных, независимо от первичного ключа, используемого в исходных системах.

Вам следует использовать суррогатную мать по ряду причин. Два важных из них заключаются в том, что ключ обеспечивает механизм, необходимый для обновления определенных типов атрибутов измерения с течением времени, и устраняет зависимости от ключей, происходящих из разных источников данных. Например, если вы извлекаете данные о клиентах из двух баз данных SQL Server, один клиент может быть связан с несколькими идентификаторами или один и тот же идентификатор может быть назначен нескольким клиентам.

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

Размер даты

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

Примечание:
Измерение DimDate в примерах использует только числовые эквиваленты для представления значений дня, таких как день недели и месяц. Однако вы можете создать измерение данных, которое также будет включать в себя написанное имя, например среда и август.

Таблица фактов может ссылаться на измерение даты несколько раз.Например, столбцы OrderDateKey и ShipDayKey ссылаются на столбец DateKey в DimDate . Если вы также хотите отслеживать время дня, ваш склад должен включать измерение времени, в котором хранятся определенные приращения времени, такие как часы и минуты. Опять же, на измерение времени может ссылаться несколько фактов или на него можно ссылаться несколько раз в одном и том же факте.

В отличие от других типов измерений, первичный ключ которых является целым числом, измерение даты использует первичный ключ, представляющий дату.Например, первичный ключ для строки от 20 октября 2008 г. — 20081020. Измерение времени следует той же логике. Если измерение хранит часы, минуты и секунды, каждая строка будет представлять секунду в дне. В результате первичный ключ для такого времени, как 10:30:27 утра, будет 103027.

Медленно меняющееся измерение

Таблицы измерений часто классифицируются как медленно меняющиеся измерения (SCD), то есть сохраненные данные изменяются относительно медленно по сравнению с таблицами фактов.Например, в предыдущих примерах таблица FactSales получит гораздо больше обновлений, чем измерения DimProduct или DimSalesPerson. Такие размеры обычно меняются очень медленно.

Способ, которым вы идентифицируете SCD, влияет на то, как измерение обновляется в процессе ETL. Есть три типа медленно меняющихся размеров:

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

Встроенные механизмы в службах интеграции SQL Server (SSIS) реализуют только SCD ​​типа 1 и типа 2. Хотя вы можете создать решение ETL для работы с SCD типа 3, SCD типа 2 обычно считаются более эффективными, более простыми в работе и обеспечивают наилучшую емкость для хранения исторических данных.

При работе с SCD в SSIS можно использовать преобразование Медленно изменяющееся измерение для реализации рабочего процесса преобразования SCD. Однако SSIS определяет SCD не на уровне измерения, а на уровне атрибута (столбца). На рисунке 4 показан экран Медленно изменяющиеся столбцы размеров мастера Медленно изменяющиеся размеры .

Рисунок 4. Указание медленно изменяющихся столбцов измерений в SSIS

Для каждого столбца вы можете выбрать, является ли этот столбец изменяющимся атрибутом (тип 1) или историческим атрибутом (тип 2).Мастер также предлагает третью опцию — Фиксированный атрибут , в этом случае значение столбца никогда не может измениться.

Есть еще одно соображение при работе с SCD. Если измерение поддерживает SCD типа 2, вам нужно каким-то образом пометить каждую строку, чтобы показать, является ли она текущей строкой (самой последней обновленной строкой) и историческим диапазоном, когда каждая строка была текущей. Наиболее эффективный способ сделать это — добавить следующие три столбца к любому измерению, поддерживающему атрибуты SCD:

  • Дата начала: Дата / время, когда строка была вставлена ​​в измерение.
  • Дата окончания: Дата / время, когда строка перестала быть текущей и была вставлена ​​новая строка для замены этой строки. Если строка является самой последней строкой, значение этого столбца устанавливается равным нулю или назначается максимальная дата, выходящая за пределы текущего диапазона, например 31 декабря 9999 года.
  • Текущий флаг: Логический или другой индикатор, который отмечает, какая строка в заданном наборе связанных строк является текущей строкой.

Некоторые системы реализуют только столбцы даты начала и даты окончания без флага, а затем используют дату окончания, чтобы вычислить, какая строка является текущей строкой.Фактически, преобразование «Медленно изменяющееся измерение » поддерживает использование только дат или использование только флага. Однако реализация всех трех столбцов обычно считается наиболее эффективной стратегией при работе с SCD. Один из подходов, который вы можете использовать при использовании мастера Slowing Changing Transformation , — это выбрать флаг состояния в качестве индикатора, а затем изменить поток данных, чтобы включить обновления начальной и конечной даты.

Данные

Хотя хранилище данных является важным компонентом корпоративной системы бизнес-аналитики, существуют и другие важные компоненты.На рисунке 5 представлен обзор того, как набор инструментов SQL Server может быть реализован в системе бизнес-аналитики.

Рисунок 5: SQL Server BI Suite

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

После загрузки данных в хранилище их можно обработать в кубах SSAS. Обратите внимание, что SSIS, помимо загрузки хранилища данных, также может использоваться для обработки кубов в рамках операции ETL.

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

Еще один компонент пакета SQL Server BI — SSRS. Вы можете использовать SSRS для создания отчетов на основе данных в хранилище данных или в базе данных SSAS. (Вы также можете использовать SSRS для прямого доступа к источникам данных, но этот подход обычно не рекомендуется для корпоративных операций, поскольку вы хотите убедиться, что данные очищены и согласованы, прежде чем включать их в отчеты.Создание отчетов SSRS на основе данных хранилища или данных SSAS зависит от потребностей вашего бизнеса. Вы можете отказаться от реализации SSAS или SSRS, но только тогда, когда все эти компоненты используются в оркестровке, вы осознаете всю мощь пакета SQL Server BI.

Заключение

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

Опции для масштабирования вашего хранилища данных SQL Server

Хранилище данных имеет решающее значение для принятия бизнес-решений на протяжении более двух десятилетий.Как эксперт по бизнес-аналитике и системный интегратор Microsoft, BlueGranite часто встречает клиентов, которые хотят максимизировать производительность своего существующего хранилища данных SQL Server или которым нужна помощь в планировании перехода на новую версию SQL Server.

Одной из распространенных проблем, которые BlueGranite видит при работе с клиентами из самых разных отраслей, является увеличение источников данных, объемов данных и увеличение времени загрузки ETL. Кроме того, конечные пользователи ожидают большей функциональности и мгновенного отклика отчета / информационной панели за доли секунды.Дни двухминутного ожидания отчета прошли. В большинстве случаев клиенты ищут возможности, функции, методы и даже оборудование, которые позволят им удовлетворить растущие требования к производительности.

Являясь девятилетним лидером в «Магическом квадранте бизнес-аналитики» Gartner, Microsoft предлагает широкий спектр решений и продуктов для удовлетворения растущих потребностей хранилищ данных. Хотя многие клиенты знают о SQL Server 2016 и его более ранних версиях, Microsoft также предлагает три дополнительных продукта для решений для хранилищ данных: Data Warehouse Fast Track, Azure SQL Data Warehouse и Analytics Platform System (подробности см. Ниже).Хотя SQL Server содержит множество функций бизнес-аналитики, таких как службы Integration Services, Analysis Services и Reporting Services, в одной установке продукта, здесь мы сосредоточимся на реляционной базе данных, используемой для решений хранилищ данных.

Что это такое: SQL Server 2016 — лучшая платформа бизнес-аналитики за более чем десятилетие

Microsoft SQL Server Enterprise — наиболее распространенное решение для хранилищ данных из четырех перечисленных выше. Это механизм базы данных с асимметричной многопроцессорной обработкой (SMP), который поддерживает NUMA, что означает, что он полагается на центральные процессоры, оперативную память и хранилище, совместно используемые на одном сервере.При использовании SQL Server для хранилища данных заказчик должен создать собственное аппаратное решение, а затем установить и «настроить» SQL Server поверх оборудования. Он обладает ведущими в отрасли функциями, включая Clustered Columnstore Index для чрезвычайно быстрой обработки запросов в памяти с низким объемом операций ввода-вывода.

Основные соображения: создайте собственное развертывание — множество вариантов

Заказчики могут использовать как физическое, так и виртуальное оборудование, а также напрямую подключенное или совместно используемое хранилище через сеть хранения данных.Большинство клиентов настроят SQL Server для рабочих нагрузок хранилища данных с учетом особых соображений и конфигураций для рабочих нагрузок, ориентированных на сканирование (в отличие от OLTP). Хотя SQL Server традиционно устанавливается и запускается локально, клиенты также могут запускать SQL Server в облаке, используя инфраструктуру как услугу (IaaS). SQL Server Enterprise поставляется с множеством функций бизнес-аналитики, которые можно использовать для создания связного решения. Скорость хранилища, доступного для сервера, жизненно важна для любого развертывания хранилища SQL Server, поэтому многие встроенные решения SQL Server используют преимущества современных технологий хранения на базе PCI и флэш-памяти.Любая конструкция должна учитывать не только емкость хранилища, но и производительность ввода-вывода, чтобы получать результаты с требуемой скоростью.

BI Особенности: все в одном или один для всех

SQL Server не накладывает ограничений на возможность заказчика установить и использовать несколько функций на одном сервере; это популярная практика, поскольку Microsoft вводит лицензирование только на основе серверов (по парам ядер), а не по функциям или экземплярам.

Программирование: Обычный T-SQL

Заказчики программируют свои хранилища данных с помощью надежного языка программирования T-SQL, который расширяется и становится более надежным с каждой версией SQL Server.

Варианты масштабирования: масштабируйте себя

Заказчики могут «масштабировать» свое хранилище данных SQL Server, добавляя больше мощности (ОЗУ, ЦП и более быстрое хранилище). Используя SQL Server в масштабируемой среде, заказчики могут рассчитывать на увеличение своего хранилища данных до 10 ТБ, прежде чем им понадобится анализировать другие решения.

Основные характеристики: CCI и многое другое

SQL Server имеет сжатие страниц и строк, которое позволяет сжимать данные на диске, поэтому извлечение данных в целом происходит быстрее.Начиная с SQL Server 2014, заказчики также могут создавать кластерные индексы столбчатого хранилища (CCI), которые преобразуют данные в столбцовое хранилище из хранилища строк, обеспечивая еще большее сжатие. CCI могут в 100 раз ускорить запросы к хранилищу данных. Таблицы OLTP в памяти могут использоваться для промежуточных таблиц для ускорения рабочих нагрузок ETL. Пакетный режим также помогает повысить производительность, поскольку механизм может выполнять итерацию по «пакетам» строк за раз.

Для получения информации о функциях производительности SQL Server 2016, библиотека ресурсов Microsoft является отличной отправной точкой.

Что это такое: Высокопроизводительное устройство SMP SQL Server

SQL Server Fast Track — это методология эталонной архитектуры для решений хранилищ данных, в которой производительность сбалансирована между всеми компонентами программного обеспечения, оборудования и хранилища для устранения узких мест. Microsoft и различные поставщики оборудования объединились, чтобы использовать эту архитектуру для создания предварительно настроенных, протестированных и поставленных аппаратных решений для хранилищ данных SQL Server. Это может устранить большую часть усилий и знаний, необходимых для разработки оптимального серверного решения из базовых компонентов.

Основные соображения: экономия времени — готовое развертывание аппаратного и программного обеспечения

Эталонная архитектура может быть вручную применена к простому решению хранилища данных SMP SQL Server, но клиенты получают наибольшую ценность, имея возможность выбрать готовое решение для желаемого уровня производительности и цены, поскольку это может ускорить решение. развертывания. При покупке устройства Fast Track клиенты могут ожидать, что поставщик доставит и настроит оборудование и программное обеспечение в локальном центре обработки данных клиента.

Функции BI: только SQL на устройстве

Поскольку Fast Track — это подход, основанный на использовании устройств, существуют некоторые основные ограничения. Во-первых, устройства Fast Track в настоящее время доступны только локально. Во-вторых, хотя SMP SQL Server позволяет заказчику устанавливать функции для бизнес-аналитики, это обычно не поддерживается устройством.

Программирование: совместимость с обычным T-SQL

Поскольку Fast Track — это просто SQL Server Enterprise SMP, вы можете использовать обычный T-SQL.

Параметры масштабирования: увеличение масштаба — предопределенный предел размера шкалы (от 5 ТБ до 145 ТБ)

Fast Track — это масштабируемое решение. Доступны устройства разных размеров (от 5 ТБ до 145 ТБ) от многих поставщиков. Поскольку устройство уже масштабировано, они, как правило, не могут быть увеличены дальше. Если клиент превышает порог размера Fast Track, он обычно должен купить еще один.

Основные характеристики

: быстрое хранилище, доступны все функции SQL Server

Основными преимуществами Fast Track являются невероятно высокая производительность (скорость чтения / записи до 10 ГБ / с), использование простого T-SQL и доступ ко всем улучшениям производительности SQL Server, таким как CCI.Это означает, что клиенты могут перенести свои решения для хранилищ данных на Fast Track, оставить свой код без изменений и получить огромные преимущества в производительности.

Для получения дополнительной информации о Fast Track посетите веб-сайт Microsoft.

Что это такое: устройство MPP для SQL Server

Microsoft Analytics Platform System (APS) — это хранилище данных на базе SQL Server Enterprise, созданное Microsoft и поставщиками оборудования, которое может масштабироваться до 6 ПБ данных. APS — это механизм базы данных с массовой параллельной обработкой (MPP), что означает, что это набор из нескольких SQL-серверов, работающих совместно.

Основные соображения: горизонтальное масштабирование и распределение данных

APS — это горизонтально масштабируемое решение. Принцип работы APS заключается в том, что большая проблема разбивается на более мелкие части. APS делает это за счет реализации топологии управления / вычислений, в которой один SQL-сервер функционирует как мозг решения (управления), а другие SQL-серверы действуют как мускулатура (вычисление) для выполнения параллельных операций с данными, которые были распределены среди вычислительных ресурсов. SQL-серверы.

Функции BI: только SQL на устройстве

Как и Fast Track, APS имеет некоторые ограничения и доступен только локально.APS есть только на SQL Server; дополнительные функции бизнес-аналитики не могут быть установлены на устройстве, хотя все функции бизнес-аналитики могут использовать устройство.

Программирование: DSQL немного отличается и может потребовать преобразования

APS использует распределенный SQL (DSQL). DSQL немного отличается от T-SQL, и у клиентов обычно есть некоторая конверсия кода (DDL и DML), которая необходима, прежде чем они смогут перенести свои базы данных на APS. Это преобразование может быть минимальным или обширным в зависимости от практики программирования клиента.

Опции масштабирования: масштабирование в единицах шкалы

Заказчикам следует обратить внимание на APS, когда у них есть около 10 ТБ данных, и ожидать роста объемов данных. APS можно масштабировать до 6 ПБ. APS масштабируется с линейной стоимостью и производительностью, поскольку его можно расширить, добавив к устройству дополнительные вычислительные узлы (так называемые единицы масштабирования).

Основные характеристики

: невероятно быстрый

При использовании APS клиенты могут ожидать значительного улучшения производительности при запросах и загрузке данных.Запросы отчетов клиентов часто можно ускорить в 100 раз, а данные могут загружаться со скоростью до нескольких ТБ в час. Поскольку APS — это скрытый SQL Server, для подключения к нему не требуется ничего особенного, поэтому клиенты могут рассчитывать на беспроблемный переход своих инструментов отчетности и семантического уровня.

Дополнительные сведения об APS см. На веб-сайте Microsoft.

Что это такое: MPP SQL Server в облаке

Хранилище данных SQL Azure (SQL DW) — это служба хранилища данных «платформа как услуга» (PaaS) в облаке Microsoft Azure.SQL DW — это ядро ​​базы данных MPP, основанное на топологии управления / вычислений с использованием базы данных SQL Azure и хранилища блогов Azure. SQL DW не является APS, но очень похож.

Ключевые соображения: SQL DW — это масштабируемое PaaS — инфраструктура управляется Microsoft

SQL DW — это масштабируемое решение, такое как APS, и, как и APS, данные распределяются по вычислительным узлам для повышения производительности и масштабирования. Поскольку SQL DW является предложением Azure, он работает только в Azure и недоступен локально. Предложение также является PaaS, поэтому клиентам не нужно беспокоиться о локальной или даже облачной инфраструктуре, поскольку все это управляется Microsoft.

Функции BI: только SQL на устройстве

SQL DW — это только SQL Server, такой как Fast Track и APS. Хотя вы не можете добавлять функции бизнес-аналитики в кластер, SQL DW можно использовать со всеми функциями SQL Server и Azure BI.

Программирование: DSQL немного отличается и может потребовать преобразования

Как и APS, SQL DW использует DSQL и имеет аналогичные ограничения программирования.

Варианты масштабирования: эластичное масштабирование за минуты

Заказчикам следует обращаться к SQL DW, когда у них есть ТБ данных.Используя SQL DW, они могут рассчитывать на масштабирование до PB. SQL DW можно эластично масштабировать за секунды, изменив параметр Единицы хранилища данных (DWU — единица масштабирования производительности) на портале Azure.

Основные характеристики

: разделение вычислительных ресурсов и хранилища

Заказчики могут создать кластер SQL DW за считанные минуты. Как и другие предложения Azure, это модель ценообразования с оплатой по факту использования, поэтому вы оплачиваете почасовую оплату. SQL DW можно не только эластично масштабировать, но и заказчики могут даже приостановить работу своих экземпляров, что снижает затраты на вычисления.Хранилище и вычислительные ресурсы полностью разделены, поэтому, когда клиенты приостанавливают работу кластера, их данные сохраняются.

Если вам нужна дополнительная информация о Azure SQL DW, посетите веб-сайт Microsoft.

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

Что такое хранилище данных? Типы, определение и пример

Что такое хранилище данных?

A Хранилище данных (DW) — это процесс для сбора и управления данными из различных источников, чтобы обеспечить значимую бизнес-аналитику. Хранилище данных обычно используется для подключения и анализа бизнес-данных из разнородных источников. Хранилище данных — это ядро ​​системы бизнес-аналитики, созданной для анализа данных и создания отчетов.

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

В этом руководстве по хранилищу данных (DWH) вы узнаете больше об-

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

Многие знают, что в базе данных, разработанной 3NF для системы инвентаризации, многие таблицы связаны друг с другом. Например, отчет о текущей информации инвентаризации может включать более 12 объединенных условий.Это может быстро замедлить время ответа на запрос и отчет. Хранилище данных имеет новый дизайн, который может помочь сократить время ответа и повысить производительность запросов для отчетов и аналитики.

Система хранилища данных также известна под следующим названием:

  • Система поддержки принятия решений (DSS)
  • Исполнительная информационная система
  • Информационная система управления
  • Решение Business Intelligence
  • Аналитическое приложение
  • Хранилище данных

История Datawarehouse

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

Вот некоторые ключевые события в развитии хранилища данных —

  • 1960 — Дартмут и General Mills в совместном исследовательском проекте, разработайте термины, измерения и факты.
  • 1970- A Nielsen и IRI вводят размерные витрины данных для розничных продаж.
  • 1983 — Tera Data Corporation представляет систему управления базами данных, специально разработанную для поддержки принятия решений.
  • Хранилище данных началось в конце 1980-х годов, когда сотрудник IBM Пол Мерфи и Барри Девлин разработали хранилище бизнес-данных.
  • Однако реальную концепцию дал Инмон Билл. Его считали отцом хранилища данных. Он писал на различные темы, касающиеся строительства, использования и обслуживания склада и фабрики корпоративной информации.

Как работает Datawarehouse?

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

Данные могут быть:

  1. Структурированные
  2. Полуструктурированные
  3. Неструктурированные данные

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

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

Типы хранилищ данных

Три основных типа хранилищ данных (DWH):

1. Корпоративное хранилище данных (EDW):

Корпоративное хранилище данных (EDW) — это централизованное хранилище. Он предоставляет услуги поддержки принятия решений в масштабах всего предприятия.Он предлагает единый подход к организации и представлению данных. Это также дает возможность классифицировать данные по предмету и предоставлять доступ в соответствии с этими разделами.

2. Хранилище операционных данных:

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

3. Витрина данных:

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

Общие этапы хранилища данных

Раньше организации относительно просто использовали хранилища данных. Однако со временем возникло более изощренное использование хранилищ данных.

Ниже приведены общие этапы использования хранилища данных (DWH):

Автономная оперативная база данных:

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

Автономное хранилище данных:

Данные в хранилище данных регулярно обновляются из оперативной базы данных. Данные в хранилище данных отображаются и преобразуются для достижения целей хранилища данных.

Хранилище данных в реальном времени:

На этом этапе хранилища данных обновляются всякий раз, когда в оперативной базе данных происходит какая-либо транзакция.Например, система бронирования авиабилетов или ж / д.

Интегрированное хранилище данных:

На этом этапе хранилища данных постоянно обновляются, когда операционная система выполняет транзакцию. Затем Datawarehouse генерирует транзакции, которые передаются обратно в операционную систему.

Компоненты хранилища данных

Четыре компонента хранилищ данных:

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

Менеджер склада: Менеджер склада выполняет операции, связанные с управлением данными на складе. Он выполняет такие операции, как анализ данных для обеспечения согласованности, создание индексов и представлений, генерация денормализации и агрегирования, преобразование и объединение исходных данных, а также архивирование и накопление данных.

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

Инструменты доступа конечных пользователей:

Они подразделяются на пять различных групп, например 1. Отчетность по данным 2. Инструменты запросов 3. Инструменты разработки приложений 4.Инструменты EIS, 5. Инструменты OLAP и инструменты интеллектуального анализа данных.

Кому нужно хранилище данных?

DWH (хранилище данных) требуется для всех типов пользователей, таких как:

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

Для чего используется хранилище данных?

Вот наиболее частые секторы, в которых используется хранилище данных:

Авиакомпания:

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

Банковское дело:

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

Здравоохранение:

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

Государственный сектор:

In В государственном секторе хранилище данных используется для сбора разведданных.Это помогает государственным органам вести и анализировать налоговые записи, записи политики здравоохранения для каждого человека.

Инвестиционный и страховой сектор:

В этом секторе склады в основном используются для анализа моделей данных, тенденций клиентов и отслеживания движений рынка.

Сохранить цепочку:

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

Телекоммуникации:

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

Гостиничный бизнес:

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

Шаги по внедрению хранилища данных

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

  1. Стратегия предприятия : Здесь мы определяем технические, включая текущую архитектуру и инструменты.Мы также определяем факты, измерения и атрибуты. Также передаются отображение и преобразование данных.
  2. Поэтапная доставка : Внедрение хранилища данных должно быть поэтапным в зависимости от предметных областей. Связанные бизнес-объекты, такие как бронирование и выставление счетов, должны быть сначала реализованы, а затем интегрированы друг с другом.
  3. Итеративное прототипирование : Вместо большого подхода к реализации, хранилище данных следует разрабатывать и тестировать итеративно.

Вот ключевые этапы внедрения Datawarehouse и их результаты.

Шаг Задачи Результаты
1 Необходимо определить объем проекта Определение объема
2 Необходимо определить бизнес-потребности Модель логических данных
3 Определение требований к операционному хранилищу данных Модель хранилища операционных данных
4 Приобретение или разработка инструментов извлечения Извлечение инструментов и программного обеспечения
5 Определение требований к данным хранилища данных Переход Модель данных
6 Документ недостающих данных Список дел по проектам
7 Сопоставляет хранилище операционных данных с хранилищем данных Карта интеграции данных D / W
8 Разработка хранилища данныхПроектирование базы данных Проектирование базы данных D / W
9 Извлечение данных из хранилища операционных данных Интегрированное извлечение данных D / W
10 Загрузка хранилища данных Загрузка исходных данных
11 Ведение хранилища данных Текущий доступ к данным и последующие загрузки

Передовой опыт внедрения хранилища данных

  • Составьте план проверки согласованности, точности и целостности данных.
  • Хранилище данных должно быть хорошо интегрированным, четко определенным и иметь временные метки.
  • При проектировании Datawarehouse убедитесь, что вы используете правильный инструмент, придерживаетесь жизненного цикла, заботитесь о конфликтах данных и готовы понять, что вы делаете ошибки.
  • Никогда не заменяйте операционные системы и отчеты
  • Не тратьте слишком много времени на извлечение, очистку и загрузку данных.
  • Убедитесь, что все заинтересованные стороны, включая бизнес-персонал, вовлечены в процесс внедрения хранилища данных.Определите, что хранилище данных — это совместный / командный проект. Вы не хотите создавать хранилище данных, бесполезное для конечных пользователей.
  • Подготовьте план обучения для конечных пользователей.

Зачем нам нужно хранилище данных? Преимущества и недостатки

Преимущества хранилища данных (DWH):

  • Хранилище данных позволяет бизнес-пользователям быстро получать доступ к важным данным из некоторых источников в одном месте.
  • Хранилище данных предоставляет единообразную информацию о различных межфункциональных действиях.Он также поддерживает специальные отчеты и запросы.
  • Data Warehouse помогает интегрировать множество источников данных, чтобы снизить нагрузку на производственную систему.
  • Хранилище данных помогает сократить общее время обработки анализа и отчетности.
  • Реструктуризация и интеграция упрощают пользователям использование отчетов и анализа.
  • Хранилище данных позволяет пользователям получать доступ к критически важным данным из множества источников в одном месте. Следовательно, это экономит время пользователя на получение данных из нескольких источников.
  • В хранилище данных хранится большой объем исторических данных. Это помогает пользователям анализировать различные периоды времени и тенденции, чтобы делать прогнозы на будущее.

Недостатки хранилища данных:

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

Будущее хранилищ данных

  • Изменение Регулирующие ограничения могут ограничить возможность объединения источников разрозненных данных.Эти разрозненные источники могут включать неструктурированные данные, которые трудно хранить.
  • По мере увеличения размера баз данных оценки того, что составляет очень большую базу данных, продолжают расти. Сложно создавать и запускать системы хранилищ данных, размер которых постоянно увеличивается. Доступные сегодня аппаратные и программные ресурсы не позволяют хранить большие объемы данных в сети.
  • Мультимедийные данные нельзя легко манипулировать как текстовые данные, тогда как текстовую информацию можно получить с помощью доступного сегодня реляционного программного обеспечения.Это может быть предметом исследования.

Инструменты хранилища данных

На рынке доступно множество инструментов хранилища данных. Вот некоторые из наиболее известных:

1. MarkLogic:

MarkLogic — это полезное решение для хранения данных, которое упрощает и ускоряет интеграцию данных с использованием множества корпоративных функций. Этот инструмент помогает выполнять очень сложные поисковые операции. Он может запрашивать различные типы данных, такие как документы, отношения и метаданные.

https://www.marklogic.com/product/getting-started/

2. Oracle:

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

https://www.oracle.com/index.html

3. Amazon RedShift:

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

https://aws.amazon.com/redshift/?nc2=h_m1

Вот полный список полезных инструментов Datawarehouse.

ОСНОВНОЕ ОБУЧЕНИЕ

  • Хранилище данных (DWH), также известное как корпоративное хранилище данных (EDW).
  • Хранилище данных определяется как центральное хранилище, в котором информация поступает из одного или нескольких источников данных.
  • Три основных типа хранилищ данных: Enterprise Data Warehouse (EDW), Operational Data Store и Data Mart.
  • Общее состояние хранилища данных: автономная оперативная база данных, автономное хранилище данных, хранилище данных в реальном времени и интегрированное хранилище данных.
  • Четыре основных компонента Datawarehouse: диспетчер загрузки, диспетчер хранилища, диспетчер запросов, инструменты доступа конечных пользователей.
  • Datawarehouse используется в различных отраслях, таких как авиалинии, банковское дело, здравоохранение, страхование, розничная торговля и т. Д.
  • Внедрение Datawarehosue состоит из трех частей. стратегия а именно. Стратегия предприятия, поэтапная доставка и итеративное прототипирование.
  • Хранилище данных позволяет бизнес-пользователям быстро получать доступ к важным данным из некоторых источников в одном месте.

Когда выбрать хранилище данных вместо базы данных для вашей компании

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

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

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

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

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

Что такое хранилище данных?

Хранилище данных (также известное как DWH) — это база данных, предназначенная для хранения, фильтрации, извлечения и анализа больших наборов данных (поставщики, клиенты, маркетинг, администрация, человеческие ресурсы, банки и т. Д.). Особенностью этих систем является то, что они специально разработаны для работы с большими данными, что позволяет визуализировать и перекрестно анализировать информацию одновременно, , без необходимости смешивать и консолидировать результаты из разных источников данных.

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

Хранилище данных — это очень рекомендуемый инструмент, если вы хотите убедиться, что неопытные пользователи в управлении системами и базами данных не подвергают риску информацию компании.Учитывая трехуровневую архитектуру, используемую в этих решениях, конечные пользователи DWH могут запрашивать свои хранилища данных, никоим образом не затрагивая и не влияя на работу системы.

Короче говоря, архитектура хранилища данных основана на трех уровнях:

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

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

  • Отделение обработки и анализа больших данных от транзакционных баз данных, что улучшает производительность обеих систем .
  • Консолидация больших данных из разных источников.
  • Повышение качества, согласованности и точности данных, обрабатываемых компанией, что приводит к более эффективному принятию решений командой менеджеров.
  • Поскольку вся информация хранится в одном центральном хранилище, более высокое качество данных составляет гарантированно , а время, необходимое для создания отчетов и анализа, составляет оптимизировано .
  • Содействие устранению повторяющихся записей, ошибок и противоречивой информации.
  • Повышение согласованности внутренней отчетности за счет стандартизации и централизации источников данных, обрабатываемых различными отделами.
Основные различия между базой данных и хранилищем данных
База данных Хранилище данных
Предназначен для хранения данных из очень ограниченного числа источников. Предназначен для хранения данных из неограниченного количества источников.
Эффективен для обработки транзакционных операций. Эффективен для анализа и агрегирования больших объемов данных.
Его возможности для анализа и интеграции данных ограничены. Позволяет визуализировать данные и быстро извлекать отчеты из сложных данных.
Быстрое и менее затратное внедрение. Более дорогостоящее и трудоемкое первоначальное внедрение.
Идеально, чтобы увидеть текущее состояние компании. Идеальный инструмент для изучения развития компании и составления среднесрочных и долгосрочных прогнозов.
В облаке или на локальном сервере?

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

Среди преимуществ наличия хранилища данных в облаке выделяются следующие:

  • Безопасность и защита данных на протяжении всего жизненного цикла.Поставщики облачных услуг должны вывести ежедневное обновление своих протоколов безопасности и резервного копирования на новый уровень.
  • Масштабируемость системы хранения намного проще.
  • DWH в облаке на дешевле , так как они не влекут за собой высоких первоначальных затрат на оборудование и лицензий на проприетарное программное обеспечение.
  • Установка и ввод в эксплуатацию хранилища данных в облаке обычно на быстрее .
  • Облачные сервисы легко подключают к другим сервисам в облаке, что, в свою очередь, приводит к повышению эффективности системы.

При этом установка хранилища данных на локальном корпоративном сервере также имеет свои преимущества:

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

Внедрение хранилища данных SQL Server 2019

Выпущено
23.10.2019 Размерные модели, такие как хранилища данных, могут обеспечить более доступную и согласованную форму хранения данных, чем реляционные базы данных.Вы можете консолидировать данные из нескольких источников в едином репозитории для бизнес-аналитики, анализа и отчетности. В этом курсе объясняется, как создать решение для долгосрочного хранения данных с использованием локальных экземпляров SQL Server и хранилища данных SQL Azure. Инструктор Адам Уилберт показывает, как построить хранилище данных с нуля, начиная с таблиц и представлений; установить поток управления; обеспечить качество данных; и использовать свои данные в таких службах, как SQL Server Reporting Services и Power BI. К концу курса вы сможете внедрить надежное настраиваемое решение для удовлетворения всех потребностей вашей организации в бизнес-аналитике, отчетности и анализе.Темы включают:
  • Транзакционные базы данных и хранилища данных
  • Схемы звездочек и снежинок
  • Создание хранилища данных
  • Проектирование таблиц и представлений
  • Восстановление индексов columnstore
  • Создание хранилища данных SQL Azure
  • Установление потока управления за пределами ETL
  • Обеспечение качества данных
  • Настройка Master Data Services
  • Получение данных со склада в сервисах BI

Уровень квалификации
Средний

2ч 7м

Продолжительность

12 503

Просмотры

Показать больше Показывай меньше

Продолжить оценку

Вы уже начали эту оценку ранее, но не завершили ее.Вы можете продолжить с того места, на котором остановились, или начать заново.

Резюме Начать сначала

5 вещей, которые следует учитывать администраторам баз данных хранилища данных SQL Server

Это продолжение нашей серии статей о SQL Server BI для администраторов баз данных. В этой публикации я собираюсь кратко изложить всего 5 общих областей, на которых, как я вижу, администраторы баз данных сосредоточиваются наиболее эффективно, когда вы отвечаете за хранилище данных SQL Server, а не за классическое приложение базы данных OLTP. Мы не собираемся сосредотачиваться ни на новом устройстве хранилища данных Microsoft SQL Server, ни на предложениях эталонных серверов: Fast Track и Parallel Data Warehouse.Вместо этого мы возьмем классический SQL Server 2005, 2008 или 2008 R2 в качестве ядра базы данных для вашего DW.

BTW, в произвольном порядке:

1. Изучение ландшафта

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

2. Шаблоны использования: всплески, массовые пакеты и чтение

Данные, которые загружаются в таблицы хранилища данных, скорее всего, поступят в больших объемах (ETL). Хранилища данных обычно могут выиграть от большего количества индексов. Но за все эти индексы на этапе загрузки данных ETL приходится платить высокую цену. Распространенной практикой является удаление индексов в таблицах загрузки перед массовыми операциями, а затем их повторное создание после процесса.Не забудьте искать отсутствующие отсутствующие индексы в DMV отсутствующих индексов.

3. На что обратить внимание

Вот общий список счетчиков и DMV для мониторинга, характерных для хранилищ данных SQL Server: отсутствующие индексы (sys.dm_db_missing_index_groups), следите за фрагментацией из-за больших операций ввода-вывода (sys.dm_db_index_physical_stats), проверьте ввод-вывод со средним значением чтения с диска / сек и Также в Perfmon следите за продолжительностью жизни страницы. Когда вы видите здесь низкие значения, вам следует вернуться и поискать отсутствующий индекс.Помните, что особенность специальных запросов в среде хранилища данных может оказаться сложной задачей.

4. Управление перемещением больших объемов данных с помощью разделов

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

Распространенной практикой разделения в хранилищах данных является разделение таблиц фактов по дате и выбор раздела на основе периода времени, который может быть еженедельным или ежемесячным, на основе наиболее распространенных дат, запрашиваемых пользователями. Для управления этими разделами старые данные можно перенести на старый раздел. Здесь вам пригодятся новый мастер разбиения на разделы и техника скользящего окна в SQL Server 2008.

Один из моих любимых способов познакомить администраторов баз данных с новой ролью хранилища данных — это перейти на веб-сайт Project Real, который был совместным проектом Microsoft, Barnes & Noble, Unisys и нескольких других партнеров. Они разработали отличную эталонную архитектуру для создания базового хранилища данных в SQL Server 2005, которая полностью переносится на SQL Server 2008. Здесь подробно объясняется множество более глубоких подходов к стратегиям разделения в ETL и хранилищах данных.

5.Управление операциями ETL (извлечение, преобразование и загрузка)

Один из аспектов управления хранилищем данных, который отличается почти во всех случаях хранилища данных от системы OLTP, заключается в том, что неизбежно будет существовать процесс, посредством которого данные из одного или нескольких (обычно нескольких и обычно многих разных типов источников) источники транзакционных данных, которые необходимы бизнес-пользователям для их общих бизнес-отчетов, непосредственно в хранилище данных или используются кубом SSAS для запросов.В SQL Server ETL, скорее всего, будет реализован из серии пакетов SSIS, созданных разработчиками ETL, которые вам, как администратору баз данных, необходимо будет отслеживать на предмет успешности / неудачи, влияния индекса и планирования. Вы можете войти в службу SSIS из SSMA, выбрав службы Integration Services в обозревателе объектов, а затем управлять пакетами либо из MSDB, хранящейся в базе данных, либо из файловой системы.

Ваш комментарий будет первым

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *