Критично для бизнеса
Одна из многих черт World-Wide Web - в том, что “Всемирная паутина” ставит нас в зависимость от данных. Только подумайте - если сотрудники будут закачивать в и без того перегруженные хранилища данных компании еще больше информации, организация окажется в опасности еще до ваших похорон.
Это и есть та проблема, над которой работают многие из нас. По оценкам фирмы Standish Group International, организации потратили в 1994 году около 500 млн. долл. на крупномасштабные (более 200 Гб) системы и услуги по хранению данных. К 2000 году, как считает Standish, мы потратим более 8 млрд. Ого!
Так какая же от этого польза? Опросив 387 менеджеров высшего звена по информационным технологиям, Standish пришла к выводу, что причины для хранения данных варьировались от восприятия его как основной потребности бизнеса (48%) до средства завоевать большую долю рынка (25%), снизить издержки (16%) и увеличить поступления (11%). Учтите следующие принципы оптимального хранения данных.
Тщательно оцените размер диска. Большинство компаний сильно недооценивают требуемые размеры хранилища данных. Необходимый объем дисков не может быть равен ожидаемому объему данных. Помимо этого возникнет масса данных, сгенерированных самой системой, которым тоже потребуется место. Самое надежное правило - умножить ожидаемый объем данных на три.
Убедитесь в простоте масштабирования. Добавление новых пользователей, объемов и источников данных, платформ может внести хаос в хранилища данных. Внимательно рассмотрите влияние мощного роста и возросших (или переменных) запросов на механизм СУБД, хранилище и процессор. Ваше хранилище данных может расти на 100 Гб (или больше!) в квартал, поэтому будьте готовы масштабировать его таким способом, который не будет доставлять неудобств конечным пользователям.
Нацеливайте разработку на эффективность. Имея дело с хранилищем данных, вы не можете сначала программировать, а затем проектировать.
Запустите тест TPC-D (по хранилищам данных) и попросите поставщиков показать вам, насколько параметры продукта соответствуют реальности. Тщательно выясните, как продукт работает с данными больших и малых объемов, как у них реализована обработка запросов: при помощи растровой индексации, Б-деревьев, хэш-таблицы или через сочетание всего этого?
Рассмотрите вопросы целостности. Единожды переехав из тесной квартирки в огромное помещение крупного хранилища данных, лучше сразу тщательно рассмотреть вопрос о целостности данных. Речь должна идти не о восстановлении данных, а о предотвращении потерь. Если ваши системные администраторы считают, что резервное копирование на магнитную ленту решит все проблемы, вам следует обеспокоиться. Копирование на ленту - детская игра. Вам требуется нечувствительность к сбоям или, на худой конец, RAID либо зеркальное дублирование дисков.
Обеспечьте поддержку смешанной загрузки. Все запросы должны обрабатываться на равных! Не позволяйте сложному запросу поставить ваше хранилище на колени. Разумеется, различия в работе будут, но не позволяйте конечному пользователю их заметить. И не позволяйте длинным запросам тормозить исполнение более коротких. Если ваш поставщик не может оптимизировать обработку запросов и баланс загрузки, вам лучше обратиться к кому-нибудь еще.
Лучший путь удостовериться в успехе хранилища данных - использовать анкеты и формы для опросов, чтобы все проблемы корпорации, коммерческих подразделений и отдела ИТ были учтены заранее. У института SAS (SAS Institute) есть очень милая анкета - вы найдете ее по адресу: http://www.sas.com. Другие серверы: http://www.prism.com, http://www.ibi.com, http://www.tandem.com, http://www.ibm.com, http://www.oracle.com, http://www/sybase.com.
Кристина Комафорд, президент фирмы Corporate Computing International, MCI Mail (371-9004), CompuServe (74603,3664) Internet (74603.3664@compuserve.com) или факс (708-374-1124).
Кристина Комафорд
