Jim Gray and Mark Compton
НУЖНЫ РАБОЧИЕ РУКИ!
Databases Vol. 3, No. 3 - April 2005

Долгожданная радикальная перестройка архитектуры баз данных
(о которой так долго говорили большевики) наконец свершилась!

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

Но читайте дальше !
Растущее число разработчиков приложений верит, что XML и XQUERY станут главной
структурой исходных данных и моделью доступа, соответственно. Как минимум,
системы базы данных должны будут реализовать эти перспективы. Также, поскольку
входные данные все чаще поступают в форме непрерывного потока, чтобы иметь
возможность запросов на сравнение с исходными данными, необходимо добавить
операторы, обрабатывающие поток. Системы издание - подписка так же добавляют
проблем, инвертируя традиционную логику отношения данных и запроса, требуя,
чтобы входящие данные были сравнены с миллионами уже циркулирующих в системе
запросов, вместо того чтобы исполнять каждый запрос по отношению к миллионам
записей. Тем временем, диск и оперативная память растут существенно быстрее, чем
соответствующие возможности сокращения времени простоя и обеспечения достаточной
ширины полосы пропускания. Соответственно, современная система базы данных все
более и более интегрируется в оперативную память и использует последовательный
доступ к дискам. Это все требуют новой, намного более динамичной стратегии
оптимизации запроса в будущем. Это стратегия должна будет адаптироваться к
изменяющимся условиям и предпочтениям. Следовать некоторой статической схеме
стало просто несостоятельным. Также заметьте, что мы должны готовиться
использовать все более и более интеллектуальные внешние устройства. Каждый диск
и датчик будут эффективно функционировать как самостоятельная базы данных. Как
и со всеми другими системами баз данных, каждое из этих устройств будет
само - управляемым само - восстанавливаемым и работать круглосуточно.

Без сомнения, вы начинаете понимать о чем мы говорим !
Здесь должно быть очевидно, что мы должны изменить нашу работу, чтобы сделать
все это возможным. Мы не имеем большого выбора. Внешние обстоятельства
обуславливают эти изменения.

Добро пожаловать в революцию !

Успех, падение, снова успех объектно-ориентированных баз данных. Мы наслаждались
длительным периодом относительного застоя, где наша задача формулировалась -
"сделаем SQL чуть лучше". Майкл Стонебракер, профессор в UC Berkeley и
разработчике Ingres, называет эту эру в разработке и исследовании базы данных
эрой "полировка круглого шара". Хорошо, друзья, те дни закончены, потому что
технологии баз данных стали интегрированной средой разработки и внедрения
приложений. Данные и процедуры обработки наконец, после долгой разлуки, снова
триумфально объединились. Среда исполнения Java или обобщенный язык Windows были
помолвлены с реляционными СУБД так, что традиционное EJB-SQL разделение было
отменено. Теперь компоненты Явы или компоненты бизнес логики Майкрософт могут
выполняться внутри базы данных вместе. Результат - активные базы данных, имеющие
огромный потенциал как хорошего, так и плохого. (Об этом - далее) Наиболее
важный вызов на который нам надо отвечать - традиционные реляционные базы
данных никогда не разрабатывались, чтобы учесть смешение данных и алгоритмов.

Начались все эти проблемы с КОБОЛа, с его отделения данных и процедур, и
отдельных комитетов, которые были сформированы, чтобы определить их. Закон
Конвей подтвердился: "Построенные системы отражают учреждения, которые
проектировали их." Так, сообщество программистов баз данных унаследовало
искусственное разделение программ и данных от КОБОЛ DBTG (Рабочая группа по
базам данных). Действительно, базы данных были отделены от процедур, их
единокровных братьев, и с тех, пор почти 40 лет, боролись за воссоединение.
Воссоединение началось всерьез в середине 1980-ых, когда хранимые процедуры были
добавлены к SQL (со всей скромной благодарностью к тем храбрым сердцам из
Britton-Lee и Sybase). За этим последовал бурный рост объектно-ориентированных
баз данных. К середине 1990-ых, многие известные производители SQL добавили
объекты к их собственным системам. Даже при том, что все эти усилия были по
своему прекрасны, и несмотря на волну в промышленности "объектно-ориентированные
базы данных - в массы", все они были обречены подтверждать фундаментальный
закон: высокую степень риска, связанную со всеми инновациями в конструкциях
языка. Это также не помогало тому большинству языков, встраивавшихся в ранние
объектно-реляционные базы данных. Языки были просто ужасны. Удачно, что теперь
имеются несколько хороших объектно-ориентированных языков, которые являются
хорошо реализованными и предлагают превосходные среды разработки. Java и C# -
два хорошими примерами. Одна из характеристик этого самого современного
поколения OO сред то, что они представляют общий язык времени выполнения,
который годится как основа почти для всех языков. Действительно важное
нововведение здесь то, что эти языки также были полностью интегрированы с
современными объектно-реляционными базами данных. Среда времени выполнения была
добавлена к движкам базы данных именно так, что можно теперь писать хранимые
процедуры (модули), в то же самое время порождать объекты баз данных, как классы
в пределах этих языков. С данными, скрытыми в классах, вы вдруг в состоянии
программировать и отладить SQL, используя надежную среду программирования,
которая выглядит успокоительно знакомой, так как это то, к чему привыкли Java
или C# программисты.

