друзья, я вот тут подумал (ощущения мне понравились и я подумал еще раз), а не поговорить ли нам о Java? вот просто так взять и поговорить. не чтобы я выступал с трибуны или менторствовал в постах, а устроить живое толковище. попробуем устроит дискуссию или сессию вопросов-ответов, может быть несколько новых постов родиться.
что вообще волнует уважаемых коллег? что интересно, с чем проблемы? бо маю час та натхнення. так что если кто хочет, милости прошу в комменты.
Замусоленная тема, что будет с Java благодаря Oracle, вначале иск к Google, теперь 7 переносят на год и есть шанс, что не будет ряда мажорных фич.. по мне так язык пора уже хоронить, а вот JVM хороша. Но Rich Hickey начал переносить свою прекрасную Сlojure на CLI, т.е. какбэ настораживает, что и другие JVM языки забьют на эту платформу, а то мало ли что стрельнёт у адвокатов Oracle. Да и вообще, что-то больше склоняюсь к тому, что они собираются продавать большие такие железные штуки со своим всем ПО и Java в конце концов превратиться в платформу лишь для кровавого большого энтерпрайза...
ВідповістиВидалитиДавайте. О платформе или о языке?
ВідповістиВидалитиО платформе :) язык для меня уже почти мёртвый =/
ВідповістиВидалитиВот теперь как раз о языке и интереснее поговорить. Раз некоторые уже его хоронят... ;)
ВідповістиВидалитиТак почему же "мёртв"?
:)
ВідповістиВидалитиот части это художественное преувеличение :) просто не хватает синтаксического сахара и люди вынужденны писать вот такие статьи: http://www.rsdn.ru/article/java/JavaFP.xml На самом деле конечно не всё так плохо, возможно просто меня необъективно клинит в функциональщину и т.п. Или слишком много насмотрелся/написал страшного java кода с отсутствием хоть каких-нибудь гайдлайнов... Просто как-то был перерыв когда делали POC аналогичного проекта на С# + .NET, вообщем например выплеснул часть недовольства вот тут у себя:
http://pdrobushevich.blogspot.com/2010/04/java.html
Кста, Сорялку например уже в испуге форкнули....
ВідповістиВидалитиДак логика ж понятна, в общем. Зачем лишнего засорять язык? Фичи постепенно наращивают, но при этом гарантируется совместимость с предыдущими версиями, а вот это самое главное!
ВідповістиВидалитиСразу скажу, на самом деле я считаю все шаги Oracle(пока) правильными. Единственно, что не понравилось - это что с солярисом они обманули.
ВідповістиВидалитиНу совместимость это да круто... наверное... Но смущает вот эта _постепенность_ Java 7 переносили уже не бог весть сколько раз, а вот тут снова.. на год...
ВідповістиВидалитиНасчёт засорение вопрос философский. В смысле Ruby меня просто убивает, это не язык, а просто винегрет какой-то. Но при этом C# и развитие .NET в целом, например включение F# как официального языка доставляет.
> Сразу скажу, на самом деле я считаю все шаги Oracle(пока) правильными. Единственно, что не понравилось - это что с солярисом они обманули.
ВідповістиВидалитиКак говаривала моя бабушка: обманувшему раз, нет больше доверия.
Насчёт Oracle - Java, у них очень много business софта на Java, слишком много, есть подозрение, что они будут развивать платформу в том направлении как им надо... Совместимость, стабильность... стагнация...
Вообще, мне интересно, как людей не пугает писать под "NET". Где гарантия, что они оставят совместимость? Сколько раз они выкидывали старое?
ВідповістиВидалитиТак что в этом плане меня всё в java устраивает.
Если что, есть xml, Groovy, js, scala уж совсем на крайняк..
Насчёт Oracle - Java, у них очень много business софта на Java, слишком много, есть подозрение, что они будут развивать платформу в том направлении как им надо... Совместимость, стабильность... стагнация...
ВідповістиВидалитиЗачем гадать? По крайней мере, не выкинут - это точно.
Единственное, что пугает, так это то, что от языка (и от платформы) могут отвернутся в научных кругах и учебной среде, как следствие...
Ну я пока ещё Java программист, просто изучаю будущее... Вообще MS любит кичиться совместимостью, реальных дел не знаю, так как в долгоиграющих проектах не участвовал.
ВідповістиВидалити> Если что, есть xml, Groovy, js, scala уж совсем на крайняк..
xml - в ад, Groovy, scala не нравятся.
Вообщем скорее Clojure :)
> Единственное, что пугает, так это то, что от языка (и от платформы) могут отвернутся в научных кругах и учебной среде, как следствие...
ВідповістиВидалитиТоже относительно. Конкурентов достаточного уровня пока не видать для них... MS в этих кругах не очень тоже любят :)
> Ну я пока ещё Java программист, просто изучаю будущее... Вообще MS любит кичиться совместимостью, реальных дел не знаю, так как в долгоиграющих проектах не участвовал.
ВідповістиВидалитиДа пример с NET 1 и NET 2. Насколько знаю, они были не совместимы. А так, я NET не знаю, да и не хочется.
ну вот и я сюда добрался. сразу буду по теме
ВідповістиВидалити1) ничего с Java, как с языком, не случится. ну иск к Гуглу. и что? в стране Его Величества Авторского Права все подают в суд на всех. они так решают вопросы, не приходят друг другу взятки давать, а подают в суд. Эпл на Адоб, Адоб на Эпл, Майкрософт на всех сразу... и ничего. ничего не будет и в этом случае, кто-то кому-то денег заплатит. или не заплатит. а язык? а что язык? OpenJDK в крайнем случае есть, IBM Java. все будет хорошо
2) семерку переносят потому, что там будет новый байткод. плюс система зависимостей. это только на бумаге все просто бывает. то, что они задумали, очень сложная задача. а облажаться им сейчас нельзя. вообще никак нельзя. после ухода Гослинга все скажут "ну вот, Оракл начал выпускать говно". хотя 22 патча на 1.5 и уже 20 на 1.6
3) JVM вообще никуда не денется. там 100500 языков под нее написано.
4) ну и последнее. Java уже давно язык большого энтерпрайза. мелочь пишется на питоне, пыхе, руби, тысячи их. удобнее, быстрее, проще. а мидлтир, ну мидлтир -- да, на Java писать одно удовольствие. но это дорого, очень дорого. поэтому Java ~= Enterprise. и Оракл только расставляет все по местам
p.s. сейчас многие прокты, когда-то бывшые open source, будут переходить на схему
1) выход платной версии
2) патчи платной версии
3) выход следующей платной версии
4) выход предыдущей версии в open source
так что ситуация с Соляркой вполне логична, не особенно приятна, но логична. это трэнд рынка, если хотите
:) Интересное наблюдение - активность участников наблюдается только в первой половине дня.
ВідповістиВидалитиЛично мне рассуждения на тему 'Что будет дальше' и 'Как скоро оно умрет' кажутся лишенными практического смысла (кроме как завязать разговори, познакомится и т.д.:) ).
ВідповістиВидалитиВо первых, ну очень маловероятно, что язык или платформа вот так вот возмет и загнется в ближайшие 1-2 года (хотя бы из за огромного количества уже работающих продуктов).
Во вторых, размышления разработчиков на тему 'что будет дальше' носят вид догадок и смутных предположений. Как ни крути, но
'законодателями моды' в этой области мы не являемся потому как, не разарбатываем стратегию развития продуктов и как правило, не определяем платформу, на которой приложение базируется (конечно же, если здесь присутствуют манагеры MS, Oracle, Apple или подобных компаний). В общем случае мы скорее можем 'анализировать последствия', чем прогнозировать развитие.
Собственно говоря по теме. Предлагаю пообщатся по поводу задач более практического характера. Вот например, меня сейчас очень интересуют 2 вопроса (и особенно интересуют ответы/советы основанные на личном опыте):
ВідповістиВидалитиВопрос 1. А вот как можно довольно быстро определить вменяемость/адекватность java разработчика?
Поясню:
'java разработчика' – именно разработчика, не руководителя и не архитектора.
'вменяемость/адекватность' – ну интересует отделение людей которые 'прочитали 1-2 умные книги' или 'где-то как-то работали, но до сих пор слабо представляют с чем работали и зачем это делали’... вообщем отделить таких товарисчей от людей, которые действительно имеют некий опыт и базово-среднее понимание языка и платформы (или хотябы основных концептов).
'довольно быстро определить' – ну возмем, к примеру, собеседование. Есть 1-2 часа (ну допустим 2 сессии по 1-2 часа). Есть некий дискомфорт и всполошенность и... нету возможности посмотреть на код и манеры этого человека и, скорее всего, завести задушевно-откровенную-просветительно-образовательную беседу тоже не получится.
'А вот как можно' – наверное интересен список вопросов, или может тем для бесед. Из вышесказанного можно сделать вывод, что наверное это должны быть болие или менее формальные вопросы.
Собственно вопрос интересен потому, что замечено, что некоторые разработчики не имея практического опыта (или 'базово-среднего понимания') склонны наступать на довольно интересные грабли (например совать листы в мапу в качестве ключа). И по этому к тех. мнению таких людей надо относится с особой осторожностью. И самое неприятное заключается в том, что 'начитанный' может довольно успешно маскироваться под 'опытного' (особенно на собеседованиях).
Второй 2. ну скорее всего детский.. но все-же: по поводу производительности при обработке больших объемов данных.
ВідповістиВидалитиВот есть бооольшая куча данных (в релиционной БД). И как правило с этими данными нужно делать операции:
а) извлечения (достать и отобразить, ну например в отчете)
б) преобразовать (без участия пользователя)
в) достать - показать- дать чегой-то сделать - сохранить результат.
пункт 'в' сейчас не интересен - как правило пользователь редактирует не большие объемы данных и вообще тут вариантов не много.
Интересуют 'а' и 'б'.
пояснения: Всегда есть некие бизнес правила, т.е. правила фильтрации (что доставать), правила отображения (как показывать) и правила преобразования (что изменить и куда это сохранить).
Я видел 3 подхода к распределению этих правил :
1. Хранить все в БД, т.е. заключить бизнес логику в запросы и хранимый код.
2. Хранить в Java т.е. реализовать бизнес логику в Java.
3. Смешанный. Ну например отфильтровать с помощью SQL, а изменить в Java коде...
По поводу 1. плюсы - производительность. Минусы нужны более 'матёрые' спецы, и сам подход хранения БЛ в БД как то не очень...
По поводу 2. плюсы - для нас это более понятный способ, больше подходит для тестирования и модификации. Минусы - производительность и ресурсоемкость.
По поводу 3. хм.. ну приходилось видеть исключительно кошмарные реализации этого способа.
Собственно говоря вопросов здесь 2:
1. Можно ли хоть как приблизить скорость пережевывания больших объемов данных средствами Java к показателям, которые дают, ну скажем, хранимый код?
2. Какие есть стратегии реализации 3-его подхода, так чтобы и беспорядка не было, и быстро?
> CorWin
ВідповістиВидалитиСпасибо за ответ!
Прошу прощения у всех, меня часто в холивары клинит :)
> Макс
Насчёт первого вопроса, со мной часто общаются начиная с вопроса, какой задачей на предыдущем проекте вы гордитесь и почему, а дальше оттуда пляшут как технические, так и общие вопросы. Сам я против, но всё таки можно давать написать код на собеседовании.
Насчёт два. У нас в проекте большие объёмы (есть таблицы по 20 млн. записей в несколько десятков гигабайт) данных. И мы используем третий подход. Фильтрация, но её мало, идёт за счёт средств СУБД (MS Sql Server), всё остального, которого очень много и сложно, непосредственно тут. Опыт показал, что Java по сути не виновата. Мы всегда при оптимизации упирались в скорость с которой СУБД нам могла отдавать данные, а это упиралось в IO. Поэтому оптимизировали путём архивирования и смены формат размер хранимых данных. Хранимые процедуры тоже можно тестировать, мы это делали своими средствами, но глядели например на вот это:
http://sourceforge.net/apps/trac/tsqlunit/
Кстати, хранимки у нас есть, и пара тормазила, что пришлось воспользоваться возможностью MS SQL Server, написать хранимую процедуру на C#, ну или другом CLI языке. Выиграли почти на порядок. В великом Оракле, по слухам можно на Java писать хронимки.
Как подтверждения посыла, очень хороших результатов добились на .NET, т.к. он с SQL Server общается через shared memory, поэтому данные очень быстро приходили. Поэтому моё ощущение, что проблема не совсем в том, что Java медленно перерабатывает данные. Из таких рекомендаций могу посоветовать только банальности, во всю использовать многопоточность, если есть возможность, у нас было 32 ядра, поэтому было где развернуться, поставить серверный GC, если не стоит, и дальше баловаться с его настройками, помогает иногда очень хорошо.
Насчёт архитектурного подхода. Не знаю поможет ли, но я есть такой общий подход к обработке и интеграции данных ETL, мы его использовали. Он достаточно общий, но есть много Open Source штук, у которых можно посмотреть. Но использовать их не стоит, ИМХО, свой велосипед будет удобнее и быстрее однозначно.
@Макс, начну с последнего вопроса (жаль блогспот не поддерживает ветки комментариев, так что прийдется догадываться).
ВідповістиВидалитимне не совсем понятны исходные
1) что между базой и бизнесс логикой? Хибер? JPA? JDO? в любом случае ответ одновременно простой и сложный. оптимизацию я бы делал в два параллельных этапа
1.1) включить кэш второго уровня. для максимального количества запросов. кэшировать все или почти все. и кэшировать надолго. в идеале - навсегда с репликацией. по этому поводу посмотри в OpenSymphony. и разумеется затюнить кэш по самое немогу.
1.2) затюнить Хибер или что там у вас на persistence layer. потратить неделю, две, месяц. выжать из persistence engine 200% производительности. выкурить все форумы. перебрать максимальное количество настроек. практика подтверждает, что из Хибера можно выжать ответ за 0,5 секунды при нагрузке 1М запросов-в-секунду. единственная проблема в этом случае, которая у ребят осталась, это работа GC. Хибер фризился на 7-10 секунд, когда запускалась сборка мусора. но это решается пунктом 3.
2) можно делать параллельно 1) - разобрать данные на уровне базы во view. сформировать максимальное количество view для сложных запросов. и обращаться к ним, вместо выборки данных с условиями. большинство запросов упроститься. плюс, все что не влезет во view (должно быть 10-15% запросов в самом сложном случае)
3) кластер. обязательно кластер. на уровне Java должны быть минимум две машины в кластере. это решит проблему распределения нагрузки между Хиберами и нагрузкии вообще. база может быть одна.
4) многопоточность также решит проблему. еще вернее ее решит солюшен на базе Grid-подхода. но этот пункт нужно курить отдельно. причем на архитектурном уровне и это займет много времени. я бы делал это после того, как выжал бы все возможное из программной и аппаратной части
@Макс, теперь займемся психологией, т.е. собеседованиями
ВідповістиВидалитипро то, как я провожу собеседования ты знаешь (не я ли собеседовал тебя при приеме на работу в компанию, которую мы оба покинули? или это был Шиян? или Рыбальский?).
[тут жестоко поскпины "тезисы" длинною в жизнь, о том как надо проводить собеседования. будет отдельный пост]
собственно, как бы я отбирал на работу программеров, чтобы отличить "мастеров прохождения собеседований" от знающих и перспективных ребят
0) испытательный срок. если есть испытательный срок, все остальное не важно. если тебе понравился кандидат, бери его на испытательный срок и смотри, как он пишет код, как работает в комаде и прочее. если есть испытательный срок - остальное можешь не читать. ничто так не показывает человека, как реальный бой
1) попроси рассказать про САМЫЙ ИНТЕРЕСНЫЙ проект. и сразу, после окончания рассказа, спроси, ПОЧЕМУ человек счиает именно этот проект интересным. уточня абстракции - "использовались интересные технологии. какие технологии Вы считаете интересными?", "была перспектива роста? какой рост Вы имеете ввиду и что за перспектива?", "были интересные задачи. какие задачи для Вас интересны?". детальнее тут
2) найди пробелы в его знаниях. для этого у тебя должно быть 3 чеклиста (смотри будущий пост). всего не знает никто, найди где он плавает. только сделай это не навязчиво, путем СТАНДАРТНЫХ вопросов
2а) если пробелов не обнаружилось и перед тобой гений, то либо бери его сразу либо 4
3) как только кандидат "поплывет" ищете решение вместе. пусть подумает, погадает, подскажи, зайди с дургой стороны, давай подсказки, подталкивай, поправляй. увидишь как он/она думает
4) дай задачу не имеющую решения - "сколько шариков поместится в школьный автобус (вариант, Икарус, Богдан)?", "сколько бензина потребляет город Львов (привет площе Рынок) в сутки?", "Вы архитектор. что Вы можете сделать для снижения уровня преступности в районе, который Вы проектируете?" - опять-таки посмотришь, как он/она думает. можно поскипать 2, если кандидат кажется перспективным
и главное, панацеи нет. рано или поздно ты все-равно ошибешься, так или иначе не получится дружить со всеми. это нормально. нужно только признавать свои ошибки и их исправлять. в случае с людьми - предупреждать, наказывать и расставаться
@Макс, и последнее. про трэнды в Java, про развитие технологий и т.п. я конечно не менеджер Oracle, Apple, IBM, etc. но сейчас я работаю на Walt Disney Parks and Resorts Online. ВСЯ инфраструктура Walt Disney (разумеется я говорю сейчас про программную инфраструктуру) стоит на Java. и Disney такой не один. это миллионы человекочасов и миллиарды долларов. никто и никогда в здравом уме и трезвой памяти не пойдет на ПЕРЕПИСЫВАНИЕ этого всего. это не мыслимо.
ВідповістиВидалитив самом худшем случае все "замрет" на Java 1.6-1.7. но Элиссон не идиот, чтобы потерять ТАКОЙ рынок. и ТАКУЮ рекламу. если бы Open Solaris занимал хотя бы 10ю долю рынка ОС, его бы никто не отправил на голодный паёк. но Sun не успел, серверный рынок загреб Red Hat (ВСЕ инфраструктурные сервера, кроме почтовых и доменных, Disney стоят на Enterprise Red Hat 5). собственно Sun потому и продался, что у него не было денег. а денег у него не было, потому что он заигрывал с Open Source Community - Open JDK, Open Solaris, Open то, Open сё. это не вероятно круто, но миру не нужна ЕЩЕ одна *nix-based система. а там сидит команда не из пяти человек, каждый и которых получает не 5 копеек. простая математика. Oracle почти ушел с рынка ОС, во всяком случае перестал бодаться с Linux/FreeBSD. и это правильно
и я совершенно не согласен, что мы не можем прогнозировать развитие ситуации. можем. нужно просто правильно понимать подоплёку того или иного события. понимать его ПРИЧИНЫ и его ПОСЛЕДСТВИЯ
и еще про "бессмертность" Java. своя реализация есть у IBM, своя реализация есть у Apple. если Oracle "закроет" язык - они выйдут в лидеры, тем более, что IBM не Sun. у них есть деньги и у них есть успешный опыт выхода в OC. Apple в Open Source трудно представить, но... Джобс уж точно не дурак, и уж точно шанса не упустит. ну и еще одно, чтобы совсем добить тезис про смерть языка - часть инфраструктуры Google стоит на Java. Бринн достаточно сумасшедший, чтобы в случае чего ВЫКУПИТЬ ее у Элиссона. ну или написать свою. у Google точно хватит денег и ресурсов. и Гослинг опять-таки свободен
@Pavel Drobushevich, пожалуйста и принято. хотя можете не извинятся - холивары это практически наше все :) когда перейдете черту (я узнаю ее, когда увижу ее (с) Верховный Суд США) я скажу. обещаю :)
ВідповістиВидалитиCorWin, про гигантский рынок это всё понятно...
ВідповістиВидалитиДа, на уровне таких гигантов решения принимаются на другом уровне. Но есть ещё такой фактор как кадры. А кадры создаются в ВУЗах, немного самообучение.
В ВУЗах с java не очень (по крайней мере у нас). В рунете тоже java на задворках.
Соответственно видится ситуация с тем, что java не хватает популярности. Очень часто сталкиваешься с нехваткой специалистов, очень много ложных мифов.
Увы, политика Oracle в в данном направлении, мне кажется вообще никакой.
В итоге, боюсь это приведёт к тому, что сначала закончатся специалисты, потом волей неволей придётся выбирать др. платформы (тот же NET).
@serger, о, моя любимая тема - кадровый голод и кадровая политика. на эту тему можно рассуждать часами, и возможно я опять-таки напишу отдельный пост.
ВідповістиВидалитиесли отвечать кратко - в Украине (я не знаю, как обстоит дело в России) сложилась очень интересная ситуация с кадрами. их попросту нет. и не важно, о какой технологии речь (возможно, что с PHP ситуация более-менее хорошая). в этой ситуации виноваты... нет, не ВУЗы (они не могут готовить специалистов, потому что система образования кардинально устарела) и нет, не сами ребята (их хватает с горящими глазами, готовых работать за еду. хватает и других, но это про продожение). в этой ситуации виноваты украинские компании и мы с вами коллеги. удивил? да-да, Вы не ослышались, виноваты наши работодатели и мы. и вот почему
1) работодатели на протяжении последних 5-7 лет выбирали готовые кадры с рынка. взвинтили зарплаты до небес и за небеса. тупо перекупали более-менее квалифицированных специалистов. и если взлет зарплат есть 50/50 благо/зло, то откровенная переоценка людей есть однозначное зло. доходит до смешного, человек с 3 (!!!) годами опыта разыскивается на должность.... Java Tech Lead. простите, чем может управлять среднестатический разработчик в 24 года? он с собой только что научился справлять, куда ему командой рулить?
2) а наша вина в том, что мы позволили этому случится. нанимая людей, которые не соотвествуют позициям, позволяя не просто закрывать вакансии для заказчика, а на самом деле платить завышенные зарплаты и давать не соразмерную отвественность
в итоге мы получили рынок, наполненный недомидлами на финансовой игле сеньйорских и тимлидских зарплат. ну и джуниров конечно, но джуниров у нас не особенно жаловали. теперь все будет иначе. так что тут проблема не в Java
с популярностью Java все хорошо, когда я был в апреле в СПБ, оба дня конфа ломилась от студентов, которые УЖЕ имели уровень хорошего джуна.
и потом, финансы решают. уровень зарплат в Java стабильно высокий. .NET колеблется выше-ниже, но в среднем идет ноздря-в-ноздрю. так что научатся, не денутся никуда.
а вот что про Java мало пишут и мало говорят - это да. с другой стороны профильных конференций хватает (в том числе в СПБ, МСК и Киеве), просто они уже стали само-собой разумееющими, резонанса не производят. и это понятно, технологии уже 19 лет.
Я тоже был на конференции в Питере. Честно говоря, про студентов мне трудно что-то сказать конкретное. Не до них было. Но насколько помню вопросы, собственно, были все одними и теми же. Из года в год. Ну и ладно.
ВідповістиВидалитиНа счёт конференций - я далёк, к сожалению, от крупных городов, поэтому, возможно, немного "не в теме".
И опять таки на сколько знаю, у нас, в Ижевске, с java в университетах тяжко. Работают, насколько знаю, в основном "самоучки" или те кто обучался за счёт работы.
@serger, уровень вопросов был разным, согласитесь. я это слышал собственными ушами. четырежды я не успевал задать свой вопрос - его уже кто-то задал и я просто слушал ответы.
ВідповістиВидалитиа что большинство вопросов одинаковые, так это опровеграет Ваш тезис о непопулярности Java - из года в год на конференцию приходят НОВЫЕ ЛЮДИ. растет смена :)
а про Ижевск, извините, я не в курсе. я вообще слабо себе представляю ИТ России, кроме МСК и СПБ. Вы, наверное, можете сказать примерно тоже про Украину.
> Вы, наверное, можете сказать примерно тоже про Украину.
ВідповістиВидалитиНу, само собой! ;)
И да.. проблема с кадрами, описанная вами, не только в it.
О! Как поперло то!
ВідповістиВидалитиКак только открыл пост и дочитал до конца, родился вопрос 'А не боится ли автор, что это перерастет в небольшой форум?' и следом 'Насколько блогер предназначен для этого?'
Когда дочитал до
'... но есть ещё такой фактор как кадры. А кадры создаются в ВУЗах... ' почему то подумалось 'уууу... ну щас начнется...'. И таки да, следующий комент у меня на экран не влазит :)
А по поводу моих вопросов:
ВідповістиВидалити1. Конечно же спасибо за такое кол-во советов относительно собеседований. Но вопрос был не совсем о подборе персонала.
Слава богу, меня сейчас вопросы рекрутинга и собеседований не волнуют. Я простой, среднестатистический кодер. А еще, нас таких простых за несколько месяцев взяли еще человек 'надцать'. И понятно, что команду (по крайней мере сейчас) невозможно назвать сбалансированной. Добавим к этому беспорядок на проекте и получим следующий вопрос: к кому прислушиваться и у кого учится, а на кого не обращать внимание?
Севеты CorWin хороши, но они будут работать при относительно небольших (но частых) выборках. Т.е. ряд предложенных мероприятий нацелен на убыстрение доставки данных уровню бизнес логики.
ВідповістиВидалитиНу а если интересует задача трансформации больших объемов данных? Всех данных. Т.е. из 2М записей придется 'доставлять' все 2М. Только попутно надо еще 'дорасчитать' некоторые куски данных... Нь дя... сумбурнинько получилось. Ну вот например, хранятся у нас N записей. И надо для них вычислить (анализируя другие записи) какие то признаки и результаты засунуть в отдельную таблицу.
Ну обычно это делают так:
Шаг 1. Вычитать Записиси и преобразовать их в объектный вид (Java+ORM)
Шаг 2. Для каждого объекта рассчитать 'что надо' и сохранить результат (используя, опять же какой нить ORM)
'Не обычно' можно сделать по другому: Написать трехэтажный INSERT, который будет все дорасчитывать сам. И отгрести по полной программе от своих коллег, мол это не правильно\не очевидно\не безопасно (нужное подчеркнуть).
Сейчас мне интересны вариант как можно выполнить такие трансформации и чтобы быстро, и чтобы все было правильно\очевидно\безопасно :)
>Pavel Drobushevich
ВідповістиВидалитиДа, виновата не джава, а сеть. Именно здесь (на этапе пересылки) и появляются огромные потери времени. Если надо получить большой объем данных, как то их переколбасить, а потом сохранить, то появляется искушение писать хранимые процедуры. Но, опять же, тут 2 большие проблемы:
1. Найти толкового БД-шника, который напишет толковые хранимки не так уж просто.
2. Оттестировать это творение опять же, не такая уж тривиальная задача.
Было высказано пару интересных моментов:
Писать хранимые процедуры на 'C#, ну или другом CLI языке'. Много об этом слышал, но первый раз узнал о реальном применении. В связи с чем, интересует:
- на сколько усложняется процедура установка\разворачивания приложения?
- Насколько тяжко такой код поддерживать\модифицировать?
Ворой момент, который заинтересовал: ' очень хороших результатов добились на .NET, т.к. он с SQL Server общается через shared memory' . А вот для Java есть подобные механизмы?
@Макс, что значит при небольших объемах? кэш второго уровня предназначен именно для того, чтобы решить проблему доставки данных и БЛ. любого количества данных. он же умеет кэшиться на диск, так что за память можно не переживать.
ВідповістиВидалитиитого, есть два пути ускорить доставку данных
1) ORM + кэш второго уровня
2) Entity Beans from J2EE
вот тебе простой ответ на вопрос, что делать с доставкой 2М записей. и разумеется Lazy Loading и курсоры
что делать с трасформацией данных тоже понятно
1) слой объектов бизнес-логики, который будет "лежать" над объектами ORM и создавать нужные тебе композиции. такие себе фэктори. хотя в данном случае ORM не самое лучшее решение.
2) вообще просто - Stateful Session Beans from J2EE. контэйнер обо всем позаботиться сам. в том числе и памяти
у тебя вообще классическая задача, которая мэпится на J2EE стэк. считай повезло
я не знаю, что такое shared memory by .NET, но в Java есть J2EE
@Макс, про хранимые процедуру на уровне БД. Оракл поддерживает хранимые процедуры на Java.
ВідповістиВидалитина деплоймент не влияет практически - ставяться как обычные хранимки.
на модификацию тоже не особенно влияют. даже проще, чем на PL/SQL
самая большая проблема - отладка. но JDeveloper ее решает (решал?)
да, в прошлом комменте забыл про вставку данных в БД. для этого придумали view's. не нужно никаких своих сложных механизмов, используй стандартные
@Макс, ответ на вопрос "у кого учится" банален - у того, кто знает больше тебя. ответ на вопрос "как его найти" еще более банален - ты узнаешь его, когда увидишь. только жесткой практикой. другого пути нет, авторитеты мы создаем себе сами. и только сами.
ВідповістиВидалити> Макс
ВідповістиВидалити1. У нас были скрипты, проблема была только одна. У нас sql server и само приложение работает на разных машинах. C# процедура компилируется в студии в dll, следовательно надо, чтобы это dll попала с машины приложения, на машину с db. Китайские коллеги придумали хитро(_!_) хак, так как у нас одна такая штука было, то нас это устроило, код dll вставлялся в tsql скрипт, который деплоился с остальными скриптами :)
http://pdrobushevich.blogspot.com/2010/01/ms-sql-server-create-assembly.html
2. С поддержкой всё ок было, никаких трудностей, народ добавлял потом ещё пару таких хранимок, никто особо не жаловался.
--
Для джавы не знаю ничего подобного, jdbc работает через сокеты, так что скорость там остой, может Ораклавцы что-нибудь такое мутили/замутят... Но можно побаловаться с выбором драйвера jdbc и его настроек. Нам это помогло, например переход с 1.1 на 1.2 версию официальном ms драйвера мы выйграли почти 20% как выборке, так и 10-15% в операциях добавления/обновления. Ещё мы использовали responseBuffering=adaptive, вот тут подробнее:
http://msdn.microsoft.com/en-us/library/ms378988(SQL.90).aspx
Вообще, мы сами кеширование данных, которые часто встречаются сами делали в память. Я не знаю как на вашем проекте. Но например мы заказчику предложили увеличить производительность системы на ~70%, если они докупят на сервера парочку 8Gb планочек, и они без проблем согласились..