Магия программирования

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

2010-11-19T20:45:00.000+05:00

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

MapReduce. Основы

2010-11-12T10:36:00.000+05:00

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. Что за зверь?

2010-11-11T12:32:00.004+05:00

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

Установка

Необходимо скачать набор бинарных утилит - это ядро самого Spring Roo - http://www.springsource.com/products/spring-community-download. Необходимо добавить /bin папку данных утилит в PATH.
Если вы работаете под Eclipse, то поставить SpringSource Tool Suite, как плагин или в виде отдельной сборки - http://www.springsource.com/developer/sts. Я рекомендую вариант плагина.
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

2010-11-09T15:25:00.004+05:00

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

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

2010-08-03T17:18:00.004+06:00

Опишу основные способы, которые можно использовать, развертывая свое приложение на сервере или, как принято говорить, на 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

2010-05-03T11:59:00.000+06:00

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

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

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

2010-04-15T12:24:00.000+06:00

Недавно проходила конференция Ритконф 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.

Итоги

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

Принцип Питера для иерархических систем

2010-04-09T12:30:00.000+06:00

Существует такой "Принцип Питера"(http://ru.wikipedia.org/wiki/Принцип_Питера). Суть его в том, что в любой иерархической системе сотрудник поднимается до уровня своей некомпетентности, т.е. до должности, с которой он не может справляться компетентно. Например, сотрудник является классным техническим специалистом, но вовсе не классным или даже средним управленцем.

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

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

В общем можно сделать вывод, что застойность иерархии в системе приводит к её деградации. Относится это в том числе и к государству. Например, в России вот уже 10 лет идет укрепление вертикали власти. К чему это приводит? Приводит это к тому, что обыкновенные люди обращаются со своими проблемами в блог президенту или пишут ему видеообращения. Связано ли это с тем, что низы ничего не решают? Нет, ведь у них есть свои полномочия. Скорее всего они просто некомпетентны, т.е не выполняют своих обязанностей. Об этом также можно судить по уровню бюрократизации различных "инстанций" и нелогичности их действий.

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

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

Свой взгляд на изменения в образовании

2010-01-30T13:29:00.003+05:00

Я уже слышал много разных мнений о том, какое должно быть образование в нашей стране. Лично я имею опыт на нескольких кафедрах, правда одного и того же факультета. Учился я на бакалавра, что сейчас является довольно редким явлением. А сейчас продолжаю учиться на магистра.

Форма обучения бакалавр-магистр лучше отражает реалии рынка, чем один специалист, т.к. люди быстрее оканчивают обучение и начинают работать. При том в результате бакалавр имеет тот же набор реальных знаний, что и специалист. Фактически, специалист полгода пишет диплом и сдает ГОСы. Получается, что учится он лишь на полгода больше бакалавра и изучает при этом предметы, имеющие узкую направленность(типа, AI). На 3-4 курсе толковые студенты, как правило, ищут(и находят) себе работу. Получается, что времени на учебу у него не остается. А пар у специалистов, как правило, много (2-4 в день). Соответственно, на 3-4 курсе человек уже физически не сможет учиться на полную. Бакалавр же как раз на 4 курсе заканчивает своё обучение и продолжает работать. Вместо этого, специалист учится ещё один напряженный год, со сдачей ГОСов и диплома и при этом ещё работает. Про тех же, кто не учится толком и не работает(и не пытается найти работу или приработок), можно сказать, что они просто оболтусы, сидящие на чужой шее. В 20 лет пора уже становится самостоятельными. При нынешнем качестве образования, разницы между бакалавром и спецом нет(в большинстве случаев). Фундаментальные предметы все проходят на 1-2 курсах. При том, за рубежом в большинстве стран нет понятия "Специалист", поэтому такие дипломы там приравниваются или к бакалавру или к магистру. Потом же бакалавр идет учиться на магистра, где совсем немного пар(около 5-6 в неделю, т.е. учишься например в пятницу и субботу). В магистратуре нет гуманитарных предметов и ничего не отвлекает от хорошего изучения сложных вопросов. Вообще предметов мало, но это хорошо, т.к. есть возможность качественно их изучить. Народ пока ещё не осознал нужно ли ему идти на магистра или нет. То есть на западе на магистра идут только если хотят приобрести какие-то серьезные познания в IT. А у бывает, идут потому что не знают, что им дальше делать. То есть примерно так это выглядит: отучился, работу на нашел, знаний толком не приобрел, надо бы ещё пойти поучиться. Но такого относительно мало и выбор в сторону магистратуры делается сознательно.

Лучше самому выбирать большинство предметов, чем доверить этот выбор другому. Скоро уже будет осуществлен переход на индивидуальные учебные планы и люди смогут сами выбирать часть предметов для освоения. Я считаю, что это очень хорошо. Студенту нужно давать выбор, давать возможность управлять своим обучением. Часто возникают вопросы и недоумения "Зачем мне поставили этот предмет?" или "Я не хочу изучать данный предмет у этого преподавателя". Ситуации бывают разные, бывает, что человеку просто сложно или некогда осилить все предметы и для более качественного обучения, он вынужден убрать лишние. Такое может быть полезно для людей, которые уже работают. Бывает, что предмет ведет человек, сам в нем не разбирающийся и ходить на него смысла никакого нет. Бывает, что предмет излишне жестко спрашивают и ты сам понимаешь, что не сможешь выучить 100 определений и 50 доказательств. Если ты соглашаешься изучать данный предмет, то ты заранее понимаешь на что идешь. Но если ты понимаешь, что не осилишь и не хочешь списывать, то просто отказываешься от него. Тем более в жестком учебном плане может не быть некоторых предметов предметов, интересных тебе или, которые ведет талантливый преподаватель.

Hibernate кэширование на практике и заключение (Ч5)

2010-01-25T08:54:00.001+05:00

<class
name="Category"
table="CATEGORY">
<cache usage="read-write"/>
<id ....
</class>

Атрибут usage=”read-write” говорит Hibernate использовать стратегию параллелизма чтения-записи для КЭШа Category. Hibernate будет теперь пробовать достать запись из КЭШа второго уровня, когда мы перейдем на Category или, когда мы загрузим Category по идентификатору.
Мы выбрали чтение-запись заместо нестрогой-чтения-записи, так как класс Category интенсивно используется одновременно, распределяется среди большого количества одновременных транзакций, и становится понятно, что уровень изоляции чтения зафиксированного является достаточно хорошим. Однако, нестрогое-чтение-запись, вероятно, будет приемлимой альтернативой, поскольку существующая небольшая вероятность несоответствия между КЭШем и БД приемлема (иерархия категорий имеет малый финансовый смысл).
Этого отображения было достаточно, чтобы сказать Hibernate кэшировать все простые значения свойств, но не ассоциации или коллекции. Коллекции требуют своего <cache> элемента. Для коллекции items, мы используем стратегию чтение-запись:

<class
name="Category"
table="CATEGORY">
<cache usage="read-write"/>
<id ....
<set name="items" lazy="true">
<cache usage="read-write"/>
<key ....
</set>
</class>

Этот кэш будет использован, когда мы вызываем, например, category.getItems().iterate().
Теперь кэш коллекции хранит только идентификаторы ассоциированных экземпляров элементов. Так, что если мы требуем закэшировать сами экземпляры элементов, то мы должны включить кэширование в классе Item. Стратегия чтения-записи здесь особенно уместна. Наши пользователи не хотят принимать решение (размещая ставки), основанные на возможно устаревших данных. Давайте пойдем ещё дальше и рассмотрим коллекцию ставок. В частности ставка и коллекции ставок является неизменяемой, но мы отметили коллекцию, используя чтение-запись, так как новые ставки могут быть сделаны в любое время (важно сразу же быть в курсе новых предложений):

<class
name="Item"
table="ITEM">
<cache usage="read-write"/>
<id ....
<set name="bids" lazy="true">
<cache usage="read-write"/>
<key ....
</set>
</class>
Для класса неизменяемой ставки, мы применим стратегию только-для-чтения:
<class
name="Bid"
table="BID">
<cache usage="read-only"/>
<id ....
</class>

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

Понимание регионов КЭШа
Hibernate хранит разные классы/коллекции в различных регионах КЭШа. Регион – это именованный кэш: указатель, на который вы можете ссылать классы и коллекции в настройке поставщика конфигурации и устанавливать политику срока вытеснения, применимую к этому региону.
    Имя региона является именем класса, в случае если это кэш класса; или имя класса с именем свойства, в случае КЭШа коллекций. Экземпляры Category кэшируются в регионе с именем org.hibernate.auction.Category и элементы коллекции кэшируются в регионе с именем org.hibernate.auction.Category.items.
    Вы можете использовать конфигурационный параметр hibernate.cache.region_prefix для указания названия корневого региона для конкретной SessionFactory. Например, если префикс был установлен в node1, категория будет закэширована в регионе с именем node1.org.hibernate.auction.Category. Эта опция полезна, если ваше приложение содержит несколько экземпляров SessionFactory.
    Теперь, когда вы знаете о регионах КЭШа, давайте настроим политику сроков вытеснения для КЭШа категорий. Сначала мы выберем поставщика КЭШа. Предположим, что мы запускаем наш аукцион на одной JVM, поэтому нам не нужна кластерно-безопасная реализация (которая бы ограничила наши возможности).

Установка локального поставщика КЭШа
Нам нужно установить свойство, которое выбирает поставщика КЭШа:

hibernate.cache.provider_class=net.sf.ehcache.hibernate.Provider

Мы выбрали EHCache, в качестве нашего кэша второго уровня.
Теперь нам необходимо определить политику вытеснения для регионов КЭШа. EHCache имеет собственный конфигурационный файл, ehcache.xml в пути классов приложения. Hibernate поставляется с примерами конфигурационных файлов для всех встроенных поставщиков КЭШа, поэтому мы рекомендуем использовать комментарии в этих файлах для подробностей и принять варианты по умолчанию для всех опций, которые мы не указываем в явном виде.
Конфигурация КЭШа в ehcache.xml для класса категорий может выглядеть следующим образом:

<cache name="org.hibernate.auction.model.Category"
maxElementsInMemory="500"
eternal="true"
timeToIdleSeconds="0"
timeToLiveSeconds="0"
overflowToDisk="false"
/>

Существует небольшое количество экземпляров категорий, и все они распределяются среди большого количества одновременных транзакций. Поэтому мы отключим вытеснение по таймауту, выбрав размер ограничения КЭШа больше, чем число категорий в нашей системе, устанавливая eternal=”true”. Нет необходимости в истечении срока действия данных КЭШа по тайм-ауту, потому что категории кэшируются используя стратегию чтения-записи, и потому что не других приложений, изменяющих данные категории. Мы также запретим кэширование на диске, поскольку мы знаем, что есть только несколько экземпляров категорий и что потребление памяти не будет проблемой.
Ставки, с другой стороны являются небольшими и неизменными, но их много; поэтому мы должны настроить EHCache для аккуратного выделения кэш-памяти. Мы используем и тайм-аут и максимальный размер КЭШа:

<cache name="org.hibernate.auction.model.Bid"
maxElementsInMemory="5000"
eternal="false"
timeToIdleSeconds="1800"
timeToLiveSeconds="100000"
overflowToDisk="false"
/>

Атрибут timeToIdle определяет время вытеснения в секундах, с момента последнего доступа к элементу в кэше. Мы должны установить разумные значения здесь, поскольку мы не хотим, чтобы неиспользуемые ставки потребляли память. Атрибут timeToLiveSeconds определяет максимальное время вытеснения в секундах, с момента, когда элемент был добавлен в кэш. Поскольку ставки остаются неизменными, мы не должны удалять их из КЭШа, если к ним обращаются регулярно. Следовательно, атрибуту timeToLiveSeconds установлено большое число.
    Результатом является то, что кэшированные ставки будут удалены из КЭШа, если они не были использованы в течение последних 30 минут или если они наименее используемый элемент, если общий размер кэш-памяти достиг своего максимального предела в 5000 элементов.
    Мы отключили дисковый кэш в этом примере, так как мы ожидаем, что сервер приложений будет развернут на том же компьютере, что и БД. Если ожидаются различные физические архитектуры, то мы могли бы включить дисковый кэш.
    Оптимальная политика вытеснения из КЭШа, как вы видите, специфична для конкретных данных и особенностей применения. Вы должны учитывать множество внешних факторов, в том числе количество доступной памяти на компьютере, сервере приложений, ожидаемой нагрузки на БД компьютера, сетевые задержки, существование внешних приложений и т.д. Некоторые из этих факторов не могут быть известны во время разработки, поэтому вам часто приходится итеративно испытывать эффективность воздействия различных параметров окружения в реальных условиях или, симулируя эти условия.
    Это особенно верно в более сложных сценариях, с репликаций кэша, развернутого на кластере серверов.

Установка реплицируемого КЭШа
EHCache – это отличный поставщик КЭШа, если ваше приложение развертывается на одной виртуальной машине. Однако, корпоративному приложению поддерживающему тысячи одновременных пользователей, может потребоваться больше вычислительной мощности, и масштабирование приложения может иметь решающее значение для успеха вашего проекта. Hibernate приложения являются естественно масштабируемыми, то есть Hibernate ведет себе также, если он развернут на одной машине или на нескольких. Единственная особенность Hibernate, которая должна быть настроена специально для кластерных операций – это кэш второго уровня. Благодаря нескольким изменениям в нашей конфигурации КЭШа, мы можем использовать кластерные системы кэширования.
    Это не обязательно плохо использовать использовать чисто локального (не кластерного) поставщика КЭШа в кластере. Некоторые данные, особенно неизменяемые данные, или данные которые могут обновлены по тайм-ауту КЭШа – не требуют кластерного подтверждения и могут быть безопасно кэшированы локально, даже в кластерной среде. Мы могли бы установить каждому узлу в кластере использование локального EHCache, и тщательно выбирать достаточно короткий timeToLiveSeconds тайм-аут.
    Однако, если вам необходимо строгое состояние КЭШа в кластерной среде, то мы должны использовать более сложного поставщика КЭШа. Мы рекомендуем JBossCache, полностью транзакционную, кластерно-безопасную систему кэширования, основанную на JGroups библиотеке. JBossCache чрезвычайно производительный, и кластерная коммуникация может быть настроена любым воображаемым способом.
    Мы сейчас пошагово настроим JBossCache для CaveatEmptor для небольшого кластера из двух узлов: узел А и узел Б. Однако, мы только дотронемся до темы очень поверхностно; кластерные конфигурации по своей природе являются сложными, и многие параметры зависят от конкретного сценария.
    Во-первых, мы должны проверить, что все наши отображающие файлы используют только стратегии кэша только-для-чтения или транзакционную. Это единственные стратегии, поддерживаемые JBossCache поставщиком. Красивым приемом, которые поможет нам избежать проблемы поиска и замены в будущем: заместо размещения <cache> элементов в наших файлах отображения, мы централизовать конфигурацию КЭШа в hibernate.cfg.xml:

<hibernate-configuration>
<session-factory>
<property .../>
<mapping .../>
<class-cache
class="org.hibernate.auction.model.Item"
usage="transactional"/>
<collection-cache
collection="org.hibernate.auction.model.Item.bids"
usage="transactional"/>
</session-factory>
</hibernate-configuration>

Мы включили транзакционное кэширование для Item и для коллекции ставок в нашем примере. Однако есть важная оговорка: на момент написания этой книги, Hibernate вступит в конфликт, если у вас также есть <cache> элементы в файлах отображения. Поэтому мы не можем использовать глобальную конфигурацию, чтобы переопределить параметры в файле конфигурации. Мы рекомендуем вам использовать централизованную конфигурацию КЭШа с самого начала, особенно если вы не уверены, как приложение может быть развернуто. Это также облегчает настройку параметров КЭШа.
Следующим шагом в настройке кластера – это настройка конфигурации поставщика JBossCache. Во-первых мы включим его в Hibernate конфигурации, например, если мы не используем свойства в hibernate.cfg.xml:

<property name="cache.provider_class">
net.sf.hibernate.cache.TreeCacheProvider
</property>

JBossCache имеет свой собственный файл конфигурации, treecache.xml, который ожидается в пути класса вашего приложения. В большинстве случаев, вам понадобится другая конфигурация для каждого узла кластера, и вы должны убедиться, что нужные файл копируется в путь класса при развертывании. Давайте взглянем на типичный конфигурационный файл. В нашем кластере из двух узлов (названным MyCluster), этот файл используется на узле А:

<?xml version="1.0" encoding="UTF-8"?>
<server>
<classpath codebase="./lib"
archives="jboss-cache.jar, jgroups.jar"/>
<mbean code="org.jboss.cache.TreeCache"
name="jboss.cache:service=TreeCache">
<depends>jboss:service=Naming</depends>
<depends>jboss:service=TransactionManager</depends>
<attribute name="ClusterName">MyCluster</attribute>
<attribute name="CacheMode">REPL_SYNC</attribute>
<attribute name="SyncReplTimeout">10000</attribute>
<attribute name="LockAcquisitionTimeout">15000</attribute>
<attribute name="FetchStateOnStartup">true</attribute>
<attribute name="EvictionPolicyClass">
org.jboss.cache.eviction.LRUPolicy
</attribute>
<attribute name="EvictionPolicyConfig">
<config>
<attribute name="wakeUpIntervalSeconds">5</attribute>

<region name="/_default_">
<attribute name="maxNodes">5000</attribute>
<attribute name="timeToIdleSeconds">1000</attribute>
</region>
<region name="/org/hibernate/auction/model/Category">
<attribute name="maxNodes">500</attribute>
<attribute name="timeToIdleSeconds">5000</attribute>
</region>
<region name="/org/hibernate/auction/model/Bid">
<attribute name="maxNodes">5000</attribute>
<attribute name="timeToIdleSeconds">1800</attribute>
</region>
</config>
</attribute>
<attribute name="ClusterConfig">
<config>
<UDP bind_addr="192.168.0.1"
ip_mcast="true"
loopback="false"/>
<PING timeout="2000"
num_initial_members="3"
up_thread="false"
down_thread="false"/>
<FD_SOCK/>
<pbcast.NAKACK gc_lag="50"
retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192"
up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400"
window_size="100"
min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false"
down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false"
up_thread="false"/>
<pbcast.GMS join_timeout="5000"
join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true"
down_thread="true"/>
</config>
</attribute>
</mbean>
</server>

Конечно, этот файл конфигурации на первый взгляд может выглядеть страшно, но он легок для понимания. Вы должны знать, что это не только файл конфигурации для JBossCache, это много всего в одном: конфигурация JMX службы JBoss развертывания, файл конфигурации для TreeCache и детализированная конфигурация JGroups, коммуникационной библиотеки.
    Давайте, проигнорируем первые несколько строк, связанные с разрвертыванием JBoss (они будут игнрорироваться при запуске JBossCache вне сервера приложений JBoss) и посмотрим на Tree-Cache конфигурационные атрибуты. Эти настройки определяют реплицируемый кэш, который использует синхронизированные связи. Это означает, что узел передачи сообщений репликации ждет, пока все узлы в группе признают сообщение. Это хороший выбор для использования в по-настоящему реплицирующемся кэше. Асинхронная неблокирующая связь может быть более уместна, если узел Б был горячей заменой (узел, который немедленно берет на себя, если узел А сломался), вместо живого партнера. Горячая замена используется, когда целью является построение отказоустойчивого кластера, а не пропускная способность. Другие атрибуты конфигурации, такие как тайм-ауты, вместимость КЭШа, когда подсоединяется новый узел, ясны исходя из их названий.
    JBossCache предоставляет подключаемые политики вытеснения. В этом случае мы выбрали встроенную политику org.jboss.cache.eviction.LRUPolicy. Мы затем настроим вытеснение КЭШа для каждого региона, так же, как мы это делали с EHCache.
    Наконец, давайте посмотрим на конфигурацию взаимодействия JGroups кластеров. Порядок протоколов связи крайне важен, поэтому не меняйте или добавляйте строки в произвольном порядке. Наиболее интересным является первый протокол <UDP>. Мы связываем сокет с IP адресом 192.168.0.1 (IP адрес узла А в сети) и разрешаем многоадресную связь. Атрибут loopback должен быть установлен в истину, если узел А будет компьютером под управлением Microsoft Windows (это не так).
    Другие атрибуты JGroups являются более сложными и могут быть найдены в документации JGroups. Они имеют дело с алгоритмами, используемыми для обнаружения новых узлов в группе, обнаружение неисправностей и, в целом, управления взаимодействием группы.
    Таким образом, после изменения стратегии параллельного кэширования ваших хранимых классов на транзакционную (или только-для-чтения) и создания treecache.xml файла для узла А, вы можете запустить ваше приложение и проверить выходной лог. Мы рекомендуем включить регистрацию в журнале отладки для org.jboss.cache класса, вы увидите, как JBossCache считывает конфигурацию, и узел А сообщает о первом узле в кластере. Для развертывания узла Б, измените IP адрес в конфигурационном файле и повторите процедуру развертывания с новым файлом. Вы должны увидеть сообщение о присоединении от обоих узлов, как только начнется использование транзакционного кэширования в кластере: каждый элемент, помещаемый в кэш, будет реплицирован, и обновляемые элементы будут признаны недействительными.
    Существует одна окончательная дополнительная настройка для рассмотрения. Для кластерных поставщиков КЭШа, возможно, было бы лучше установить опцию Hibernate конфигурации hibernate.cache.use_minimal_puts в истину(true). Когда этот параметр включен, Hibernate будет только добавлять элементы в кэш после проверки на то, что они уже не находятся в КЭШе. Эта стратегия работает лучше, если кэш пишет (получает) более интенсивно, чем читает (получает). Это вариант для реплицируемого КЭШа в кластере, но не для локального КЭШа (по умолчанию, параметр выставлен в false для оптимизации локального КЭШа). Используете ли вы кластерный или локальный кэш, вам иногда необходимо, контролировать это программно для тестирования или настройки.

Контролирование КЭШа второго уровня
Hibernate имеет несколько полезных методов, которые помогут вам испытать и настроить ваш кэш. Вы можете удивиться тому, как отключить кэш второго уровня полностью. Hibernate будет загружать поставщика КЭШа и начинать использовать кэш второго уровня, если у вас объявление КЭШа в ваших файлах отображения или конфигурационном XML файле. Если вы закомментируете их, то кэш отключен. Это является ещё одной веской причиной предпочитать централизованную конфигурацию КЭШа в hibernate.cfg.xml файле.
    Подобно тому, как сессия предоставляет методы для контроля КЭШа первого уровня программным способом, также SessionFactory предоставляет их для КЭШа второго уровня.
    Вы можете вызвать evict(), чтобы удлаить элемент из КЭШа, указав класс и идентификатор объекта:

SessionFactory.evict( Category.class, new Long(123) );

Вы также можете вытеснить все элементы некоторого класса или только особые роли:

SessionFactory.evict("org.hibernate.auction.model.Category");

Вы редко будете нуждаться в этих механизмах контроля.

5.4 Резюме
Эта глава была посвящена контролю одновременного выполнения и кэширования данных.
Вы узнали, что за одну единицу работы, либо все операции должны быть полностью успешны или целиком должны быть неуспешными (и изменения откачены назад). Это привело нас к понятию транзакции и ACID атрибутах. Транзакция атомарно оставляет данные в целостном состоянии и изолированными от одновременно выполняемых транзакций, и у вас есть гарантия, что данные, сделанные транзакцией долговечны.
    Вы используете два понятия транзакции в Hibernate приложениях: короткие транзакции БД и длинные транзакции приложения. Как правило, вы изоляцию уровня чтения подтвержденного для транзакций БД, вместе с оптимистически контролем параллелизма (проверка версий и временных меток) для длинных транзакций приложения. Hibernate значительно упрощает реализацию транзакций приложения, поскольку он управляет номером версий и временными метками.
    Наконец, мы обсудили основы кэширования, и вы узнали, как использовать кэширование эффективно в Hibernate приложениях.
    Hibernate предоставляет двухслойную систему кэширования с первым уровнем КЭШа (сессия) и подключаемым КЭШем второго уровня. Кэш первого уровня активен всегда – он используется для разрешения циклических ссылок в вашем графе объектов и для оптимизации производительности на одну единицу работы. (Процессный или кластерный) Кэш второго уровня с другой стороны является опциональным и лучше всего подходит для классов, которые в основном считываются. Вы можете настроить неизменяемый кэш второго уровня для справочных (только-для-чтения) данных, или кэш второго уровня с полной транзакционной изоляцией важных данных. Однако, вы должны внимательно изучить стоит ли прирост производительности усилий. Кэш второго уровня может быть детально настроен для каждого хранимого класса, и для каждой коллекции и ассоциации. Правильно и тщательно протестированное кэширование в Hibernate даст вам уровень производительности, который почти не достижим в написанных самостоятельно слоях доступа к данным.

Кэширование в Hibernate (Ч4)

2010-01-24T22:29:00.002+05:00

это перевод Hibernate in Action главы 5
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1)
Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)
Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3)

