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

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

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

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

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

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

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

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

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

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

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

Основная идея колоночных БД

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

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

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

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

Позднее связывание

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

Например для запроса select col_1 from table where col_2 = 10 традиционная БД будет читать все строки, проверяя каждую на условие во второй колонке, и для совпавших вернет значение первой ячейки этих строк. При этому если у нас в таблице десяток колонок то будет прочитано куча лишних данных (в данном примере что-то около 80% мусора). Чтобы такого перерасхода вычислительных ресурсов не было нужно добавить индекс, который сразу ограничит набор нужных строк. Этот индекс и есть та самая дополнительная колонка, через которую пройдет позднее связывание в традиционной БД. В случае колоночной БД будет читаться лишь 2я колонка, и при совпадении условия к ней будет привязано значение из первой колонки. Очень похоже на то что у нас вся таблица состоит лишь из индексов по колонкам.

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

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

Разная структура данных

Связанные данные хранят в одной таблице (не забываем что при этом можно использовать огромное количество колонок), а связи между таблицами здесь не приживаются, по многим причинам. Но! здесь можно не боятся хранить сложные структуры в ячейках, в том числе вложенные списки, подтаблицы, структуры XML, JSON и пр.

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

Одним из применений этого подходя является ответвление БД имеющих всего одну колонку, помимо ключа, в которой и хранится все что нужно. Внешне все это выглядит как огромный HashTable. Такие БД еще называют key-value storage или document oriented database.

Сжатие данных

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

Большие объемы данных

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

Доступ

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

Но получается что средства доступа по универсальности и скорости разработки/использования выглядят обычно хуже возможностей предоставляемых Oracle и компании.

Сравнение с RDBMS

RDBMS:

• соблюдается целостность данных (foreign keys, транзакционность)
• четко структурированные данные
• запросы по всей структуре БД, используя стандартизованный язык
• результат запроса это небольшой (относительно БД) кусок данных
• быстрое извлечение нужной структуры (в том числе быстрая реализация запроса)

Колоночные БД:

• хранят большие объемы данных, упрощеный шардинг, репликация и пр.
• данные гораздо менее структурированы
• данные обрабатываются большим блоком (параллельно, massive parallel processing), или вообще сразу вся база
• оптимальным будет индивидуальный подход к обработке, тесная интеграция с данными
• худшая (ручная) поддержка целостности данных

Где стоит использовать

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

Здесь достаточно просто хранить большие блоки данных, документов (в документ-ориентированных БД) и/или сложных структур. Также довольно распространено хранилище данных вида «Ключ-Значение» (aka Properties Pattern, Хэш-таблица) с большими группами которых идет различная работа. Отлично подходит для задач, которые я привел в записи «Хранилище для обработки данных». Ну и также это хранилище логов и прочее в этом духе. Особенно хорошо если данные лишь дописываются, а не изменяются существующие.

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

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

Где не стоит использовать

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

Так же не подойдет если у нас много колонок, и мы оперируем в основном всей строкой, нет особого смысла менять тип БД. Хотя в большинстве случаев, как я уже упоминал, значения в нескольких колонкам, которые нам нужно обрабатывать одновременно, даже удобней объединить в общую структуру, к примеру в список имя/значений, или превратив в xml, yaml или json, по вкусу.

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

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

Реализации

HBase — представляет собой часть Apache Hadoop, можно сказать классическая реализация Гуглового Bigtable, рассчитана в первую очередь на большие объемы данных, и на хранение этих данных в большом кластере. Типы данных ничем не ограниченны. Я именно именно на hbase ориентировался когда приводил приводил основные тонкости/отличия, но не ограничивался им.

Из возможностей: сразу учтено что каждая колонка может иметь несколько ячеек (получается что помимо того что в строке несколько строк, в колонке тоже несколько ячеек, этакое минидерево, для хранения списочных и связанных данных), может хранить любые бинарные данные, может хранить одновременно несколько версии (версионность из коробки), поддерживает фильтры Блума, rest интерфейс доступа (помимо java api) и пр.

