Zorkus

Примеры нагруженных проектов из топа Алексы, юзающие Java: Amazon, eBay, LinkedIn, Google.

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

написал статью тут — habrahabr.ru/blogs/programming/123293/

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

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

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

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

вы дадите долю акций?

Просто вот это — дырками после удалений (если использовать просто инкремент айди) — а в чем тут проблема? Ну будут дырки и будут. Это же суррогатные ключи.

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

Какие веские причины не использовать autogenerated surrogate key?

www.texet.ru/news/4952.html

У меня TeXeT 505, всем доволен.

Java востребована и больше всего платят (среди Java-разработчиков) в области нагруженных Enterprise web и всяких нагруженных систем обработки данных.

Из нагруженных сайтов с миллионами посетителей с Back-End на Java (по крайней мере частично) — это Amazon, LinkedIn, eBay.

Системы обработки данных — это биржевые систимы (требуется ultra-low latency), банковские системы (распределенные системы для расчета рисков в инвестиционном банкинге), геоданные (в связке с O-Spatial, как было связано), обработка статистических данных, всевозможные кластерные вычисления и InMemoryDataGrid-ы, наконец та отрасль где работаю я — Data Mining в области Retail индустрии.

LastPass.

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

Потому что на самом деле хорошая глубокая техническая статья — это 1-3 дня на исследования, эксперименты и гуглинг, и день на собственно на написание статьи.

У меня есть в черновиках несколько статей по Java и JVM тематике, но все никак руки не дойдут их допилить и выложить, извините :(

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

1) Java — Atomitcs и неблокирующие алгоритмы в Java, concurrency.
2) Java — как работает внутри Reflection.
3) Groovy — как работают внутри замыкания, мемоизация замыканий, рекурсивные замыкания и лямбды.
4) Метапрограммирование в Groovy — AST-трансформации и Meta-Object Protocol.

Если взглянуть чуть дальше, возникает вопрос — а зачем хранить картинки на амазоне?

Просто у нас был проект в котором миксовались сервера арендованные в обычном датацентре, и сервера в Amazon EC2.

Так вот, если у вас ноды Амазона работают с более менее ровной нагрузкой в режиме 24/7, то арендовать сервер в датацентре возможно будет выгоднее.

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

Для PDF — iText.

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

Без этого трудно писать не-быдлокод.

Мне, как Ынтерпрайзнику, вообще кажется чем-то диким давать юзерам, которые не является девелоперами / support инженерами, и не знают хорошо SQL и базы данных «вообще» прямой SQL-level доступ к большой нагруженной БД с критичными данными (кстати, что значит доступ по TCP? Вы имели в виду — возможность запускать вручную запросы из mysql клиентов, типа SQLYog?)

Вам так необходимо, чтобы Ваши юзеры могли запускать собственноручно криво написанные запросы? Они не могут обходиться набором заголовленных репорт-запросов, или чем-то таким? Они не могут посылать запросы, которые хотят исполнить, специальному грамотному чуваку, который будет их ревьювить и запускать? А как вы предотвращаете нечаянные удаления данных и прочее? Юзеры имеют read-only привилегии на все объекты БД?

Если же Вам прямо так критично давать юзерам такой доступ… Тогда, как тут сказали тут, делать slave-сервер с репликацией, либо настраивать user resource quotas по поводу использования CPU, IO-bandwidth, памяти каждым пользователем (под которыми ваши юзеры коннектятся у БД). Сам в mysql не силен, потому не знаю, как у него с квотами ресурсов.

А зачем вам обращаться к Oracle во время проверки клиентского сертификата? У вас сертификаты хранятся в БД?

habrahabr.ru/blogs/java/84405/ — я в этом топике описывал свой опыт сдачи двух (тогда еще Sun-овских) сертификатов по Java, может найдете что-то для себя полезное.

Мы используем PL/SQL Developer / TOAD / Oracle SQL Developer.

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

В том числе сложные схемы из десятков / сотен таблиц с денормализацией, партишинингом и прочим.