5.3 Теория и практика кэширования
Основным обоснованием нашего утверждения является то, что приложения, использующие объектно-реляционный слой, как ожидается, превосходят приложения, построенные с использованием прямого JDBC, благодаря возможности кэширования. Хотя мы будем утверждать, что самые странные заявления должны быть сконструированы таким образом, что возможно достигнуть приемлемой производительности без использования КЭШа, нет никаких сомнений, что для некоторых видов приложений – особенно приложения, осуществляющие в основном чтения или приложения, сохраняющие значительные метаданные в БД – кэширование может иметь огромное влияние на производительность.
   Мы начнем наше исследование кэширования с некоторой справочной информации. Она включает в себя объяснение различия кэширования и идентичности областей, и влияния кэширования на изоляцию транзакций. Эта информация, и эти правила могут применяться для кэширования в общем; они применимы не только для Hibernate приложений. Эта дискуссия дает основу для понимания, почему система кэширования в Hibernate такая, какая она есть. Затем, мы введем вас в систему кэширования Hibernate и покажем вам, как включить настройки и управлять КЭШем Hibernate первого и второго уровня. Мы рекомендуем вам внимательно изучить основы, изложенные в этом разделе, прежде, чем начать использование кэш-памяти. Без основы, вы можете быстро заиметь сложные в отладки проблемы одновременной доступности и риски целостности ваших данных.
   Кэш-память хранит представление текущего состояния БД для приложения, либо в памяти или на диске компьютера сервера приложения. Кэш – это локальная копия данных. Кэш находится между приложением и БД. Кэш может использоваться, чтобы избежать обращений к БД, когда:
