Работа с PostgreSQL. Настройка и масштабирование

Прекрасный текст от http://leopard.in.ua/

MapReduce. Основы

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


Cloudera Hadoop Training: MapReduce and HDFS from Cloudera on Vimeo.

Документ от Google, в котором впервые был описан MapReduce:




Код ниже описывает простейшую MapReduce программу, которая подсчитывает количество вхождений определенного слова в документах. На вход map подается название документа и его содержание. Map разбивает содержание документа на список слов и пересылает каждое слово на reduce вместе с 1. MapReduce фреймворк производит группировку всех получаемых данных по ключу и формирует список значений. Ключ и данный список передается на нашу reduce функцию, которая производит суммирование полученного списка и пересылает результат.

map(String input_key, String input_value):

  // input_key: название документа

  // input_value: содержание документа

  for each word w in input_value:

    Emit(w, 1);

reduce(String output_key, Iterator intermediate_values):

  // output_key: слово

  // output_values: список кол-ва вхождений слова

  int result = 0;

  for each v in intermediate_values:

    result += v;

  Emit(result);

Ниже представлена схема процесса обработки данных.

Самый интересный момент в данной программе состоит в том, почему она пересылает единичку с каждым словом, а не строит например HashMap, подсчитывает общее количество слов и уже потом отсылает свой список. MapReduce фреймворк избавляет нас от необходимости создавать какие-то структуры в оперативной памяти и делать предварительные группировки. Ведь объем данных, пересылаемых на map шаг может составлять более сотни мегабайт. На одном вычислительном узле, как правило запускается одновременно map и reduce задачи (map задач значительно больше). Поэтому использование например 64 Мб на каждую из map задач может вести к падению общей производительности. 

Но такая возможность остается при помощи применения комбинаторов. Комбинаторы как раз занимаются обработкой данных после map шага и перед reduce шагом для уменьшения количества пересылаемых данных. 

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

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

Spring Roo. Что за зверь?

Spring Roo - набор утилит и плагинов, который позволяет ускорить и упростить разработку Spring-приложений. Особенно хорошо он подходит для людей, которые впервые сталкиваются с разработкой приложений на Spring.

Установка

1. Необходимо скачать набор бинарных утилит - это ядро самого Spring Roo - http://www.springsource.com/products/spring-community-download. Необходимо добавить /bin папку данных утилит в PATH.
2. Если вы работаете под Eclipse, то поставить SpringSource Tool Suite, как плагин или в виде отдельной сборки - http://www.springsource.com/developer/sts. Я рекомендую вариант плагина.
3. Maven - http://maven.apache.org/download.html, а также плагин к Eclipse m2Eclipse.

Вы можете просмотреть видео по установке Spring Roo, если возникли какие-то затруднения http://s3.springsource.com/MRKT/roo/2010-01-Five_Minutes_Roo.mov.

Первый проект

Инструкция по созданию тестового проекта представлена на http://static.springsource.org/spring-roo/reference/html/intro.html#intro-first-steps. Думаю, что там нет ничего сложного.

Мой опыт работы

Консоль

Центральным элементом Roo является её консоль. В консоли качественно реализована функция suggest. Единственное, что иногда консоль может выдавать большее количество подсказок.

Использование аспектов AspectJ и кодогенерация

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

Например, Roo может выносить в аспекты следующие вещи:

• геттеры и сеттеры
• метод toString (с возможностью настройки того, какие поля будут в нем прописываться)
• базовые вещи для Entity классов. Это например id поле, аннотация того, что класс является сущностью. EntityManager и т.д.
• стандартные методы контроллеров
• генерация finder-методов. Roo может генерировать практически любые комбинации полей, по которым необходимо искать. 

Единственное, что тут непонятно для меня, так это почему автоматически не генерируются методы equals и hashCode.  UPDATE: Генерация данных методов вынесена в отдельный плагин http://code.google.com/p/spring-roo-equals-roo-addon/. Возможно, этот плагин войдет в новый релиз.

