Интеллектуальные базы данных. Учебное пособие

Однако это не означает, что CBR-системы самостоятельно могут принимать решения. Последнее всегда остается за человеком, данный метод лишь предлагает возможные варианты решения и указывает на самый "разумный" с ее точки зрения.

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

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

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

3.2. Методы кластерного анализа

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

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

Суть иерархической кластеризации состоит в последовательном объединении меньших кластеров в большие или разделении больших кластеров на меньшие.

20

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

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

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

Методы поиска ассоциативных правил (association rule) - целью является нахождение закономерностей между связанными событиями в базах данных.

Часто встречающиеся приложения с применением ассоциативных правил: розничная торговля: определение товаров, которые стоит продвигать совместно; выбор местоположения товара в магазине; анализ потребительской корзины; прогнозирование спроса; перекрестные продажи: если есть информация о том, что клиенты приобрели продукты A, Б и В, то какие из них вероятнее всего купят продукт Г; маркетинг: поиск рыночных сегментов, тенденций покупательского поведения; сегментация клиентов: выявление общих характеристик клиентов компании, выявление групп покупателей; оформление каталогов, анализ сбытовых кампаний фирмы, определение последовательностей покупок клиентов (какая покупка последует за покупкой товара А); анализ Web-логов.

21

3.3.Методы визуализации

Свозрастанием количества накапливаемых данных, даже при использовании сколь угодно мощных и разносторонних алгоритмов Data Mining, становится все сложнее "переваривать" и интерпретировать полученные результаты. А, как известно, одно из положений Data Mining - поиск практически полезных закономерностей. Закономерность может стать практически полезной, только если ее можно осмыслить и понять.

В 1987 году по инициативе ACM SIGGRAPH IEEE Computer Society Technical Committee of Computer Graphics, в связи с необходимостью использования новых методов, средств и технологий данных, были сформулированы соответствующие задачи направления визуализации.

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

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

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

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

22

Глава 4. ВНЕДРЕНИЕ ИНТЕЛЛЕКТУАЛЬНЫХ БАЗ ДАННЫХ. РЫНОК ИНСТРУМЕНТОВ

4.1.Обзор NOSQL систем

Впоследние годы появилась целая серия решений альтернативных реляционным БД. Эти технологии известны как «NoSQL базы данных».

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

горизонтальное масштабирование при больших объемах данных, например как в случае Digg (3 терабайта для зеленых значков, отображаемых, если ваш друг сделал dugg на статье) или Facebook (50 терабайт для поиска по входящим сообщениям) или eBay (2 петабайта в целом);

производительность каждого отдельного сервера;

негибкий дизайн логической структуры.

Многие компании нуждаются в нахождении новых путей для хранения и масштабирования огромных массивов данных. Рассмотрим так называемые NoSQL базы данных подробнее.

Термин NoSQL был придуман Эриком Эвансом (Eric Evan / Racker), когда Джоан Оскарсон (Johan Oskarsson) из Last.fm хотел организовать мероприятие для обсуждения распределенных баз данных с открытым исходным кодом.

Под термином NoSQL скрывается большое количество продуктов с абсолютно разными дизайнами. Однако используются три основных параметра для сравнения этих систем: масштабируемость; модель данных и запросов; система хранения данных. Проанализируем некоторые NoSQL БД.

Масштабируемость - автоматическое распределение данных между несколькими серверами (распределенные базы данных). К ним относятся СУБД Cassandra, HBase, Riak, Scalaris и Voldemort.

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

23

Нераспределенные базы данных включают в себя CouchDB, MongoDB, Neo4j, Redis и Tokyo Cabinet. Эти системы могут служить прослойкой для хранения данных для распределенных систем; MongoDB предоставляет ограниченную поддержку шардинга (sharding), так же как и Lounge для CouchDB, и Tokyo Cabinet может использоваться как система хранения файлов для Voldemort.

Модель данных и запросов. Существует огромное многообразие моделей данных и API запросов в NoSQL базах данных.

Система семейства столбцов (columnfamily) используется в Cassandra и HBase, и ее идея была привнесена в них из документов, описывающих устройство Google Bigtable. В обеих системах в БД есть строки и столбцы, как обычно, но количество строк невелико: каждая строка имеет больше или меньше столбцов, в зависимости от необходимости, и столбцы не должны быть определены заранее.

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

24

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

Neo4J обладает уникальной моделью данных, храня объекты и связи в качестве узлов и ребер графа. Для запросов, которые соответствуют этой модели (например, иерархических данных), они могут быть в тысячу раз быстрее, чем альтернативные варианты.

Scalaris использует распределенные транзакции между несколькими ключами. При этом необходимо учитывать компромисс между последовательностью и наличием свободных мест при оценке в распределенных системах.

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

Базы данных хранящие данные в памяти, являются очень быстрыми (Redis может выполнять до 100 000 операций в секунду), но не могут работать с данными, превышающими размер доступной оперативной памяти. Долговечность (сохранение данных в случае сбоя на сервере или отключения питания) также может быть проблемой (в новых версиях будет поддержка append-only log). Количество данных, которые могут ожидать записи на диск, потенциально велико. Другая система с хранением данных в оперативной памяти — Scalaris, решает проблему долговечности с помощью репликации, но она не поддерживает масштабирования на несколько датацентров, так что потеря данных вероятна и тут — в случае отключения питания.