•   Приложение выполняет поиск по идентификатору (первичному ключу)
•   Хранимый слой разрешает ленивую ассоциацию
Также возможно, кэшировать результаты запросов. Как вы увидите, в главе 7, прирост производительности кэширования запросов минимален, большинстве случаев это так, так что эта функция используется гораздо реже.
   Прежде, чем мы рассмотрим, как работает Hibernate кэш, давайте рассмотрим различные параметры кэширования и посмотрим, как они относятся к идентичности и параллелизму.

5.3.1 Стратеги кэширования и области
Кэширование является настолько фундаментальным понятием в объектно-реляционном отображении, что вы не сможете понять производительность, масштабируемость или семантику транзакций в реализации объектно-реляционного отображения, без первоначальных представления какую стратегию (или стратегии) кэширования он использует. Существуют три основных типа КЭШа:
•    Транзакционный – связанный с текущей единицей работы, которая может быть фактическая транзакция БД или транзакция приложения. Она корректна и используется во время работы единицы работы. Каждая единица работы имеет свой кэш.
•    Процессный – распределяется между многими (возможно одновременными) единицами работы или транзакции. Это означает, что данные в процессном КЭШе доступны одновременно выполняемым операциям, очевидно с последствиями для изоляции транзакций. Процессный кэш может хранить хранимые объекты целиком в КЭШе, или может хранить их состояние в разобранном формате.
•    Кластерный – распределяется между несколькими процессами на одной машине или между несколькими машинами в кластере. Он требует какой-то удаленный процесс взаимодействия для поддержания согласованности. Кэширование информации должно быть продублировано на всех узлах кластера. Для многих (не всех) приложений, кластерное кэширование имеет сомнительную ценность, так как чтение и обновление КЭШа может быть лишь незначительно быстрее, чем прямое обращение в БД.
Хранимые слои могут обеспечивать несколько уровней кэширования. Например, промах КЭШа(cache miss) (поиск элемента в КЭШе, который там не содержится) в транзакционном типе может последовать за поиском в процессном. Запрос к БД будет последней инстанцией.
    Тип КЭШа, используемый хранимым уровнем, влияет на сферу идентичности объектов (взаимосвязь между Java идентичностью и идентичностью на уровне БД)