С аспектами возможно появление непредсказуемых багов в плане отладки. Там возможны некоторые затруднения с дебагом.

Добавление полей сущностям

Эта функция реализована на ура. Можно добавлять новые поля, как из консоли, так и из IDE. Roo все подхватывает и исправляет.

Scaffold

Roo предоставляет возможность Scaffold. Реализуется это при помощи установки аннотации @RooWebScaffold на класс модели. Scaffold - это автоматическая генерация UI по моделям. Это функция очень хороша, когда надо создать скелет UI в проекте с новыми технологиями. Можно посмотреть, как все работает и исправить на свой вкус. 

Сам скаффолд генерируется в виде *.jspx файлов и небольшой библиотечки тегов.

Хотя с исправлением скаффолда сейчас не все гладко, например, если вы в скаффолде укажете русские символы, то при следующем обновлении увидите заместо них "???". Это связано с тем, что проект ещё сыроват, особенно в плане поддержки других языков.

Естественно, что в каких-либо реальных проектах будет просто необходимо отказываться от скаффолда. 

С версии 1.1.0 возможен scaffold при помощи GWT.

Maven

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

Обновление

Начинал я работу со Spring Roo с версии 1.0.0. Во время моей работы Roo успел обновиться до версии 1.1.0. Изменения очень сильные, по сути пришлось пересоздавать проект. Подозреваю, что такая нестабильность сохранится и в ближайшее время, поэтому для серьезных проектов использовать Roo рано. 

Документация

Как и в Spring, документация здесь далеко не всегда полная и полезная.

Баги

Сталкивался с парой багов, связанных с UTF-8 кодировками. Они до сих пор не решены в 1.1.0 и будут решены в 1.1.1. Одна из них, кстати, благодаря мне.

Maven Tomcat remote debugging under Windows

If you want to debug Java application, which is running through mvn tomcat:run on Windows, you MUST set environment variable MAVEN_OPTS without double quotes! It's some stupid problem that eats many time to resolve.

So use the following commands in your Windows cmd:

>set MAVEN_OPTS=-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000

>mvn tomcat:run

In the Linux use:

>MAVEN_OPTS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000";
>export MAVEN_OPTS
>mvn tomcat:run

Способы развертывания приложения на сервере из системы контроля версий

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

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

2) Обновление приложения напрямую из репозитория. В данном случае проект чекаутиться или экспортируется прямо из репозитория в папку приложения. В случае чекаута можно обновлять приложение частично, используя команду svn update. Наиболее рационально обновлять его из стабильной ветки(branch). Но для небольших самоуверенных проектов можно и из основной ветки приложения. Преимущества в том, что быстро и просто. Недостатки в том, что старая версия приложения может не сохраняться, либо этот процесс происходит вручную. В общем, данный вариант кошернее ручного копирования, но все же не подходит для сколь-нибудь серьезного применения, в силу своей негибкости, большого простора для ошибок и неунифицированности.