Но, как минимум в данный момент, не имеет индексов, кроме как по ключу. Если честно, как и сам Hadoop эта база еще развивается, поэтому БД в данный момент достаточно сырая.

Прочие

CouchDB

реализация на Erlang. Не совсем колоночная, это документная БД (document oriented DB), но по сути внутри одна большая колонка, и все приемы соответствующие. БД, конечно, не привязана к определенной платформе (т.е. к Эрлангу). Запросы пишутся на Javascript (!) в виде mapreduce операций, доступ через REST. Благодаря отказоустойчивости самого Erlang'а — очень интересное решение

Hipertable

реализация bigtable на С, изначально как основная альтернатива Hadoop HBase, именно так себя позиционировали. Причем хранение так же было организовано поверх Hadoop HDFS. Как там сейчас обстоит дело не знаю.

The Cassandra Project

реализация от Facebook, тоже базируется на идеях Google BigTable и поэтому похожа на HBase.

Project Voldermort

распределенный key-value storage, на java.

Kdb+

коммерческая БД и язык обработки, заточенные под time-series data. Это всевозможные логи, биллинг, биржы и пр. Язык обработки имеет очень сильную базу для обработки массивов (БД в данном случае является отдельным огромным многомерным массивом) и особенно распределенных во времени. В результате многие узкоспециализированные задачи (всяческие кубы, временные данные) выполняются в разы быстрее. Как минус — БД и все вокруг нее являются излишне закрытыми от людей извне

LucidDB

Open Source реляционная СУБД с основой на колоночной структуре. Расчитывается в первую очеред на аналитику, bi и пр.

Sybase IQ

Еще одна реляционная колоночная СУБД, для нужд аналитики. В этот раз коммерческая

Amazon SimpleDB, Google BigTable, Yahoo Everest

закрытые внутренние реализации от монстров интернета.

Ссылки

• PDF — «Column-Stores vs. Row-Stores: How Different Are They Really?»
• Debunking Yet Another Myth: Column-Stores As A Storage-Layer Only Optimization (и предыдущие в цикле статей)
• Is the Relational Database Doomed?

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

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

В итоге получаем примерно такие шаги:

1. (первая колонка) список URL
2. выкачиваем документ по этому адресу, складываем в колонку 2
3. убираем весь мусор (стили, js, реклама и пр.) из html и кладем в колонку 3
4. вырезаем текстовые контент (убираем навигацию, и пр.), результат в колонку 4
5. делаем PDF, результат в колонку 5

Рис 1. Таблица с несколькими колонками

Рис 2. Таблица с вертикальной обработкой

Мы складываем в колонку справа если у нас идет обработка 1 к 1 (см. рис 1), если же у нас идет какая либо вертикальная агрегация (см. рис 2), то новые данные стоит записывать под текущим блоком, в той же колонке, что есть более универсальный подход. В случае СУБД у нас получается для первого варианта таблица с колонками block_id, data_id, col_1...col_N, для второго варианта block_id, data_id, value. Где

• block_id это у нас идентификатор обрабатываемого блока,
• data_id идентификатор элемента данных, которым мы оперируем,
• и col_1..col_n или value это те данные которые нужно обработать.

В случае файловой системы получается только второй вариант, идентификатором тут будет путь к файлу. Следуя этим подходам в Apache Hadoop есть HDFS для варианта хранения в файлах, и HBase для хранения в виде таблицы.