Кэширование и идентичность объектов
Рассмотрим транзакционный кэш. Кажется естественным, что этот кэш используется также для осуществление идентичности хранимых объектов. Это означает, что транзакционный кэш реализует обработку идентичности: два поиска, использующих один и тот же идентификатор БД, возвращают тот же Java объект в одной единице работы. Поэтому транзакционный кэш идеально подходит, если механизм сохранения также предоставляет транзакционную идентичность.
    Механизм сохранения с процессным КЭШем можно выбрать для реализации процессной идентификации. В этом случае, объект идентификации эквивалентен для БД для всего процесса. Два поиска, использующие один и тот же идентификатор БД в двух единицах одновременно выполняемой работы, вернут в результате один и тот же экземпляр Java. Кроме того, объекты извлекаются из процессного КЭШа, могут быть возвращены по значению. Кэш содержит кортежи данных, а не хранимые экземпляры. В этом случае, каждая единица работы загружает свою копию состояния(кортеж) и строит свой собственный хранимый объект. Объем кэш-памяти и объем идентичности объектов уже не являются одинаковыми.
    Кластерный кэш всегда требует удаленной связи, а в случае POJO-решений, таких как Hibernate, объекты всегда передаются удаленно по значению. Кластерный кэш не может гарантировать идентичность через кластер. Вы должны выбирать между транзакционной или процессной идентичностью объектов.
    Для типичной архитектуры Интернет или корпоративных приложений, самым удобным является, когда сфера идентичности объектов ограничивается одной единицей работы. Иными словами, это ни необходимо, ни желательно, иметь идентичными объекты в двух параллельных потоках. Существуют и другие виды приложений (в том числе некоторые настольные или толстый-клиент архитектуры), где была бы уместно использовать процессную идентичность объектов. Это особенно справедливо, когда память сильно ограничена – потребление памяти транзакционного кэша пропорционально количеству одновременных единиц работы.
    Недостатком процессной идентичности является необходимость синхронизации доступа к хранимым объектам в КЭШе, что приводит к высокой вероятности возникновения тупиков.