3) Использование системы, предназначенной для обновления приложения. Лично у меня есть опыт использования только одной такой системы - Capistrano. В целом данная система унифицирует процесс, описанный в пункте 2, не позволяя допустить базовых ошибок, в тоже время давая большой простор для действий. Отличительной особенностью тут является версионирование сборок и возможность отката к старой версии.
Создается несколько папок: current, releases и shared. В current всегда находится текущая версия сборки, в релизах находятся папки сборок(имя папки - дата сборки), в shared можно сохранить общие данные для релизов или сборок. При обновлении, Capistrano, используя определенную стратегию создания сборки, создает новую папку в releases, выполняет саму сборку и после успешного выполнения обновляет ссылку папки current. Происходит это с использованием символьных ссылок(symlink), то есть current папка является ссылкой на один из релизов. Причем обновление происходит транзакционно и в случае ошибок, релиз не создается и соответственно ссылку на текущий релиз не меняется.
Capistrano предоставляет несколько стратегий обновления по умолчанию, среди которых знакомый нам checkout и export. В данном случае в папку релиза сбрасывается текущее содержание проекта из репозитория. Вариант с экспортом проекта кажется наиболее безопасным, ведь в данном случае сохраняется полная копия всего проекта.
Бывает, что такой вариант неприемлем или попросту не нужен. Поэтому возможно создание чекаута на сервере в папке shared, обновление этой версии и копирование в папку ревизии. Здесь, как минимум, экономия во времени, т.к. приложение не скачивается каждый раз из репозитория целиком. Причем можно не копировать всю получившуюся сборку целиком, а только нужные её части. Например, в проекте существуют тысячи картинок, которые не хотелось бы копировать в каждую версию сборки(накладно с точки зрения занимаемого пространства и времени копирования). Тогда можно создать symlink на папку картинок и она будет браться из последней ревизии. К тому же крайне удобно таким образом симлинкить конфигурационные файлы, например конфигурационный файл БД. Ведь обычно такие файлы не хранят в репозитории, а создают уже на месте, либо хранят их заготовку.
После обновления, Capistrano может выполнять различные задачи, например, миграцию схемы БД или прогонку тестов(ведь надо быть уверенным, что сборка валидна). Много простора для фантазии, если вы владеете языком Ruby. 
В общем, можно создавать любые задачи для Capistrano и выполнять их со своего локального компьютера(обновление сборки тоже делается с локального компьютера). Это конечно же очень удобно.


Учтите, что если в сборку попадают файлы системы контроля версий и на сервере не установлен запрет на чтение этих файлов(например, запрет на чтение "*.svn"), то это может привести к получению злоумышленников части исходных кодов вашей системы. А там вполне могут быть ценные пароли, либо информация, помогающая осуществлению взлома. Эта тема поднималась на Хабре http://habrahabr.ru/blogs/infosecurity/70330/ и стала сенсационной, хотя по сути является банальным недосмотром и следствием чьей-то лени.

Лекция Александра Степанова в Yandex

Интересная лекция Александра Степанова(создателя STL в C++)




Есть ещё одна лекция "Преобразования и их орбиты" на Я.Видео.

Впечатления от Ритконф 2010

Недавно проходила конференция Ритконф 2010 http://ritconf.ru/ в Москве. Конференция проходила 3 дня. Не имея возможности наблюдать это вживую, смотрел интернет-трансляцию. В интернет-трансляции показывали лишь 2 зала, а судя по программе конференции залов было 3. Теперь описания докладов, которые мне запомнились и которые я увидел.

Первый день

"NoSQL хранилища / Кирилл Коринский(Yota)" - половину доклада пропустил, из-за проблем интернет-вещания. Как раз в этой половине шла речь о том, как работают NoSQL Услышал в каком состоянии находятся open-source NoSQL решения.

"Реляционные СУБД и их нереляционные реализации / Олег Царев" - появился NoSQL, но следует ли из этого, что РСУБД уходят в тень и NoSQL - новый тренд? Конечно же нет. В противовес NoSQL РСУБД имеют разнообразные индексы, несколько стратегий join(в NoSQL это только nested loop join), встроенный мощный декларативный язык запросов SQL, декомпозицию запросов и многое-многое другое, чего не имеет NoSQL. Надо понимать область применения и ограничения NoSQL перед тем, как использовать именно его вместо РСУБД. Упор доклада не на NoSQL vs РСУБД, а про возможности современных РСУБД. Доклад хороший, но очень быстро прошел.

"Rakudo Perl 6 / Jonathan Worthington" - на самом деле докладывал не Jonathan Worthington, а его российский коллега, т.к. Джонатан по каким-то причинам не смогу приехать. Сам я с Perl сталкивался лишь косвенно, но интересно было послушать, что там творится. Общее впечатление осталось, что Perl наконец-то движется к "нормальному" языку. У них появилась первая спецификация языка, а раннее никакой спецификации не было. Появляется ООП, все становится объектом, синтаксис упрощается, появляются мультифункции. Но переходить на Perl конечно же не буду.