... Да !
Только один момент, чтобы осознать: SQL-программирование, приходящее с полным
набором инструментов: управлением версиями, отладчиком, обработкой исключений,
и всеми другими функциональными возможностями, которые Вы обычно ожидаете от
полноценной среды программирования. SQLJ, хорошая интеграция SQL и Java,
является уже доступной, и лучшие идеи - на подходе. Красота этого, конечно,
состоит в том, что дихотомия "внутри базы / снаружи базы", остававшаяся
неприступной 40 лет, становится прошлым. Теперь, поля - объекты (значения или
ссылки); строки - векторы объектов (полей); и таблицы - последовательности
объектов-записей. Базы данных, в свою очередь, преобразовываются в коллекцию
таблиц. Это объектное представление систем базы данных обладает огромным
потенциалом - достаточным, чтобы дать ход многим из революционных изменений,
которые мы собираемся обсуждать.

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

TPlite - снова в строю. Базы данных, окруженные бизнес логикой, которые, прежде
чем появились хранимые процедуры, всегда запускали монитор обработки транзакций.
Он был расположен прямо посередине классической трехзвенной
архитектуры представление - приложение - данные. С введением хранимых процедур,
мониторы TP были исключены из двухуровневой клиент - серверной
архитектуры. Затем маятник качнулся назад. С появлением серверов Web опять
возвращается трехзвенка, так что HTTP используется в том числе для того, чтобы
обработать конверсию протокола между HTTP и протоколами клиент-сервера баз
данных и обеспечить службы представления (HTML) прямо на серверах Web,
но также и обеспечить среду выполнения для EJB или COM бизнес - объектов.

C развитием e-commerce, большинство WEB клиентов трансформировалось так, что
сегодня, на месте браузера, вслепую отображающего то, что сервер высылает, Вы
находите клиентские прикладные программы, часто в JavaScript, которые исполняя
многое в логике презентации, используют тем не менее XML чтобы связаться с
сервером. Хотя большинство WEB клиентов e-commerce продолжают пока просто
извлекать данные из HTML cтраниц, для доставки данных к "толстым" клиентским
приложениям все больше используются XML службы. Аналогично, хотя большинство
служб сегодня продолжает использовать WEB сервера классического типа (Apache и
Microsoft IIS, например), системы базы данных начинают все больше слушать порт
80 и прямо предлагают SOAP интерфейсы. В этом бравом новом мире, Вы можете
взять класс или хранимую процедуру, которые был реализованы в пределах системы
базы данных и выложить ее в Internet как сервис (с WSDL определениями
интерфейса, службой DISCO, UDDI регистрацией, и сгенерированными автоматически
заглушками SOAP вызовов). Так, модель клиента-сервера "TPlite" возвращается,
если Вы хотите это. Разработчики все еще имеют возможности трехзвенного или n-
звенного дизайна, но теперь двузвенка - снова привлекательная опция. Для многих
приложений, простота подхода клиента-сервера - притягивающая. Однако,
соображения безопасности,заставляющие закрывать базы данных защитными экранами,
будут вероятно определять выбор трехзвенки, которая позволяет работать с базами
данных только серверам Web в демилитаризованной зоне, которые быть безопасно
спрятаны позади этих Web серверов в частных сетях.

Даже если и нет, мысли вращаются вокруг возможностей, открытых нашими внезапно
расширенными горизонтами ! С одной стороны, является ли возможным, или даже
вероятным, что службы Web закончился как способ соединения разнородных системы
базы данных ? Это ни в коем случае не очевидно, но самого вопроса уже
достаточно, чтобы породить значительное количество научно-исследовательской
деятельности. Среди фундаментальных вопросов на повестке дня: Какова правильная
объектная модель для базы данных ? Каков правильный способ, упаковки информации
"в провода" ? Как действительно работают схемы в Internet ? Соответственно, как
схемы могли бы эволюционировать ? Как лучше всего искать данные и / или базы
данных по Internet ?

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