Кэширование и параллелизм
Любая реализация объектно-реляционного отображения, которая позволяет нескольким единицам работы разделять одни хранимые объекты, должна предоставлять некоторые формы блокировок на уровне объектов, для обеспечения синхронизации параллельного доступа. Обычно, это реализуется, используя блокировки на чтение и запись (устанавливаемые в памяти) вместе с определением тупиков. Реализации, вроде Hibernate, которые поддерживают различных набор экземпляров для каждой единицы работы (транзакционная идентичность), избегают этих проблем в значительной степени.
    Наше мнение, что блокировок в памяти следует избегать, по крайней мере для веб-сайтов и корпоративных приложений, где многопользовательская масштабируемость является главной заботой. В этих приложений, обычно нет необходимости сравнивать объекты на идентичность в параллельных единицах работы; каждый пользователь должен быть полностью изолирован от других пользователей.
    Существуют довольно веские аргументы в пользу этой точки зрения, когда реляционной СУБД реализует модель многоверсионного параллелизма (например, Oracle или PostgreSQL). Это несколько нежелательно для объектно-реляционного хранимого КЭШа, чтобы переопределять семантику транзакций или модель параллелизма нижележащей БД.
    Рассмотрим эту опцию снова. Транзакционный кэш является предпочтительным, если вы также можете использовать транзакционную идентичность объектов и это лучшая стратегия для высоко-параллельных многопользовательских систем. Этот первый уровень КЭШа будет обязательным, посколько он также гарантирует идентичность объектов. Однако, это единственный кэш, который вы можете использовать. Для некоторых данных, может быть полезен кэш второго уровня, относящийся к процессу (или кластеру), который возвращает данные по значению. Поэтому этот сценарий имеет два уровня КЭШа; вы позже увидите, что Hibernate использует этот подход.
    Давайте обсудим, какие преимущества есть от второго уровня кэширования, или, другими словами, когда для включать процессный (или кластерный) КЭШ второго уровня, в дополнении к обязательному КЭШу первого уровня.

Кэширование и изоляция транзакций
Процессный или кластерный кэш делают извлечение данных из БД в одной единице работы, видимой для другой единицы работы. Это может иметь очень неприятные эффекты, при изоляции транзакций.
    Во-первых, если приложение не имеет эксклюзивного доступа к БД, то процессное кэширование не должно использоваться, за исключением данных, которые редко меняются и могут быть безопасно обновлены по истечению срока кэширования. Этот тип данных часто встречается в приложениях, управляющих содержанием, но редко в финансовых приложениях.
    Вам нужно взглянуть на два основных сценария, с участием неэксклюзивного доступа:
•    Кластерные приложения
•    С общими данными
Любое приложение, задуманное для расширяемости, должно поддерживать кластерные операции. Процессный кэш не поддерживает согласованность между различными КЭШами на разных машинах в кластере. В этом случае вы должны использовать кластерный (распределенный) кэш вместо процессного КЭШа.
    Многие Java приложения разделяют доступ к своей БД с другими приложениями. В этом случае, вы не должны использовать любой тип КЭШа, кроме транзакционного кэша. Не существует никакой возможности для кэширующей системы, что знать когда совместное приложение обновило общие данные. Собственно, это можно реализовать на уровне приложения для показа недействительности процессного (или кластерного) КЭШа, когда изменения сделаны в БД, но мы не знаем какого-либо стандартного или лучшего пути достижения этой цели. Конечно, это никогда не будет встроенной возможностью Hibernate. Если вы реализуете такое решения, то оно, скорее всего подойдет только для вас, потому что оно сильно зависит от среды и используемых продуктов.
    После рассмотрения неэкслюзивного доступа к данным, вы должны установить, как уровень необходим для данных приложения. Не всякий кэш реализует все уровни изоляции транзакций и это критически важно узнать. Давайте посмотрим на данные, которые выгодны для процессного (или кластерного) КЭШа.
    Полное объектно-реляционное решение позволит вам настроить кэш второго кровня отдельно для каждого класса. Хорошими кандидатами на кэширования являются классы, которые представляют:
•    Данные, которые редко меняются
•    Не критичные данные
•    Данные, которые локальны для приложения и не являются общими
Плохими кандидатами для КЭШа второго уровня являются:
•    Данные, которые часто меняются
•    Финансовые данные
•    Данные, которые являются общими с другими приложениями
Однако, это не все правила, которые мы обычно применяем. Многие приложения имеют несколько классов, со следующими свойствами:
•    Маленькое количество экземпляров
•    На каждый экземпляр ссылается много других экземпляров другого класса или классов
•    Экземпляры редко (или никогда) обновляются
Такие данные иногда называют справочными данными. Справочные данные являются отличным кандидатом для кэширования процессным или кластерным КЭШем, и любое приложение, которое интенсивно использует эти данные сильно выигрывает от того, что данные закэшированы. Вы позволяете данным обновляться во время истечение таймаута КЭШа.
    Мы сформировали картину двойного слоя системы кэширования в предыдущих разделах, с транзакционным КЭШем первого уровня и опциональным процессным или кластерным КЭШем второго уровня. Это похоже на систему кэширования Hibernate.

5.3.2 Архитектура КЭШа в Hibernate
Как мы говорили ранее, Hibernate имеет двухуровневую архитектуру кэш-памяти. Различные элементы этой системы можно увидеть на рис. 5.5
(РИС. 5.5)
Кэш первого уровня является также сессией. Жизненный цикл сессии соответствует либо транзакции БД, либо транзакции приложения (как описано ранее в этой главе). Мы считаем кэш, связанный с сессий транзакционным. Кэш первого уровня является обязательным и не может быть выключен; это также гарантирует идентичность объектов внутри транзакции.
    Кэш второго уровня в Hibernate является подключаемым и может быть процессным или кластерным. Это кэш состояний (возвращаемых по значению), а не хранимых экземпляров. Стратегия параллельности КЭШа определяет детали транзакционной изоляции для определенных элементов данных, в то время, как поставщик КЭШа представляет собой физическую, фактическую реализацию КЭШа. Использование КЭШа второго уровня является необязательным и может быть настроено на каждый класс и на каждую ассоциацию.
    Hibernate также реализует кэширование результатов запросов, тесно интегрированных с КЭШем второго уровня. Это является дополнительной функцией. Мы обсуждаем кэш запросов в главе 7, так как его использование тесно связано с фактическим выполнением запросов.
    Давайте начнем с использования КЭШа первого уровня, который также называется КЭШем сессии.