"Виртуализационный бум, о чем молчат вендоры / Денис Гундарев" - развеиваются маркетинговые мифы про виртуализацию. Как всегда, надо думать головой, а не слушать маркетологов. Суть доклада в том, что виртуализация сейчас сыровата, чтобы смело утверждать о "виртуализационном будущем" и тем более настоящем. У неё есть свои проблемы. Опять же: использовать, но думать головой.

"Связность в Рунете / «Филанко»" - понял примерно треть доклада, т.к. до доклада был совсем не в теме. Освещалось понятие "связности" интернета. Почему связность так важна и почему трафик в рунете иногда идет через зарубежные сервера(из-за отсутствия связности). Тут все не так просто и надо поковырять подробнее.

"Почему нужно использовать Скрам в вашем веб-проекте. Опыт «Моего Круга»/ Евгений Курышев (Яндекс)" - до доклада абсолютно ничего не слышал про Скрам. С виду Скрам - это некая IT-модификация старых-добрых каждодневных "планерок" и совещаний. Причем, это работает... не везде, но работает. Основные момента скрама:

• Скрам-доска - доска текущих заданий, которая всегда у всех на виду. Докладчик рассказал, что судя по его практике такая доска сильно помогает. Если участники команды сидели в другой комнате или были удаленными, то их эффективности снижалась. У них сейчас  электронная доска.
• Скрам-митинг - каждодневные "мини-планерки" строго на 15 минут. Начинается строго в одно время. Присутствуют все участники проекта. Каждый отвечает "что сделано", "что будет сделано" и "какие проблемы" с момента прошлого скрам-митинга
• На каждой итерации или неделе(что может совпадать) - собираемся и обсуждаем результаты. Кто что сделал, какие проблемы возникли, какие у кого планы. Это нужно, чтобы разработчики не делали одно и тоже, делились проблемами(многие разработчики интроверты и пока не спросишь о проблемах - не скажут).
• Скрам-покер, как метод оценки задач. Как это все выглядит я не понял, но разработчики вроде бы оценивают задачи совместно, путем вытягивания карт. Таким образом, уменьшается вероятность неверной оценки задачи и по каким-то причинам карточками оценивать проще. Грубо говоря Вася сделал фичу, которая позволяет решить задача в 3 раза быстрее, а Коля был не в курсе. Если задачи оцениваются таким образом, то Коля оценит задачу, как сложную, но Вася тут же подскажет ему, что новая фича позволяет сделать задачу быстрее. Либо обратная ситуация: Коля внес изменения, которые усложнят реализацию задачи. Если бы Коли не было на планировании, то Вася неверно оценил бы задачу. Это интересный момент, я сам сталкиваюсь с этим в работе. Ещё докладчик сказал, что они умножают кажущуюся оценку задачи на Пи и для них это работает :-)

В общем интересно, но опять же применять с умом. Стоит покапать поглубже. На конференции было несколько докладов на эту тему.

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

"Top-20 глупых высказываний о QA и что на них ответить / Екатерина Рощина" - про тестировщиков. Вот это было интересно послушать. Рекомендую дождаться видео и посмотреть своими глазами. Тут кратенько обо всей кухне данной профессии. Как надо делать и как не надо. Короче, must-see, пересказывать бессмысленно.

Второй день

"Grails. Поиски закончены / Сергей Нековаль (Грамант)" - доклад не развеял моего мнения, что Grails - это "мертвяк" и никогда ему не быть популярным. Также усмехнулся про поддержку Groovy в IDE. Поддержка Groovy в Eclipse ужасна, там есть древний плагин версии около 0.1, который никак не развивается и ужасно глючит. Правда в списке Eclipse шел на последнем месте. Видимо, у NetBeans с этим дела намного лучше.

"Разработка через рефакторинг / Яков Сироткин (Яндекс)" - я этот доклад впервые видел. Можно сказать, что весь доклад в одной фразе "Делайте сразу хорошо, чтобы потом не было плохо". Ну а так, весело послушать, с примерами из жизни.