25

Memtables и SSTables буферизируют запросы на запись в памяти (memtable), после записи в commit лог для сохранности (см.подробнее http://wiki.apache.org/cassandra/ArchitectureOverview). После накопления достаточного количества записей, Memtable сортируется и записывается на диск, уже как SSTable. Это дает производительность, близкую к производительности памяти, в то же время система лишена проблем, актуальных при хранении только в памяти.

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

В CouchDB используют B-деревья с функцией добавления (append-only B-Trees — бинарное дерево, которое не нужно перестраивать при добавлении элементов), что позволяет получить неплохую производительность при записи данных на диск.

4.2. БД MongoDB

MongoDB (от "humongous") это масштабируемый, высокопроизводительный, документо-ориентированный сервер БД с открытым исходным кодом. Одна из наиболее популярных NoSQL БД. Это нечто среднее между key-value хранилищами (которые обычно быстры и масштабируемы) и традиционными реляционными базами данных (MySQL, PostgreSQL и т.п.), которые предоставляют расширенные запросы и богатый функционал. Написан на C++. Можно использовать в веб-приложениях. Последние версии достаточно стабильны для использования в коммерческих проектах. Проект разрабатывает команда специалистов на постоянной основе, выходят исправления ошибок, появляются новые идеи по проекту, используется немалым числом крупных интернет-проектов, среди которых присутствует SourceForge. Написаны драйверы для популярных языков программирования.

Особенности использования. Рассмотрим некоторые различия в работе с MongoDB по сравнению с привычным SQL. Все примеры кода написаны на

26

JavaScript и могут быть проверены в интерактивной консоли. По аналогии с тем, как в консоли mysql можно выполнять SQL-запросы, интерактивная консоль MongoDB позволяет выполнять команды сервера БД, используя язык JavaScript. По умолчанию используется движок SpiderMonkey, при желании мы можем поменять его на V8. На официальном сайте можно найти onlineвариант консоли, который работает прямо в браузере, плюс к тому небольшое введение для начинающих. Начинать рекомендуется именно с этого.

Структура информации. Структуру данных в реляционных системах на примере MySQL мы можем представить в виде следующей иерархии: База данных -> Таблица -> Строка -> Поле + Значение. В MongoDB это выглядит так: База данных -> Коллекция -> Документ -> ключ + значение. Таблицы в реляционных БД должны быть жестко структурированы, в то время как в MongoDB можно создавать документы произвольной структуры.

Пример документа в формате JSON:

{doc_id: 153,

title: 'Some title',

body: '...A lot of text...',

tags: ["tag1", "tag2", "tag3"]}

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

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

27

прибегать к инструкции JOIN, т.к. в унифицированной системе наподобие Drupal мы не всегда можем записать всю информацию в одну таблицу. Например:

SELECT docs.title, loc.city FROM documents docs

INNER JOIN doc_location d_loc ON d_loc.doc_id = docs.doc_id INNER JOIN location loc ON loc.loc_id = d_loc.loc_id

В MongoDB это делается так, учитывая что все хранится в одном документе:

db.find({additional.location.city: "Moscow"});

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

MongoDB хорошо справляется с большим количеством документов (миллионы), скорость выборки, как и в SQL, оптимизируется индексами, лимитами на количество получаемых документов за один запрос, как и в привычных реляционных БД, индексы отрицательно влияют на скорость записи. Есть знакомая нам операция EXPLAIN, выполняющая те же функции, что и в MySQL.

Запись. В SQL есть оператор INSERT для добавления и UPDATE для обновления записей. Запись в MongoDB выполняется при помощи трех функций: insert – добавление, save – обновление, update – обновление.

Рассмотрим примеры:

//$doc - произвольный документ

//Вставить документ db.insert($doc);

//Обновить документ или добавить новый если его не существует, 2 варианта

db.save($doc);

// или

db.update({name: "Joe"}, $doc, true); // первый аргумент - условие, второй - новый документ, третий - вставка если исходный документ не найден

// Атомарная операция. Увеличить параметр counter на единицу

db.update({name: "Joe"}, {$inc : {counter : 1}});

28

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

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

Агрегация. Решим задачу: из таблицы с комментариями надо выбрать суммарное количество голосов за каждого автора. В SQL это решается довольно просто:

SELECT author, SUM(votes) FROM comments GROUP BY author;

В MongoDB реализация более сложная, но и более мощная. Называется она Map/Reduce.

Фактически, это альтернатива оператора GROUP BY и функцийагрегаторов (SUM, MAX, MIN, ...) для NoSQL (в нашем контексте). В общих чертах эта операция происходит следующим образом.

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

2.На языке JavaScript создается функция map, которая проходит по каждому документу, найденному на предыдущем шаге, и собирает необходимую информацию для агрегации.

3.Далее вновь на JS создается функция reduce, которая получает данные маппинга, сгруппированные по какому-то определенному в функции map ключу. Происходит агрегация данных.

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

Получаем результат агрегации и используем его в нашем приложении.

29