Поскольку Internet - слабосвязанная федерация серверов и клиентов, это просто
факт действительности, что клиент будет иногда отсоединяться. Факт и то, что
клиенты должны продолжать функционировать, будучи офф-лайн. Это предлагает,
маловероятным использование приложения RPC с сильной связью, скорее, программы
для Internet должно быть сделаны, как асинхронные задачи; они должны быть
структурированы как последовательности действий, выполняемых автономными
агентами. Чтобы представить этот дизайн подойдет простой пример с электронной
почтой: пользователи ожидают читать и послать почту даже, когда они не соединены
с сетью. Все основные системы базы данных теперь включают механизмы организации
очередей, которые помогают облегчить задачу определить очереди, добавить к
очереди и убрать из очереди сообщения, подсоединять триггеры к очередям, и
осуществлять диспатч задания, отправленного в очередь на обработку. Также, с
появлением хороших сред программирования с базами данных, теперь намного проще и
более естественно использование очередей. Возможность публиковать очереди как
службы Сети - очевидное преимущество. Но мы оказываемся лицом к лицу перед
сложной проблемой, потому что со всеми этими новыми возможностями, очереди
естественно можно использовать не только в качестве ACID (атомарность,
непротиворечивость, изолированность, надежность) танзакций. Конкретнее, сейчас
тенденция состоит в том, чтобы реализовать системы публикации-подписки на базе
системы организации очереди. Идеи относительно того, как лучше всего, чтобы
обработать последовательности действий и оповещений являются все еще спорным и
на них сфокусировались экспериментаторы. Ключевой вопрос, стоящий перед
исследователям - как структурировать последовательности действий. Честно говоря,
проблема эта не поддается решению уже нескольких десятилетий. Но так как
проблема осознана ключевой, мы можем ожидать множество решений в ближайшем
будущем. Выбираясь из все этого, некоторые ясные подходы должны появиться
вскоре, и наша задача как исследователей - классификация этих моделей.

--------------------
перевод Бархатов А Э
часть 1 из 2

Уважаемый mir

я не специалист по БД, не переводчик
Посмотрите пожалуйста не название статьи - НУЖНЫ РАБОЧИЕ РУКИ
Если Вы видите грубые ошибки перевода - дайте свой вариант
оригинал, например здесь:
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=293

Автор статьи - Джим Грей - в рекомендациях не нуждается
Он эту историю, о которой мы с Вами узнаем из газет, делал...

Всего самого лучшего
андрей

Посмотрите пожалуйста, а я допереведу остальное в выходные
Можно будет выложить со сноской "редактор перевода <Ваше имя>"

Да, авторство...

Причины у меня были
Личные.

Спасибо за проявленный интерес
Всего
андрей

Уважаемый Mir

Вы исправили пока только одну неточность
(на мой взгляд Ваш вариант ничем не лучше,
но это дело не мое - Вы редактор перевода)

То что Вы, специалист в данной области,
не вполне поняли статью, доказывает,
что с 2005 года она не потеряла актуальности!

Давайте оставим общие замечания
НУЖНЫ РАБОЧИЕ РУКИ
(или К БАРЬЕРУ - если Вам нравится именно военная метафора ;)

С уважением
андрей

Уважаемый Мир

Спасибо за ссылку
Посмотрю обязательно

Я не обиделся
Обидно было бы если бы не столь представительном
форуме никто не заинтересовался открыто
провокационной (в хорошем смысле) статьей
Один заголовок чего стоит ;)

Все работы, которые делает Джим Грей отличает прямо юношеский задор
Нам, завязшим с юных лет в программировании бухгалтерских
проводок о таком и мечтать не приходится
Это не моя оценка
http://www.regdeveloper.co.uk/2006/05/30/jim_gray/

Всего самого
андрей

Посмотрел ссылку
Статья Lee Fesperman - хорошая злая и конкретная

Одна фраза показалась слишком эмоциональной
Gray bundles together a plethora of current practices and techniques,
and intimates that all should be integrated into database systems.

Джим не intimates, он делает все то, о чем говорит
(Он уже после получения премии Тьюринга наработал на вторую)
Байесовский классификатор, SVM и другие чудеса статистической математики
УЖЕ включены в MS SQL Server.