"Erlyvideo — создание видеостримингового сервера на erlang / Максим Лапшин" - один из самых сильных докладов на конфе. Я сам читаю блог Макса и по его статьям кое-чего начинал юзать, поэтому интересно было, как он будет выступать на конфе. Выступил он отлично, по-моему всем понравилось. Конечно же must-see. В общем Erlang быстро изучается, на нем можно быстро писать и он превосходно масштабируется. Erlang идеально подошел для задачи видеостриминга. Макс(с коллегами?) сделал сервер видео-стриминга erlyvideo, который по возможностям обгоняет текущие open-source решения. Причем этот сервер очень быстрый. 

Но опять же Erlang - это не волшебная таблетка, есть свои недостатки, однако для некоторых задач он является сейчас идеальным кандидатом, что и продемонстрировал Макс. Понравилось ещё название их конторы "Злые марсиане".

"Разработка эффективных и масштабируемых серверных приложений на C/C++ / Владимир Малашенко(Microsoft)" - о разработке серверов под новые версии Windows, где появился уже готовый ThreadPool и прочие вещи, незаменимые при разработке серверов. Из доклада узнал, что Microsoft тратит на одно обновление Windows 1 млн зелени. А так уныло.

"Ситуационное лидерство в Agile / Сурен Самарчян (Innova Group)" - интересно, особенно если вы руководитель и ваша команда неэффективна. Сурен поделился опытом, как он привел к успеху команду, потерпевшую два провала и не имевшую шанса провалится в третий раз. Опять же про Скрам и Agile. Был приведен пример MySpace, которая увеличила эффективности своих команд в среднем в 2,4 раза, применив Скрам. В общем, must-see.

"Облачная футурология по материалам западных конференций / Дмитрий Лоханский (Oversun Scalaxy)" - выступал директор Оверсан, рассказывал про облачные вычисления. В общем было интересно послушать, но чего-то конкретного в голове не отложилось. Облака это удобно и круто, к этому все якобы движется и т.д. Ну и разыграл 2 книги во время доклада. Стоит посмотреть для улучшения понимания облачных технологий.

"Реальный опыт использования облачного хостинга для высокопосещаемых сайтов/ Евгений Потапов (Сумма АйТи)" - а вот это уже must-see про облака. У ребят есть такой интересный сайт http://makemybaby.com/, там можно залить свою фотку и фотку партнера и увидеть, какой у вас был бы ребенок. Так вот нагрузка на их сервис в определенные моменты бывает в десятки раз выше обычной. Например, когда про сайт рассказывают по ТВ. В такие моменты сайт у них обычно падал. Причем они предоставляют ещё некий API сторонним разработчикам, который не должен падать по условиям договора. Им приходилось закупать оборудование "впрок", которое фактически 90% времени простаивало и выручало лишь в моменты бума. Естественно, у ребят возникло желание перейти на облачную платформу и платить за используемые ресурсы. Но это оказалось не так-то просто. У облаков есть свои ограничения. Например, время ответа диска может различаться в десять раз, поэтому размещать в облаке БД крайне не рекомендуется(она так и остается на dedicated сервере). Ещё одна из проблем - это то, что instance в облаке может подниматься по одному часу. Соответственно, не может быть речи о мгновенном реагировании на увеличении нагрузки. Короче, оно не стабильно и нужно постоянно мониторить. В общем нужно пилить и пилить и не факт, что облако окупится. В их случае оно сэкономить не помогло, но сервис стал стабильным, перестал падать в моменты пиков.

"Ошибка. Осознание, анализ, извлечение пользы / Вадим Макишвили (Яндекс)" - к сожалению не посмотрел. Говорят, что отличный доклад был, один из самых сильных на конфе.

"Костыли — это кошерно! / Павел Кудинов(Точка Кипения)" - смотрел уже в записи вот здесь http://vimeo.com/10922497. Яркий доклад. Павел рассказывает о реалиях жизни и скорее не о настоящем, а о будущем разработке ПО. Всего сразу не учтешь и не нужно этого бояться, нужно быть гибче и не стремиться всегда превращать "какашку" в конфетку. Реальность такова, что "переписывать все" зачастую не нужно. Must-see.