Использование КЭШа первого уровня
Кэш сессии гарантирует, что когда приложение запросит такой же хранимый объект дважды в той же сессии, то он получит тот же (идентичный) Java экземпляр. Это иногда позволяет избегать ненужного трафика БД. Более важно, что он обеспечивает следующее:
•    Слой хранимых объектов не подвержен опасности переполнения стека, в случае циклических ссылок в графе объектов
•    Никогда не возникнет конфликтов представлений об одной строке БД в конце транзакции БД. Существует не более одного объекта, представляющего любую строку БД. Все изменения, внесенные в этот объект, могут быть безопасно записаны в БД (сброшены).
•    Изменения, сделанные в конкретной единице работы всегда незамедлительно видны всему другому коду, исполняемому внутри этой единицы работы.
Вам не нужно делать ничего специального для того, чтобы разрешить кэш сессии. Он всегда включен, и по указанным причинам, не может быть отключен.
Всякий раз, когда вы вызываете save(), update() или saveOrUpdate() и всякие раз, когда вы получаете объект, используя load(), find(), list(), iterate() или filter(), он добавляется в кэш сессии. Когда впоследствии вызывается flush(), то состояние объекта синхронизируется с БД.
    Если вы не хотите, чтобы эта синхронизация происходила, или если вы обрабатываете огромное количество объектов и необходимы эффективные средства управления памятью, то вы можете использовать метод evict() сессии, для удаления объекта и его коллекции из первого уровня кэш-памяти. Есть несколько сценариев, где это может быть полезно.

Управление КЭШем первого уровня
Рассмотрим этот часто задаваемый вопрос: «Я получаю OutOfMemoryException при попытке загрузить 100,000 объектов и манипулируя всеми ими. Как я могу сделать массовые обновления с Hibernate?».
    Наше мнение, что объектно-реляционное отображение не подходит для операций массового обновления (или удаления). Если у вас есть прецедент, как этот, то иная стратегия почти всегда лучше: вызов хранимой процедуры в БД или использование прямых SQL UPDATE и DELETE выражений. Не передавайте все данные в основную память для простых операций, если она может быть выполнена более эффективно в БД.
Если ваше приложение в основном использует массовые операции, то объектно-реляционного отображение не является правильным инструментом для работы!
Если вы настаиваете на использовании Hibernate для массовых операций, вы должны немедленно вызывать evict() каждого объекта, после того, как он будет обработан (при переборе результатов запроса), и тем самым предотвратить исчерпание памяти.
Чтобы полностью убрать все объекты из КЭШа первого уровня, вызовите Session.clear(). Мы не пытаемся убедить вас, что убранные объекты первого уровня является плохой вещью в целом, однако, редко встречаются хорошие случаи его использования. Иногда использование проекций и отчетных запросов, как это обсуждается в главе 7, раздел 7.4.5 «Повышение производительности с отчетными запросами», может быть лучшим решением.
Обратите внимание, что убирание, как и операции сохранения и удаления, могут автоматически применяться к ассоциированным объектам. Hibernate будет убирать ассоциированные экземпляры из сессии, если в файле отображения атрибуту cascade задано значение ”all” или “all-delete-orphan” для конкретной ассоциации.
Когда случается промах первого уровня КЭШа, Hibernate пытается взять значение из КЭШа второго уровня, если он включен для определенного класса или ассоциации.

Кэш второго уровня Hibernate
Hibernate кэш второго уровня является процессным или кластерным; все сессии обладают одним и тем же КЭШем второго уровня. Кэш второго уровня, на самом деле, имеет область SessionFactory.
Хранимые экземпляры хранятся в КЭШе второго уровня в разобранном виде. Думайте о демонтаже, как о процессе похожем на сериализацию (однако, алгоритм, намного, намного быстрее, чем Java сериализация).
Внутреннее представление этого процессного/кластерного КЭШа не представляет большого интереса; более важным является правильное использование политики кэширования, то есть стратегии кэширования и выбор физических провайдеров КЭШа.
Различные виды данных требуют различной политики кэширования: соотношение чтение к записи изменяется, размер БД изменяется, и некоторые таблицы используются совместно с другими приложениями. Так что, кэш второго уровня настраиваемся под детализацию каждого индивидуального класса или коллекцию ролей. Это позволяет, например, разрешить кэш второго уровня для справочных данных и запретить его для классов, представляющих финансовые записи. Политика КЭШа включает в себя настройку следующих параметров:
•    Включен ли кэш второго уровня
•    Стратегию параллелизма Hibernate
•    Политика истекания срока кэширования (такую, как тайм-аут, LRU, зависимую от ОП)
•    Физическое устройство КЭШа (в памяти, индексируемые файлы, кластерная репликация)
Не все классы имеют выгоду от кэширования, поэтому чрезвычайно важно иметь возможность отключить кэш второго уровня. Повторяем, кэш-память, как правило полезно только для классов, которые по большинству считываются. Если у вас есть данные, которые обновляются чаще, чем читаются, не разрешайте кэш второго уровня, даже если все остальные условия для кэширования верны! Кроме того, кэш второго уровня может быть опасен в системах, которые разделяют данные с другими приложениями, которые могут эти данные изменить. Как мы объяснили в предыдущих разделах, необходимо тщательно подумать над решением.
    Hibernate кэш второго уровня устанавливается в два этапа. Во-первых, вы должны решить, какую стратегию параллельности использовать. После этого вам нужно настроить истечение КЭШа и физические атрибуты, используя поставщика КЭШа.

Встроенные стратегии параллелизма
Стратегия параллелизма является посредником; она несет ответственность за хранение элементов данных в кэш памяти и извлечение их из КЭШа. Это важная роль, поскольку она определяет семантику изоляции транзакций для этого конкретного пункта. Вам придется принять решение по каждому хранимому классу, какую стратегию параллелизма кэша использовать, если вы хотите разрешить кэш второго уровня.
   Есть четыре встроенных стратегии параллелизма, представляющие снижение уровня строгости, в терминах изолированности транзакции:
•   Транзакционная – доступна только в управляемой среде. Она гарантирует полную изоляцию транзакций до повторяемого чтения, если это требуется. Используйте эту стратегию для данных которых в большинстве считываются, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в редких случаях обновления.
•   Чтение-запись – поддерживает изоляцию чтения подтвержденного, используя механизм временных меток. Она доступна только в некластерных средах. Опять же, использовать эту стратегию нужно для чтения данных, в которых очень важно предотвратить появление устаревших данных в параллельных транзакциях, в том редком случае обновления.
•   Нестрогое-чтение-запись - не дает никакой гарантии согласованности между КЭШем и БД. Если есть возможность одновременного доступа к одной сущности, то вам необходимо настроить достаточно короткий срок истечения тайм-аута. В противном случае, вы можете прочитать устаревшие данные в КЭШе. Используйте эту стратегию, если данные редко меняются (несколько часов, дней или даже недель), и небольшая вероятность появления устаревших данных не является критической проблемой. Hibernate считает недействительным кэшируемый элемент, если модифицируемый объект очищается(flush), но это асинхронные операции, без какой-либо блокировки КЭШа или гарантии, что полученные данные являются последней версией.
•   Только-для-чтения – данная стратегия подходит для данных, которые никогда не меняются. Используйте её только для справочных данных.
Обратите внимание, что с уменьшением строгости приходит увеличение производительности. Вы должны тщательно оценивать эффективность кластерного КЭШа с полной изоляцией транзакций, перед тем как использовать его в реальных условиях. Во многих случаях, вам было бы лучше, отключить кэш второго уровня для конкретного класса, если устаревшие данные не приемлемы. В начале, протестируйте ваше приложение с отключенным КЭШем второго уровня. Тогда включайте его только для хороших классов-кандидатов, по одному, постоянно тестируя производительность вашей системы и оценивая стратегию параллелизма.
   Можно определить свою собственную стратегию, реализуя net.sf.hibernate.cache.CacheConcurrencyStrategy, но это довольно трудная задача и применяется только в крайне редких случаях оптимизации.
   Вашим следующим шагом после выбора стратегий параллелизма, которые вы будете использовать для ваших кандидатов на кэширования, является выбор поставщиков КЭШа. Поставщик является подключаемым, физической реализаций системы кэширования.