Если бы мы боролись за чистоту SQL, как мистер Ли,
мы бы не имели ни Греевского TerraServer, ни Google Earth, ни SkyServer и тд
Государственные службы и бизнес в штатах УЖЕ используют эти революционные разработки
Он не воюет с ортодоксами,
выдающими за откровение то, что они изучали в институте.
Он говорит - делай как я

Всего самого
андрей

Да, я понял о чем Вы:
Корпоративную политику в выборе платформ
определяют не инженеры

Поэтому я советую Вам при первой возможности
бежать из фирмы, где проектирование информационной системы
начинается со слов начальника - БЕРЕМ ОРАКЛ... (MSSQL или Java или DotNet)

Джим Грей имел возможность спроектировать MSSQL под свои требования
Но не в этом его заслуга
Получив требуемые ресурсы он решил серьезные задачи
в ГИСах, в eScience, параллельных вычислениях и тд

Мне кажется, он призывал расширять кругозор, а не идти проторенными
коммерческими тропами

Всего
андрей

Это точно,
в нашем вавилоне я ничего не понимаю

Но представьте что Вы будете обсуждать
на форуме об АРХИТЕКТУРЕ вопрос -
какую файловую систему использовать для Вашего проекта

Так же и СУБД...
Что Вы так переживаете за ОРАКЛ (или Джаву Дельфи ТочкуНет - что там еще) ?
Вам что интересно всю жизнь рисовать окошки и выдавать на печать формочки ?

Джим Грей начал ГИСовскую тему - то что сейчас использует Гугль
Если Вы начальник - найдите ресурсы, соберите команду, сделайте подобный проект
в медицине, энергетике, транспорте, в науке и тд

А на чем это будет работать - да хоть на FAT32

Всего
андрей

Хорошие вещи не делаются за деньги, по принуждению

Джим Грей дал мне 1500 уе, да еще нашел задачу,
чтобы мне не стыдно было бы взять их

Вы можете не верить, я бы тоже не поверил

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

Всего
андрей

Как сказал один философ
посмотрев один фильм
(это был Бодрияр а фильм - Матрица)
"самое интересное они не сказали - что же дальше"

Спасибо за душевную беседу (больному лучше ;)
андрей

Как обычно, с извинениями по качеству перевода.
Может все же вычитаю паждежные окончания...
андрей.

Jim Gray and Mark Compton
НУЖНЫ РАБОЧИЕ РУКИ!
Databases Vol. 3, No. 3 - April 2005
(Вторая часть)

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

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

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

