А вот в JavaScript тогда не было ничего. FireBug только появлялся, jQuery не было. Отладка была лишь за счет alert'ов. Серьезный процесс разработки на этом не построишь.

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

А в прошлом году происходил какой-то фантастический рост использования JavaScript. Появились тысячи библиотек. Благодаря jQuery код писать становится на порядок проще, появились средства разработки (IDEA стала ничуть не хуже работать с HTML/JavaScript/CSS), firebug вырос, и пр. Теперь все совсем наоборот, разработка на JavaScript стала гораздо проще чем на GWT, разрабатывать действительно быстрее и результат получается качественней. Есть, конечно, еще куча вещей которые нужно сделать, но уже вполне неплохо. И как минимум позволило ему стать лидером прошлого года, помимо возросшей востребованности.

Я в данном случае не эксперт, но похоже как-то так. А вы что скажете? Вырос ли javascript до уровня серьезной разработки? Какие полезные инструменты порекомендуете? И в каких случаях есть смысл использовать gwt?

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

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

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

А вообще вот презентация (это не то что было на официальном представлении, но суть передает):

Да, все идет к этому, к SaaS, PaaS, Enterpise 2.0, интеграции приложений под одним зонтом и пр. Мы собственно сейчас занимаемся тем же самым, посмотрим кто кого VMForce что-то реальное собирается показать во второй половине года, мы надесь тоже.

P.S. Но суть презентации я не понимаю, хоть убей, что они хотели сказать то? Все сводилось к лозунгу что «Java может работать в облаке». И чо? Кто-то разве сомневался? Не объяснили ни зачем это нужно бизнесу, ни зачем это нужно вендорам, ни что вообще хотят сделать. И вообще трансляция была полуработающая Такое ощущение что им срочно нужно было хоть что-то сказать, но времени на полноценную подготовку не было.

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

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

И я их наверное начинаю понимать, cloud computing это довольно специфичная область. Позиционируется чаще всего как средство экономии, гибкости и удобства с технической стороны. Но для серьезного enterprise это ведь совсем не главный критерий, ну поставят они еще пару стоек под свой старый или новый софт, это ведь не критично, это всего лишь деньги. И техническая сторона тоже не критична, не будет большой заказчик с открытым ртом смотреть в сторону гибкости, удобства, экономии, ну и open-source, его вполне устраивают WebSphere+EJB+JSF+Oracle, пусть это гораздо дороже, дольше делается и переделывается, но в этом случае риски отдаются на сторону зарекомендовавшего себя вендора. А вот SpringSource как раз позиционирует себя как альтернатива всему этому тяжеловесному j2ee, как легкий j2ee лицом к разработчику. Как и cloud computing. Видимо и рынок тут ожидается другой, меньше жирных клиентов, а больше развивающихся, и набирающие темпы web-приложения хотят подхватить. В последних так вообще все очень гибко и динамично, редко где java промелькнет, все больше php, ruby, python и прочие динамические и гибкие технологии. Так что хоть VMWare и Spring совсем разные вещи, но обладают общим духом.

Получается что теперь есть комплект из:

• Spring Framework как общая архитектура приложений, гибкая, «лицом к разработчику» и т.д.
• Grails для быстрой разработки web-приложений
• Tomcat (точнее tm и dm Server'а) как application-сервер
• Hiperic для мониторингов и прочего управления софтом в кластере
• и сам VMWare, конечно, с виртуализацией и прочим, без чего cloud computing толком не организовать
• ничего больше не забыл? Spring в последнее время тоже неплохо расширялся, а за VMWare я не следил

Вот только меня смущает что хоть Spring Source и ложится в эту теорию, но чего то не хватает для полного стека, наверное еще что-то будут докупать? Возможно

• не хватает SOA и прочей интеграции приложений, и я даже думаю конкретно про Mule ESB, потому что он тесно связан с Spring Framework, и хорошо ложится в общий стек. Хотя сам по себе он излишне усложнен по сравнению с вышеперечисленными, и не совсем похож на остальные ESB, выбрал немного свой путь. Последнее может и плюс в данном случае.
• платформы для вычислений в облаке, и тут имхо очень напрашивается GridGain, который тоже очень хорошо с Spring связан, и тоже очень прагматичный и гибкий.
• наверное еще что-то напрашивается, что мне в голову не приходит? Продукты Apache и JBoss'а не рассматриваю, просто потому что их вряд ли купишь вот таким образом, да и незачем имхо, хотя Hibernate красиво смотрелся бы в этой компании, но с ним отдельная история

Так что есть надежда что Spring&Co не загнется, а наоборот расцветет всеми красками и вырастит в сторону очень интересных направлений. Если, конечно, vmware не закроет исходники. Посмотрим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступ

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

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

Сравнение с RDBMS

RDBMS:

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

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

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

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

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

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

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

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

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

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

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

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

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

Реализации

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

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

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

Прочие

CouchDB

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

Hipertable

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

The Cassandra Project

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

Project Voldermort

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

Kdb+

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

LucidDB

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

Sybase IQ

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

Amazon SimpleDB, Google BigTable, Yahoo Everest

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

Ссылки

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

Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.

В отличии от того же Hadoop здесь не гнались за обязательной возможностью обрабатывать терабайты данных за один проход. GridGain удобней будет для длительных вычислений на объемах гораздо поменьше, по хорошему это то что можно передать между нодой в одном List'е, что, возможно, даже практичней. Я не хочу сказать что для больших объемов эта платформа не подойдет, просто при большом объеме данных (а не вычислений над ними) все упирается уже в хранилище данных, и они этим сознательно не занимались, но в случае когда это нужно — можно всегда использовать и внешнюю БД и даже Hadoop HDFS/HBase.

Для многих случаев это очень удобный вариант, отличная альтернатива hadoop'у, ну в самом деле не обязательно у нас что-то грандиозное, вполне может быть у нас пара тысяч независимых операций и cloud из нескольких серверов, и этот самый простой способ распараллелить все. Если основной упор на вычисления, например параллельно обработать несколько тысяч url'ов, на каждый по 1-2 минуты, то GridGain предлагает очень удобное подспорье. И, кстати, очень просто организуется архитектура для случая когда есть несколько gui клиентов, на слабых компах, а все вычисления для них производятся в cloud.

Как я уже говорил платформа давно развивается (кстати нашими соотечественниками), хорошо документирована, внутренняя часть уже вполне стабильна, и к тому же хорошо развиты инструменты мониторинга, алгоритмы балансировки, восстановления после сбоя и пр. и пр. Для ознакомления стоит посмотреть скринкаст «Grid Application in 15 Minutes»

Так вот, хоть как язык Java и проигрывает, но она имеет за плечами огромный набор библиотек, для решения почти всех востребованных задач. Я бы даже выразился так:

На каждую хитрую задачу найдется свой jar с винтом.

ну может не всегда именно jar, а скорее технология, протокол, спецификация, но суть в общем такая.

У всех остальных все хуже. Там или узкая заточенность под одни нужды (RoR), или единая линия партии (.Net), или просто полный хаос.

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

Поэтому нравится java или нет, но... но чаще всего выбирать и не из чего.

P.S.: Хотя, если честно, есть тут один минус: это то что привыкнув к этому все стараются делать «через жаву», что не всегда верно, но это уже издержки производства.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.

EJB немного был когда я работал в Luxoft, но это почти мимо меня прошло. К EJB как таковому у меня отношение отрицательное из-за больших объемов лишней работы, я считаю что простые вещи должны делаться просто. Для EJB это не выполнялось, простые вещи делались сложно. Да и, честно говоря, сложные вещи делались не сложно, а очень сложно. Тоже самое касается и JSF. Система становится всеобъемлющей, делает все что можно, но, как результат комплексности, делает «все» одинаково плохо. Говорят с EJB 3.0 все лучше стало, т.к. изучили опыт аналогов (читай стараются догнать). Но это немного поздно, и с учетом инертности крупных разработчиков все совсем плохо.

Все это рассчитывалось на то что с этим сможет работать совершенно некомпетентный специалист, который возьмет какую либо GUI рисовалку и, не понимая базовых принципов, наклепает работающее приложение. В результате совершенно непонятно как вся эта хренотень может работать, и требует огромных компьютерных ресурсов. Хотя для последнего всегда проще купить HP Superdome и не парится (к тому же часто наоборот, сервера уже стоят, а загружены на 10%, но это уже решается другими методами). На самом деле я даже согласен, часто действительно лучше и гораздо дешевле поставить железо мощнее, но только когда это не вызвано уродством архитектуры. Т.е. когда мы пишем сервер на Ruby (например) и получаем красивое технологически решение, поддерживаемое и легко расширяемое, то потребность в больших ресурсах вполне себе оправдана, но когда говорят «а нафиг нам пул соединений с БД? без него точно все работает, а с ним вдруг что случится? у нас сервер хороший и без пула потянет!» то тут уже не сервер ставить, а архитектора увольнять. Хотя и мысль теоретически даже правильная, но не в том месте.

JSF больше страдает клиентской избыточностью, но для intranet на это еще можно забить. Я даже пару раз пытался использовать это, но так и не понял вкуса. К тому же если нужно создавать хороший интерфейс не заморачиваясь с html/javascript, то надо использовать GWT, а не JSF. Но это, конечно, если нет в требованиях пункта «поддержка Netscape Navigator 3.0», что еще было обязательным года 3 назад, надеюсь сейчас эти «компьютеры» уже окончательно доломались и на замену поставили те где можно поставить браузер посовременней.

А то к чему приводит разработка лишь на JSF могу проиллюстрировать тем что на очередном собеседовании с большим недоверием отнеслись к тому что я могу редактировать JSP/HTML в текстовом редакторе, вместо положенного WYSIWYG редактора. Очень удивились тому что я могу предполагать как изменится внешний вид в браузере после редактирования исходного HTML этой страницы. Я по своей наивности считал это вполне обыденной вещью, которую можно поручать даже школьнику-верстальщику. Ладно хоть не сказал что, к примеру, еще понимаю как HTTP протокол организован и на сайты хоть телнетом ходить могу.

Та вот, к чему я. В начале заголовок статьи был «Я не использую EJB и JSF», сейчас заменил на «Я не знаю EJB и JSF». Т.е. это скорее не принципиальное решение, а ситуация. Ведь может быть действительно моя проблема в том что я не знаю их? Может там есть очень серьезные плюсы? Серьезные выигрыши для проекта, для архитектуры, по сравнению с теми же Spring, Hibernate и пр.? Снижение каких то рисков? Если в случае EJB еще более-менее понятно, само по себе оно нужно, как минимум все части по отдельности востребованы. Вопрос в том нужны ли столь тяжеловесные решения иногда для простых задач, когда есть прекрасные и удобные альтернативы. Иногда конечно стоит взять готовую коробку от IBM, Oracle или BEA, вместо набора различных OS кубиков типа Mule, ActiveMQ, JBoss, Hibernate, Spring и т.д. Это касается EJB, а вот в случае JSF мне вообще непонятно как оно до сих пор существует и кому это надо, неужели JSF дает что-то такое что разработка становится настолько дешевле?

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

И так, помимо алгоритма по умолчанию решил попробовать SDBM:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = c + (hash << 6) + (hash << 16) - hash;
    }
    return hash;
}

и DJB2:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = ((hash << 5) + hash) + c;
    }
    return hash;
}

и подсчитал отклонение от середины для случайно сгенеренных слов (как коротких так и длинных), на английском, русском, смешанном, смешанном+случайный регистр.

И вот график среднего отклонения, по этим четырем тестам:

По оси X — номер бита, по Y отклонение от равномерного, среднее для 4х тестов.
Видно что алгоритм по умолчанию, что DJB2 нормально работают лишь для первых 15 бит, дальше отклонения все больше и больше (на практике понижается вероятность заполнения бита по мере удаления от начала) В Java же int является 32х битным, поэтому в таком случае лучше использовать SDBM, который гораздо меньше отклоняется.

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

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

PS: это для моих потребностей важна именно равномерность, не буду утверждать что для всех остальных случаев SDBM алгоритм лучше/быстрее/пр., но вероятно что именно так.