Выбор поставщика КЭШа
Сейчас, Hibernate заставляет вас выбирать одного поставщика КЭШа для всего приложения. Следующие поставщики встроены в Hibernate:
•    EHCache предназначен для простого процессного кэширования в одной JVM. Он может кэшировать в памяти или на диске и поддерживает опциональный Hibernate кэш результатов запроса.
•    OpenSymfony OSCache – это библиотека, которая поддерживает кэширование в памяти и на диске в одной JVM, с богатым набором политик истечения и поддержкой КЭШа запросов.
•    SwarmCache – это кластерный кэш, основанный на JGroups. Он использует кластерное аннулирование, но не поддерживает кэш Hibernate запросов.
•    JBossCache – это полностью транзакционно-репликационный кластеризованный кэш, также основанных на JGroups. Кэш запросов Hibernate поддерживается, предполагая, что часы в кластере синхронизированы.
Легко написать адаптер для других продуктов, реализуя net.sf.hibernate.
cache.CacheProvider.
    Не каждый поставщик КЭШа совместим с каждой стратегией параллелизма. Матрица совместимости представлена в таблице 5.1 поможет вам выбрать соответствующую комбинацию.

Поставщик кэша
только-для-чтения
нестрогое-чтение-запись
чтение-запись
транзакционная
EHCache
x
x
x
OSCache
x
x
x
SwarmCache
x
x
x
JBossCache
x
x

Настройка кэширования включает в себя два этапа:
1.    Взгляните на файлы отображения ваших хранимых классов и решите, какую стратегию параллельного КЭШа вы хотели бы использовать для каждого класса и для каждой ассоциации.
2.    Включите предпочтительного поставщика КЭШа в глобальной конфигурации Hibernate и установите конкретные настройки поставщика.
Например, если вы используете OSCache, нужно отредактировать oscache.properties, или для EHCache ehcache.xml в ваших путях к классам(classpath).
    Давайте, добавим кэширование к нашему CaveatEmptor Category и Item классам.

Hibernate кэширование на практике и заключение (Ч5)

Пессимистическая и оптимистическая блокировки, транзакции приложения, версионирование, детализация сессии (Ч3)

2010-01-23T13:26:00.006+05:00

это перевод книги Hibernate In Action Глава 5
Hibernate транзакции, параллельность и кэширование. Основы транзакций. (Ч1)
Очистка сессии, уровни изоляции транзакций, выбор и установка уровня изоляции транзакций в Hibernate (Ч2)

5.1.7 Использование пессимистической блокировки

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

В режиме чтения подтвержденного (наш предпочтительный уровень изоляции транзакций), БД никогда не приобретает пессимистическую блокировку, если это явно не запрашивается приложением. Как правило, пессимистические блокировки не являются самым масштабируемым подходом к параллелизму. Однако, при определенных обстоятельствах, они могут быть полезны для предотвращения тупиковых ситуаций на уровне БД, которые приводят к сбою транзакций. Некоторые СУБД (например, Oracle и PostgreSQL) обеспечивают SQL SELECT … FOR UPDATE синтаксис, чтобы разрешить использование явных пессимистических блокировок. Вы можете проверить Hibernate диалекты, чтобы узнать поддерживает ли ваша БД эту функцию. Если БД не поддерживает такой функции, то Hibernate будет всегда выполнять обычный SELECT без FOR UPDATE пункта.

Класс Hibernate LockMode позволяет запрашивать пессимистические блокировки на конкретный элемент. Кроме того, вы можете использовать LockMode, чтобы заставить Hibernate не использовать уровень КЭШа или выполнить простую проверку версии. Вы увидите выгоду этих операций, когда мы обсудим версионирование и кэширование.

Давайте взглянем на использование LockMode. Если у вас есть транзакция, на подобии этой:

Transaction tx = session.beginTransaction();
Category cat = (Category) session.get(Category.class, catId);
cat.setName("New Name");
tx.commit();

тогда, вы можете установить пессимистичную блокировку следующим образом:
Transaction tx = session.beginTransaction();
Category cat = (Category) session.get(Category.class, catId, LockMode.UPGRADE);
cat.setName("New Name");
tx.commit();

В этом режиме, Hibernate будет загружать категории, используя SELECT … FOR UPDATE, таким образом, блокирую возвращаемые строки в БД, пока они не будут освобождены, когда транзакция завершится.

Hibernate определяет несколько стратегий блокировок:

• LockMode.NONE – не обращается к БД, за исключением случае, если объект не в КЭШе.

• LockMode.READ – обходит оба уровня КЭШа, а также выполняет проверки версии, чтобы убедиться, что версия объекта в памяти совпадает с той, что существует в БД.

• LockMode.UPGRADE – обходит оба уровня КЭШа, выполняет проверку версии (если применимо), и получает пессимистическую блокировку обновления уровня БД, если она поддерживается.

• LockMode.UPGRADE_NOWAIT – тоже самое, что UPGRADE, но использует SELECT … FOR UPDATE NOWAIT в Oracle. Это отключает ожидание освобождения параллельных блокировок, тем самым выбрасывая исключение о блокировке немедленно, если блокировка не может быть получена.

• LockMode.WRITE – устанавливается автоматически, когда Hibernate записывает строку в текущей транзакции (это внутренний режим; вы не можете указать это явно).

По умолчанию, load() и get() используют LockMode.NONE. LockMode.READ является наиболее полезным с Session.lock() и несвязанным объектом. Например:

Item item = ... ;
Bid bid = new Bid();
item.addBid(bid);
...
Transaction tx = session.beginTransaction();
session.lock(item, LockMode.READ);
tx.commit();

Этот код выполняет проверку версии на несвязанном Item для проверки того, что строка БД не обновлена другой транзакцией с момента её извлечения, перед сохранением нового Bid каскадно (предполагая, что каскадная ассоциация от Item к Bid разрешена).

Задавая явный LockMode, отличный от LockMode.NONE, вы заставляете Hibernate обойти оба уровня КЭШа и пройти весь путь к БД. Мы считаем, что в большинстве случаев кэширование является более полезным, чем пессимистическая блокировка, поэтому мы не используем явный LockMode, если мы действительно в нем не нуждаемся. Наш совет в том, что если у вас есть профессиональный администратор БД на вашем проекте, то пусть администратор решит какие операции требуют пессимистических блокировок, как только приложение запущено и работает. Это решение должно зависеть от тонких деталей взаимодействия между различными операциями, о которых можно не догадаться сразу.

Давайте рассмотрим ещё один аспект одновременного доступа к данным. Мы считаем, что большинство Java разработчиков знакомы с понятием транзакции БД, и это то, что они обычно имеют ввиду под транзакцией. В этой книге, мы полагаем, что это мелкозернистые(fine-grained) транзакции, но мы также полагаем более крупнозернистое понятие. Наши крупнозернистые транзакции будут соответствовать тому, что пользователь считает одной единицей работы. Почему они должны отличаться от мелкозернистых транзакций БД?

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

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

5.2 Работа с транзакциями приложения

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

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

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

1. Данные извлекаются и отображаются на экране в первой транзакции БД.

2. Пользователь имеет возможность просмотреть и изменить данные, вне всяких транзакций БД.

3. Изменения сохраняются в БД во второй транзакции.

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

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

Давайте обсудим применение транзакций приложения на примере.

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

• Последний коммит выигрывает - оба обновления являются успешными, а второе изменение перезаписывает изменения первого. Сообщение об ошибке не показывается.

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