Наверное сразу возникает претензия что у нас всегда данные если не дублируются, то остается слишком много временных данных, старые на каждом этапе остаются, а новые (выведенные из предыдущих) складываются рядом. Зачем это? Затем что иначе нам нужно следить за транзакциями, усложнять процесс распараллеливания обработки. Гораздо проще складывать рядом, и когда придет время (например когда мы дойдем до конечного шага), можно будет выкинуть все лишнее. Если мы можем позволить себе это, то так получается гораздо удобнее. Дополнительные бонусы тут в том что на любом этапе мы можем переиграть обработку заново (как замена rollback'а) или сделать новую «ветку» обработки, выполнив другие функции. И, как минимум, всегда можем проследить историю операций.

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

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

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

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

Идея что для web'а что для enterprise одинакова, но в случае бизнеса уже множество раз опробованная, а в web лишь только зарождается. В случае социальных сетей нет такого желания объединиться, по крайней мере со стороны сервисов, это удобно лишь конечному пользователю. Крупные социальные сети пока считают что тем самым они могут потерять своих пользователей, и судя по всему они слишком жадные до данных, скорее всего они будут сильно сопротивляться этим инновациям, пока окончательно не умрут. Те же одноклассники сейчас ценятся лишь огромной базой пользователей, а не теми услугами которые они предоставляют для них. Ну на самом деле, разместить фото и отписать «как дела?» можно и без них, но показывать это фото обычно некому, нужно в начале найти этого человека И ведь ничего суперсовременного тут нет, нужна лишь база по которой можно найти своих одноклассников, а дальше уже мелочи.

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

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

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

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

В корпоративном секторе, при объединении клиентских данных, обычно выделяют 3 этапа:

Основа на CRM

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

Поэтому появляется следующий вариант:

Виртуальная модель данных

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

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

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

В этом случае создается единый центр клиентских данных, и уже его используют сторонние БД, CRM и пр. приложения. Это собственно и является Customer Data Integration (CDI)

Вообще это на самом деле некоторая концепция, и может включать как подходы предыдущих пунктов, так и как упомянутый центр на который все переключаются, не храня у себя никакой дополнительной информации. Здесь отличие больше заключается в идеологическом вынесении центральной точки, отвечающей за данные клиента, называемой в данном случае Customer Data Hub. Этот хаб может и объединять данные, и ссылаться на них во внешних источниках, устанавливать связи между данными из разных источников, и передавать дальше внешним приложениям и пр. Технически потом все системы связывается через SOA/ESB, и все довольны.

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

Далее все выросло до следующего варианта: при выполнении задачи пишется ###.название.sql, где название"" лишь для визуальной идентификации, а вот эти ### для очередности выполнения скриптов. Для небольшого проекта это простой счетчик. т.е. файлы 001.extend_user.sql, 002.optimize_prod_view.sql и т.д. Да, и если номера совпали у двух разработчиков, то чаще всего проблемы не возникнет, если они не меняли одну область БД. Когда же проект побольше, то можно нумеровать в виде yyMMdd.title.sql или даже yyMMdd.HHmm.title.sql. Хотя в любом случае нужно разруливать на уровень выше, при планировании задач связанных с БД.

А запустить полученные скрипты может как ДБА, так и shell скрипт, который написать совсем не проблема. Для упрощения можно еще завести табличку version содержащую актуальный номер (тот самый, с которого начинаются наши файлы sql) и тогда процедура обновления версии вовсе станет автоматической.

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

PS: pgAdmin (менеджер для PostgreSQL) в данном случае очень удобен, по нажатию на любой объект, будь то таблица, колонка, индекс, вьюха или что угодно, он сбоку покажет SQL для удаления и создания этого объекта. В результате все эти alter table писать не приходится, достаточно скопировать.

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

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

Область применения

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

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

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

Пример алгоритма

Приведу один простой пример, может понятней будет.

mapNumbers («1, 4 and 3»)

Пусть он выделит все цифры в тексте, например регэкспом \d+, не суть важно. В нашем случае выдаст пары {num:1, num:4, num:3}, где num — имя ключа, а 1,4 и 3 — его значения

reduceSum (num[])

На вход придет список пар с одинаковым ключем, в нашем случае ключ num. Пусть метод выполняет суммирование всех цифр для переданного списка пар. Т.е. в нашем случае ему на вход придут те три пары num:#, и он произведет суммирование 1 + 4 + 3, выдав 8

На самом деле функции иногда в сотни раз сложнее, но суть та же.

Реализации MapReduce кластера под java

Apache Hadoop

Apache Hadoop — одна из основных реализаций системы для такой обработки. Поддерживает как MapReduce так и распределенную файловую систему (HDFS). Подпроектом еще идет как минимум реализация BigTable. map/reduce могут быть написаны не обязательно на Java, вполне подойдет все что может запускаться под этой ОС. Кстати, базовой ОС является Unix, хотя как я понимаю под Windows тоже работает, через cygwin.

Недавно Yahoo! сообщил что они успешно используют Hadoop для обработки объемов порядка 300 терабайт на кластере из 10 000 серверов. Из чего можно сделать вывод что для повседневных задач по обработки текущих данных Hadoop хватит с лихвой.

GridGain

GridGain скорее рассчитан(но не ограничивается этим) не на обработку терабайтов данных, а разбиение на кучу задач, не важно каких. Больше подходит название SplitAggregate. Т.е. мы задаем объем задач, GridGain раскидывает это по кластеру, и далее передает нам результат. И здесь уже хоть сразу все через БД делай, хоть используй поверх распределенной ФС (от того же Hadoop даже), не суть важно. Авторы к примеру предлагают так юнит тесты запускать, т.е. разбиваем по методам на кластер, и все они параллельно тестируются. Надо это попробовать, если окажется десяток лишних компов под рукой

А еще эти товарищи очень не любят писать лишний код сами, а предпочитают интегрировать готовые, зарекомендовавшие себя решения. Что я считаю очень правильно, зачем лишний раз изобретать велосипед? Так вот, я к тому что система получается очень гибкая, красиво написанная, настраиваемая в спринге и интегрируется с кучей прочих около grid решений.

Cloud Computing

В свете последнего расцвета cloud computing, сервисов типа Amazon S3 и EC2 все это становится довольно интересным. Сейчас можно не ждать несколько часов для обработки, когда можно запустить все это на кластере из сотен серверов, получить результат через несколько минут заплатив за аренду этого кластера совсем небольшую сумму.

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
 <property name="driverClassName" value="com.mysql.jdbc.Driver"/>
 <property name="url" value="jdbc:mysql://localhost/wallpapers?autoReconnect=true&autoPoolReconnect=true&useUnicode=true"/>
 <property name="username" value="user"/>
 <property name="password" value="pass"/>
 <property name="maxActive" value="500"/>
 <property name="initialSize" value="50"/>
</bean>

В строке соединения:
autoReconnect и autoPoolReconnect заставляют переконнекчиватся к базе при потере соединения. MySQL сам сбрасывается неиспользуемую коннекцию, помоему через 12 часов (поправте меня если что), и если в пуле будет коннекция которая столько времени не использовалась, то она оборвется и когда пулу она потребуется то приложение свалится. А useUnicode дружит нас русским языком, точнее с Unicode, т.е. в базе не будут лежать символы вопроса вместо русских букв.

Параметры maxActive и initialSize указывают на размер пула (пояснения что где думаю излишни)

Далее, если не используется data access layer, то используем коннекцию как обычно. Ну а удобней всеже передать этот датасурс Hibernat'у или чему подобному.

Через BasicDataSource можно достучатся до самого драйвера, если надо. Например чтобы не вызывать

SELECT LAST_INSERT_ID()

после вставки в табличку с auto_increment, можно сделать так:

((com.mysql.jdbc.PreparedStatement)(((DelegatingPreparedStatement)ps).getInnermostDelegate())).getLastInsertID();

где ps это PreparedStatement через который запихивали данные.

А вообще: пользуйте PostgreSQL, а лучше Oracle