Category: Хранение данных

SQL/NoSQL, MongoDB/Cassandra/Appengine, MySQL/PostgreSQL/Oracle

Data Company на смену Software Company

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

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

... if you want to make a boatload of money in software, be prepared to spend decades getting big enough to catch the world’s attention. What the data also suggest, however, is that there are far better ways to make money than through software… Like data…. The Age of Software was fun. Welcome to the Age of Data.

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

Companies are becoming so data- and application-centric. They need individuals who can come to the table to model and mine in big data environments

Я уж не говорю о волне технологий вокруг, о NoSQL, Hadoop и пр.

Spring-Data

Вчера беседовал с Марком Полаком из SpringSource и узнал что они сейчас занимаются, помимо прочего, проектом Spring Data. Это будет некий ORM. Так что, во-первых, все недовольные Hibernate и пр. могут иметь ввиду. А во-вторых эта штука делается и для NoSQL решений, что для моих проектов очень интересно.

Стабильное решение будет не скоро, проект в самом начале пути, нет ни плана, ни майлстоунов, ни объявлений, но есть надежда что выкатят летом-осенью следующего года. Ну а сейчас, говорит, уже работает для Neo4J и MongoDB.

Там, кстати, Gitorius. Так что можете поучаствовать, если хочется использовать пораньше, ну или можно найти что-нибудь другое, интересное вам: http://git.springsource.org/

PwC о Semantic Web

Встретил хороший отчет PriceWaterhouseCoopers по поводу Semantic Web, где идет речь о способах хранения и обработки корпоративных данных. Заинтересовало именно то что там идет речь не только о semantic web как таковом, но о внутреннем использовании этих технологий, для хранения и обработки данные.

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

Что есть полезного:

  • RDF — чрезвычайно простой и универсальный формат, а именно структурированеи в виде графа (и RDF это не XML)
  • OWL — язык для структуризации, описания предметной области, в том числе вывода неявной информации, зависимостей, связей и пр.
  • SPARQL — язык запросов к rdf данным

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

PS а отчет советую прочитать

Колоночные базы данных

Меня, если честно, всегда смущал тот факт что Oracle пихают во все задачи, куда только можно, бытует мнение что «БД это Оракл». Я лично не думаю что это прям такая «серебряная пуля». MySQL занимает те же позиции немного на другом фронте. Да, Oracle в частности, MySQL, и реляционные БД в общем, это отличный инструмент, но для случая когда у нас реально востребована эта реляционность.

Но ведь Оракл используют независимо от того нужна ли нам реляционность, просто по привычке, и потому что «все так делают». Я за все свое время редко встречал нормализованные структуры, и даже больше, часто встречал таблицы БД с колонками вида col_1, col_2, col_N и пр. нарушениями всех форм, когда также разрезали таблицы на отдельные, в том числе отдельные инстансы БД. Встречал также когда в Oracle складывали черт знает что, когда использовали как хранилище лога операций, десятки гигабайт логов, ну и т.д. И никакого серьезного положительного эффекта от реляционных возможностей во всех этих случаях не было.

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

Под реляционностью в данном случае я подразумеваю не только то что данных хранятся в виде таблице (с заранее четко оговоренным списком атрибутов). Я имею ввиду все что вертится вокруг этого: нормальные формы, внешние ключи, связи и ограничения, acid, собственно реляционная алгебра и все прочее предназначенное для облегчения хранения и соблюдения целостности структурированных данных.

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

Поэтому хотел бы обратить внимание на другой тип баз, на колоночные БД.
Continue reading

Хранилище для обработки данных

Допустим у нас стоит задача: нужно собирать неструктурированные html данные и извлекать из них структуру, или, точнее, информацию, т.е. система Text Mining/Information Extraction.

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

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

Single Web Profile

Предыдущий пост про CDI на самом деле подготавливал почву к похожей теме из другой области.

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

Customer Data Integration

Customer Data Integration — объединение информации о клиентах, изначально разбросанной по множеству приложений/баз данных. Результат объединения, как единый профайл, будет уже Single Customer View.

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

Это для предприятий, если на другом примере, для веба, то это можно представить как информацию разбросанную по множеству соц-сетей (одноклассники, вконтакте, мойкруг, пикаса, жж и т.д.) и объединение всего это с помощью идей заложенных в Google Social Graph, Open Social API, DataPortability и пр.
Continue reading

Миграция БД

Бывает что при обновлении версии работающего приложения тратится иногда по нескольку часов на приведение структуры БД к новому виду. Ну т.е. добавление колонок, переименовывание, смена связей и пр. При этом DBA сидит и по diff двух инициализационных sql (для текущего приложения и для нового) пытается понять что менялось и как нужно прописать все эти ALTER TABLE ..., или того хуже UPDATE по хитрым условиям. Когда то, по неопытности, и мы так делали, при этом приложение клиента ждало (т.е. не работало) иногда по нескольку часов. Слава богу у них в это время была ночь и заказчик сладко спал, иначе бы много чего могли бы наслушаться.
Continue reading

Обработка данных, подход «MapReduce»

В 2004 году Google рассказал о модели обработки данных которую они использую. Основана она на том что данные обрабатывает пара простых функций Map и Reduce. Первая их которых выделяет множество пар Ключ/Значений из входящих данных (тоже являющихся парами Ключ/Значение), а вторая производит объединение/группировку этих пар, и, опять же, выдает наружу таки пары, чаще всего в меньшем количестве чем пришло на вход. Дополнительным элементом является распределенная файловая система GoogleFS, благодаря которой обрабатываемый файл, и вся промежуточная информация, становится легко доступной с любого компьютера в кластере.

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

Так же эту идею можно встретить под названием Split/Aggregate. Т.е. суть в том что входные данные (неважно какого размера) разбиваются на отдельные элементы (этап split), к примеру построчно, каждая строка как отдельное значение для обработки. Эти блоки строк раcпределяются по кластеру для обработки, где для каждой строки вызывается функция обработки (map). Результат выполнения опять объединяется (reduce/aggregate) в выходной файл. Если нужно, то данные сохраняются отсортироваными в определенном порядке, к примеру по внешнему ключу.
Continue reading