• Слияние конфликтующих обновлений – первая модификация записывается, а вторая может применяться пользователем по выбору.

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

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

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

5.2.1 Использование управляемого версионирования

Управляемой версионирование основывается либо на номере версии, который увеличивается или на метке, которая обновляется в настоящем времени, при любом изменении объекта. Для управляемого версионирования в Hibernate, мы должны добавить новое свойство для нашего класса Comment и отобразить его в качестве номера версии, используя тег . Во-первых, давайте посмотрим на изменения в классе Comment:

public class Comment {
...
private int version;
...
void setVersion(int version) {
this.version = version;
}
int getVersion() {
return version;
}
}

Вы можете также использовать модификаторы public для сеттера и геттера. Свойство должно прийти сразу после отображения идентификатора в файле отображения для класса Comment:

<class name="Comment" table="COMMENTS">
<id ...
<version name="version" column="VERSION"/>
...
</class>

Номер версии – это просто счетчик, он не имеет какой-либо полезного семантического значения. Некоторые люди предпочитают использовать временные метки(timestamp), вместо счетчика:

public class Comment {
...
private Date lastUpdatedDatetime;
...
void setLastUpdatedDatetime(Date lastUpdatedDatetime) {
this.lastUpdatedDatetime = lastUpdatedDatetime;
}
public Date getLastUpdatedDatetime() {
return lastUpdatedDatetime;
}

}

<class name="Comment" table="COMMENTS">
<id ...../>
<timestamp name="lastUpdatedDatetime" column="LAST_UPDATED"/>
...
</class>

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

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

FAQ Если версия родительского объекта изменится, то изменится ли наследник? Например, если одна ставка в коллекции ставок Item изменится, то изменится ли номер версии для Item или нет? Ответ на этот и подобные вопросы прост: Hibernate будет увеличивать номер, когда объект «загрязнен»(dirty). Это включает в себя все «грязные» свойства, будь то одиночные значения или коллекции. Подумайте о взаимоотношениях Item и Bid: если изменяется Bid, то версия связанного Item не увеличивается. Если мы добавим или удалим Bid из коллекции ставок, то версия Item будет обновлена (конечно, мы хотели бы сделать Bid неизменяемым классом, поскольку не имеет смысла изменять ставки).

Всякий раз, когда Hibernate обновляет комментарий, он использует колонку с версией в SQL WHERE условии:

update COMMENTS set COMMENT_TEXT='New comment text', VERSION=3
where COMMENT_ID=123 and VERSION=2

Если другая транзакций приложения будет обновлять этот же элемент, то поскольку он был считан в текущей транзакции приложения, столбец с версией не будет содержать значение 2, и строка не будет обновлена. Hibernate будет проверять количество строк, возвращаемых JDBC драйвером –которые в данном случае будут обозначать количество обновляемых строк, если их количество будет равно нулю, то будет выброшено исключение StaleObjectStateException.

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

Как вы можете видеть, Hibernate позволяет с легкостью использовать версии для осуществления оптимистической блокировки. Можете ли вы использовать оптимистические и пессимистические блокировки вместе, или вы можете принять решения только в пользу одной блокировки? А почему она называется оптимистической?

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

Конечно, обе стратегии имеют свои области применения. Многопользовательские приложения обычно по умолчанию используют оптимистический контроль параллелизма и используют пессимистические блокировки, когда это необходимо. Обратите внимание, что продолжительность пессимистической блокировки в Hibernate является продолжительность одной транзакции БД! Это означает, что вы не можете использовать эксклюзивную блокировку, чтобы заблокировать одновременный доступ дольше, чем на одну транзакцию БД. Мы считаем, что это хорошо, потому что единственным решением была бы чрезвычайно дорогая блокировка в памяти (или так называемая блокировка таблицы в БД) на срок, например, транзакции приложения. Это почти всегда узкое место в производительности; каждый доступ к данным требует дополнительной проверки блокировки с синхронизированным менеджером блокировок. Вы можете, если это сильно необходимо в вашем конкретном приложении, осуществлять простую длительную пессимистичную блокировку, используя Hibernate для управления блокированием таблицы. Шаблоны для этого могут быть найдены на сайте Hibernate, но мы определенно не рекомендуем такой подход. Необходимо внимательно изучить последствия этого исключительного случая.

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

5.2.2 Детализации сессии

Чтобы понять, как можно использовать Hibernate-сессию, давайте рассмотрим отношения между транзакциями. Ранее, мы обсуждали две взаимосвязанные концепции:

• Уровень идентичности (см. раздел 4.1.4)

• Детализацию БД и транзакций приложения

Hibernate сессия определяет сферу идентичности объекта. Транзакция Hibernate соответствует сфере транзакций БД.

(РИСУНОК 5.2)

Какова взаимосвязь между сессиями и транзакциями приложения? Давайте начнем обсуждение с наиболее распространенным использованием сессии.

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

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

Если вам необходима длительная транзакция приложения, то вам могут помочь несвязанные объекты (и Hibernate поддерживает оптимистическую блокировку, обсуждаемую в предыдущем разделе), осуществите его, используя тот же подход (см. рис. 5.3).

Предположим, что ваша транзакция приложения охватывает два клиентских запроса/ответа, например два HTTP-запроса в веб-приложении. Вы можете загрузить интересующие объекты в первой сессии, а затем связать их к новой сессии после того, как они были изменены пользователем. Hibernate автоматически проверит версию. Время между (S1, T1) и (S2, T2) может быть «длинным», настолько длинным, насколько это нужно пользователю, чтобы сделать его изменения. Этот подход известен также, как сессия-на-запрос-с-несвязанными-объектами.

Кроме того, вы можете предпочесть использовать одну сессию, которая охватывает несколько запросов вашей транзакции приложения. В этом случае, вам не нужно беспокоиться о присоединении несвязанных объектов, так как объекты остаются хранимыми в рамках одной длительной сессии (см. рис. 5.4). Конечно, Hibernate по-прежнему несет ответственность за выполнение оптимистической блокировки.

Сессия сериализуемая и может быть безопасно сохранена, например, в сервлете HttpSession. Конечно, базовое JDBC соединение должно быть закрыто и новое соединение должно быть получено на следующий запрос. Вы используете методы disconnect() и reconnect() интерфейса сессии для того, чтобы освободить соединение и затем получать новое соединение. Такое подход известен, как сессия-на-транзакцию-приложения или длинная сессия.

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

Вопрос о реализации транзакций приложения и объем сессии важен при построении приложения. Мы обсудим реализацию стратегии, с примерами в главе 8 «Реализация транзакций приложения».

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

5.2.3 Другие способы реализации оптимистической блокировки

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

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

<class name="Comment" table="COMMENT" optimistic-lock="all">
<id ...../>
...
</class>

Сейчас, Hibernate будет включать все свойства в WHERE условие:

update COMMENTS set COMMENT_TEXT='New text'
where COMMENT_ID=123
and COMMENT_TEXT='Old Text'
and RATING=5
and ITEM_ID=3
and FROM_USER_ID=45

Кроме того, Hibernate будет включать только изменяемые свойства (только COMMENT_TEXT в данном примере) если вы выставите optimistic-lock=”dirty” (заметим, что этот параметр также требует, чтобы вы установили файл отображения класса в dynamic-update=”true”).

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

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

Кэширование в Hibernate (Ч4)
Hibernate кэширование на практике и заключение (Ч5)

Поставщик кэша	только-для-чтения	нестрогое-чтение-запись	чтение-запись	транзакционная
EHCache	x	x	x
OSCache	x	x	x
SwarmCache	x	x		x
JBossCache	x			x