Третий день

"Принципы балансировки / Алексей Бажин(Mail.ru)" - интересный доклад о том, какими путями можно организовать балансировку. Рассмотрены все самые популярные способы, их достоинства и недостатки, а также какими способами пользуется mail.ru. 

"Эволюция WEB балансировки — производительность / Григорий Гуревич(Crescendo)" - из интереса посмотрел про аппаратные решения веб-балансировки. По сути доклад был пиаром и маркетингом фирмы Crescendo, но смотреть все равно интересно. Приводились примеры из бизнеса, где время ответа сайта стоило им реальных денег.

"Мониторинг как высоконагруженный проект/ Александр Быков (Mail.ru)" - о том, как надо мониторить сайты, какой путь прошла mail.ru для этого. После доклада многие высказали мнение, что mail.ru насобирало кучу костылей, которые вроде бы работают.

"Нагрузочное тестирование 1С-Битрикс / (Онтико)"  -  один из самых интересных докладов. Оно было скорее не про Битрикс, сколько про нагрузочное тестирование вообще. Было показано, как должен умирать сайт с ростом нагрузки. Нужно всегда понимать, что мы меряем и что это значит. Мерить нужно всю систему в целом. Надо иметь профиль нагрузки(куда юзеры заходят часто). Речь зашла об инструментах и все сошлись во мнении, что лучше чем jMeter ничего нет. Также Яндекс поделился секретом, что юзает легальный(якобы:)) ботнет для нагрузочного тестирования и свои инструменты. Must see.

"О [нагрузочном] тестировании и мониторинге производительности /Александр Шигин (Рамблер)" - довольно спонтанный технарский и практический доклад. Опять же всегда понимать, что мы меряем и что среднее время ни о чем не говорит.

"Проектирование физической структуры баз данных для SQL Server 2008 / Дмитрий Артемов (Microsoft)" - половину доклада рассказывалось про кластеризованные и некластеризованные индексы, потом про новые фильтрованные индексы, появлению новых инструментов для анализа индексов и системные представления в SQL Server 2008. В общем интересно, для тех, кто активно юзает SQL Server 2008 .

"Создание картографического сервиса на коленке (PostGIS/MapServer) / Андрей Костенко (Рамблер)" - ребята напили свой сайт http://visamap.net/ используя PostgreSQL и PostGIS, т.к. Google Maps и Яндекс.Карты не давал раскрашивать страны в разные цвета. По сути весь доклад показывал функции из доки и давал к ним комменты. В общем создание картографического сервиса - задача решаемая и не стоит её пугаться.

"Гигапиксели и пета-масштабы: астрономические вызовы технологиям баз данных / Иван Золотухин Олег Бартунов" - для меня был одним из самых интересных докладов. Речь шла о том, что в связи с развитием науки(а в частности датчиков) количество получаемой информации растет экспоненциально. Если речь раньше шла о терабайтах, то теперь о петабайтах. Возникает проблема анализа данных учеными из разных стран мира, но такие объемы данных невозможно переслать по сети. Необходимо некое хранилище, способное по запросу выдавать или что ещё лучше сразу анализировать необходимый кусок данных. Данные, как правило представлены в виде двумерных массивов, а массивы в реляционной СУБД обрабатываются очень тяжело, хоть и SQL позволяет весьма элегантно выбирать их. Эта и другие проблемы на данный момент не решены и не могут быть решена в существующих моделях РСУБД, никакие "заплатки" тут не помогут. Поэтому возникла необходимость начать разработку с чистого листа и она началась. Данная задача решается в рамках проекта SciDB. В данном проекте, кстати участвует живой классик СУБД Майкл Стоунбрейкер, ну и Олег Бартунов. В ближайшее время появятся первые бета-версии. Так что пожелаем удачи Олегу и команде SciDB.

Итоги

Отличная конференция. К сожалению, не было возможности пообщаться с участниками, т.к. смотрел через инет.