Пришло время строить здание дальше на фундаменте дата майнинг.
Мы уже узнали, как реализовать и расширять обучающиеся алгоритмы, используя
кластерный анализ, Байесовы сети, нейронные сети, анализ временных рядов, и
т.п.. Наш следующий шаг - создать обучающуюся таблицу (назовем ее здесь "Т").
Системе может быть поставлена задача создать колонки x, y, и z из атрибутов
a, b, и c - или, альтернативно, кластеризовать атрибуты a, b, и c или,
возможно даже, обрабатывать a как времен'ную метку для b. Тогда, с добавлением
данных режима обучения в обучающуюся таблицу T, некоторый алгоритм добычи
данных формирует решающее дерево или Байесову сеть или модель временных рядов
для нашего набора данных. Данные режима обучения, в которых мы нуждаемся,
могут быть получены, используя уже хорошо усвоенную метафору СУБД
"создать - вставить" и ее инструментальные средства для извлечения -
трансформации - загрузки. Со стороны вывода данных, мы можем попросить систему в
любой точке показать нашу модель данных как XML документ, так что это может быть
представлено графически, для простоты понимания человеческом. Но реальная сила –
это то, что модель может использоваться, как для данных ("Покажи мне вероятно
заказчиков") так и для проверки ("Действительно ли Мария - вероятный
заказчик?"). Таким образом, имея произвольные ключи a, b, C, модель может
возвращать значения признаков x, y, z, оценивая вероятности каждого. Или
наоборот, "T" таблица может оценивать вероятность появления некоторого значения.

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

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

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

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

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

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

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

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

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

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

Разборки со слабо структурированными данными.
Довольно неприятно, но не все данные аккуратно описываются реляционной моделью.
Профессор Станфордского Университет Дженнифер Видом подметила, что все мы
всегда начинаем со схемы < ЭТА-ХРЕНЬ />, и затем выясняем, какие структуры и
связи добавить. Также правда, что даже лучшие разработки баз данных не могут
включать каждую мыслимую взаимосвязь и оставляют по крайней мере некоторые из
отношений - неопределенными.

Как лучше всего разобраться с < ЭТОЙ-ХРЕНЬЮ /> - вопрос, который вызывал
сильное противостояние в сообществе инженеров баз данных. На одной стороне -
радикалы, кто верят, что киберпространство должно быть обработано как один
большой XML документ, который может управляться XQUERY ++. Реакционеры,
с другой стороны, верят, что структура - наш друг - и что, распространение
слабо структурированных данных являются ничем иным, как пережитком
давнопрошедшего времени, который уже давно изжили. Оба лагеря - хорошо
представлены и часто стратифицированные к возрасту. Как легко видеть,
правда находится где-то посредине, но очень трудно сказать, чем это кино
закончится.

Одна из интереснейших проблем имеет отношение к интеграции систем базы
данных и файловых систем !
Люди, хранящие тысячи сообщений электронной почты, документов, фотографий, и
музыкального архива на их персональных компьютерах, чувствуют необходимость
найти хоть какое-то решение для этого. Увеличьте масштаб той же проблемы на
порядок, чтобы представить, что происходит на предприятиях. Число файлов –
архивов - миллиарды. Традиционные схемы иерархии файлов не соответствуют той
цунами информации, которая на нас обрушилась. Так, полностью индексированные,
слабо структурированные объектные базы данных выходят на авансцену, чтобы
предложить нам поиск, приемлемой точности и повторяемости. Что это значит для
нас ? Как это ни парадоксально, файловые системы развиваются в системы базы данных - и если ничего не случится - мы можем констатировать, что слабо
структурированные данные - просто одна из фундаментальных частей в технологии
БД. Архитектуры СУБД еще требуют много работы, до того как будет объявлено, что
проблема закрыта.

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

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

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

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

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

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

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

Здравствуйте - БД в оперативной памяти !
Часть проблем, вставших перед нами, следует из безумного темпа роста объема
дисков, и мощностей памяти, опережая емкость ширины полосы пропускания и текущие
возможности уменьшения задержек. Обычно, требуется меньше секунды чтобы читать
всю ОЗУ и 20 минут, чтобы читать весь диск. Сейчас, много - гигабайт ОЗУ
просматривается за минуту, тогда как диск может требовать часов сканирования.
Также, неприятно, но очевидно, что произвольный доступ является в 100 раз
медленнее чем последовательный доступ - и разрыв только расширяется.
Коэффициенты, типа приведенных, отличаются от тех, с которыми мы выросли. Они
требуют новых алгоритмов, которые делают возможными интеллектуальные
мультипроцессорные системы, разделяющие некоторую массивную оперативную память,
при оптимизации использования драгоценной дисковой ширины полосы пропускания.
Алгоритмы БД, тем временем, должны быть перестроены, чтобы в полной мере
использовать ОЗУ (как они были переписаны, чтобы работать с миллиардами страниц
и квинтильонами байт). Короче говоря, эра БД в ОЗУ уже пришла.

Умная пыль: БД - всюду !
Мы должны отметить, что на другом полюсе от совместно используемой ОЗУ –
интеллект, помещающийся в телефонах, камерах, динамиках, и каждом периферийном
устройстве. Каждый контроллер диска, каждая камера, и каждый мобильник теперь
имеют десятки мегабайтов памяти и очень хороший процессор. Так, стало
нормальным, чтобы иметь интеллектуальные диски и другое интеллектуальное
периферийное оборудование, которое обеспечивает или доступ к базе данных (через
SQL или некоторый другой непроцедурный язык) или доступ обслуживания Сети. От
блочно-ориентированного интерфейса, к интерфейсам файловой системы и затем к
интерфейсам обслуживания - было цель энтузиастов в течении трех десятилетий.
В прошлом, это требовало аппаратных средств специального назначения. Но теперь - это не так, потому что диски теперь снабжены с быстрыми универсальными
процессорами, спасибо закону Мура. Как следствие, машины БД наслаждаются
возрождением.

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

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

Статья на Регистере в память о Джиме Грее
http://www.theregister.co.uk/2007/04/30/jim_gray_tribute/page2.html

Я тут обсуждал с товарищем Куб Данных и другие работы Грея
Видимо, он сделал так много, что даже присутствовавшие
при том люди (мы) - не успели осознать весь объем его работы
Нам кажется, что это та же вездесущая коммерческая туфта
(особенно назойливая в ИТ секторе)
Мы не можем поверить, что есть люди, не перепродающие чужое

Хорошо хоть, что в ощущении утраты мы не одиноки...