Java и большие проекты

Трудно судить о проекте по столь краткому описанию. Поэтому я попробую высказать суждения базируясь на некоторых предположениях и своем опыте. Пишу и на С++ и на Java-е (последние 2 года, а до этого лет 8 на С++, а до этого много еще на чем ). Проекты достаточно большие - распределенные базы объемом около 100 Гигов - ежедневное обновления - 10-20 Мегов. Вообщем, мы управляли БД всех тарифов описываюших все, что ввозилось/вывозилось в/из США по морю. Я был на серверной стороне (Unix). Задача охренительная - поддержать почти в реальном времени (30 сек в среднем на поиск 10-40 сек на вычисление) поиск/вычисление запросов на перевозимый товар. Ладно, это лирика. Начали на С, перешли на С++ и Java-у. При этом использовали Entera-у, потом CORBA-у и RMI и Java Beans. Так вот, могу засвидетельствовать - всему чему учили в универе - все правда. Хотя С/С++ побыстрее будет в смысле исполнения кода, основной выигрыш от алгоритмов - не буду здесь много бухтеть. Основные проблемы со временными затратами были связаны с сетями и доступом у БД. Так что Java здесь проявила себя вполне прилично. Что я хочу сказать - не надо бояться человека с ружьем - Java как язык и среда разработки - вполне приличная вещь. Опять-таки - это со стороны server programmer.

Теперь про сравнение Perl/PHP/Java. Как мне кажется (и здесь я могу быть не прав) Perl/PHP использует CGI модель, в то время как JSP использует иной подход. CGI запускает каждый раз новый процесс и соответственно все утечки рессурсов ликвидируются ОС. Соответственно и накладные расходы надо считать по-разному. Все не так просто.

И еще один пункт, которого я хотел бы коснуться. В С/С++ dtor-ы важны. Только вот приведенный пример с файлами очень не показателен. В больших системах (базируюсь на собственном опыте) время жизни объекта обычно не совпадает с рамками того куска кода, где он был создан. А значит, надо использовать new/delete. Вот здесь и лежат те грабли на которые практически все и наступают - создашь объект, потеряешь не него ссылку и труба. А в доказательство того, что пример не показателен, я приведу книгу банды 4-х про патерны.

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

Mikl>Star-office, весь GUI для Oraclе

СтарОфис аналогичной проверкой даёт 3/4 си/сипп/ха...

А насчёт "Гуй для Оракла" - это круто сказано, типа "гуй для интернета"... А за последний выпуск ODK на джаве - ораклоиды уже получили по балде - обещали исправиться

Mishka>ежедневное обновления - 10-20 Мегов

Слушай, а какие у вас носители информации? А то у нас на работе ожидается 20..30 гиг в месяц, при чём желательно иметь более-менее шустрый доступ, что исключает сменные носители (пока найдёшь, да и найдёшь ли вообще нужный DVD-ROM, к примеру). Лучше чем IDE-RAID пока ничего не придумал (SCSI - слишком высоки расходы на закупку HDD выходят). Сейчас без зеркалирования выходит 6 каналов, т.е. 1 загрузочный HDD + 1 CD-ROM + 10 Барракуд по 80Гб. Вот, думаю, верный ли подход избрали товарищи...

Mishka>Основные проблемы со временными затратами были связаны с сетями и доступом у БД. Так что Java здесь проявила себя вполне прилично. Что я хочу сказать - не надо бояться человека с ружьем - Java как язык и среда разработки - вполне приличная вещь. Опять-таки - это со стороны server programmer.

Кстати, вы не рассматривали C#? MS, кажется,в кои-то веки разработала что-то стоящее. Народ рассматривал, говорят по скорости намного шустрее Java, особенно на всяких API. В потрохах - чистейшая Forth-VM (более того - в разработке C# принимали участие известные фортеры). Ну и, синтаксис проще C/C++, тем более, Java...

Mishka>Как мне кажется (и здесь я могу быть не прав) Perl/PHP использует CGI модель

Не совсем прав. Традиционно Perl работает как CGI, PHP - как модуль Апача. Perl часто также используют как модуль. PHP - теоретически может работать как CGI, но на практике никто это не использует. Разница - по CGI-запросам скрипт перекомпилируется при каждом запросе, в виде модуля - один раз при первом запуске.

Mishka>CGI запускает каждый раз новый процесс и соответственно все утечки рессурсов ликвидируются ОС.

Однако, и в том и другом случае под скрипт запускается новый процесс. Тут ты прав. Но разве в Java не так? Я не представляю себе иного метода. Нет, можно конечно одним процесом обрабатывает все запросы поочереди, но... Хм.

Всё же, скорее всего, как я отмечал, разница во времени работы приложений. PHP/Perl-скрипты (в Web! в системе, естестенно, что угодно может быть!) работают только для создания web-страниц и какой-то минимальной обработке данных, как правило - от долей секунды до секунд. За это время большие утечки не набегают

Есть даже хорошее правило - если скрипт требует под себя более пары сотен килобайт памяти, значит что-то с алгоритмом не то. Хотя иногда приходится (вот сейчас поисковик пишу под Авиабазу - 60Мб индекс) ворочать десятками мегабайт... Но это кошмар сервера

Mishka>Если мои высказывания покажуться резкими/не подходящими или обидел кого, то заранее прошу прощения.

Да нет, на редкость взвешенный подход

>Слушай, а какие у вас носители информации? А то у нас на работе ожидается 20..30 гиг в месяц, при чём желательно иметь более-

Я так понимаю, что это суммарное количество данных, которое надо где-то хранить - я правильно понял? Т.е. эти данные надо хранить и при случае надо уметь достать и обработать? Если это так, то это немного не то чем мы занимались - у нас все данные были активны - с целью аудита любой клиент может выполнить поиск и вычисления по данным любой давности и ответ должен тем же, что и N лет назад. Если я прав в своих предположениях, то ваша задача напоминает то что делает Walmart - крупнейшая сеть супермаретов в Америке. Они собирают данные обо всем - покупателях, товарах, тендециях, и т.д. и т.п. В этом случае и подход нужен другой - скажем разделение (концептуальное и физическое) БД на две части - активной базы и БД для Data Mining. Здесь я рискую вызвать волну протестов и споров, т.к. DM область сравнительно молодая и много чего не устоялось. Та разницу, что я хочу подчеркнуть определю (тоже не правильно - не я это определение выстрадал, но проблемы с языком не позволяют высказаться точнее - говорить легче, чем писать) так - DM БД не всегда содержит абсолютно целостные или полные данные и скорость доступа не так важна.

>менее шустрый доступ, что исключает сменные носители (пока найдёшь, да и найдёшь ли вообще нужный DVD-ROM, к примеру). Лучше чем IDE-RAID пока ничего не придумал (SCSI - слишком высоки расходы на закупку HDD выходят). Сейчас без зеркалирования выходит 6 каналов, т.е. 1 загрузочный HDD + 1 CD-ROM + 10 Барракуд по 80Гб. Вот, думаю, верный ли подход избрали товарищи...

Если честно, то лучше чем mainframe-ы никто не справляется, но дорого очень. У нас здесь выбор был осознанным - мы применяли (я уж не работаю в этой конторе 2 года, хотя и поддерживаю весьма тесные отношения с друзьями) в последнее время EMC box - цена от $200.000 до $500.000 (запутался я с этими точками и запятыми - по-русски если, то "." - это разделитель тысяч, милиоенов и т.п.). Так что здесь - увы - мои советы принимают вид как в том анекдоте - богый советует бедному: питаться надо правильно, не кушать всякое там дерьмо - не надо жалеть денег на это! Опять-таки - за бугром я и по этой причине оторван от Российской действительности.

А вот про IDE-RAID тут много не скажу. Мой друг, вот пару недель назад, купил в компьютерном магазине за $100 IDE-RAID. Можно опять спорить - а RAID ли это? Он поддерживает уровни 0, 1, 0/1. То есть 3, 5 и далее там просто не существуют. Проблема с IDE на мой взгляд другая - при существующих IDE каналах, каждый из них может работать с 2 дисками и берет при этом одно прерывание. Т.е. слишком много дисков не поставишь. Кстати, есть у меня чуство, что это IDE стандарт не позволяет иметь более 2-х HDD на одном канале - кто-то может прокомментировать?
А скази (SCSI) может на одном прерывании 15 дисков иметь легко, а по последним стандартам и поболее.

>Кстати, вы не рассматривали C#? MS, кажется,в кои-то веки разработала что-то стоящее. Народ рассматривал, говорят по скорости намного шустрее Java, особенно на всяких API. В потрохах - чистейшая Forth-VM (более того - в разработке C# принимали участие известные фортеры). Ну и, синтаксис проще C/C++, тем более, Java...

Не люблю я M$. И C# не считаю выдающимся. Хотя тут можно спорить. Компилятор для C# для .NET по заказу мелко-мягкого писал мой хроший товарищ из Питера (он и сейчас там), так он его как бы любит. Ну и писать мы нашу систему начали когда С# не было и в помине. А с форточниками (не уиндусятами) я хорошо знаком - я в аспирантуре был на матмехе в Питере - рядом с форточниками.

[ слишком длинный топик - автонарезка ]

>Не совсем прав. Традиционно Perl работает как CGI, PHP - как модуль Апача. Perl часто также используют как модуль. PHP - теоретически может работать как CGI, но на практике никто это не использует. Разница - по CGI-запросам скрипт перекомпилируется при каждом запросе, в виде модуля - один раз при первом запуске.

Да, с Apache так и обстоит, согласен. А с друми (Netscape Enterprise Server скажем) как обстоит дело?

>Однако, и в том и другом случае под скрипт запускается новый процесс. Тут ты прав. Но разве в Java не так? Я не представляю

JSP вроде живет постоянно (это я со слов моего друга и его опыта работы с Tomcat). Вроде Apache загружает одну JVM per process (здесь я использую мои знания как компиляторщика и догадки, т.к. сам это дело не трогал) и JSP крутится внутри некоторой среды не этой JVM - то есть наличие некоторой глобальной среды.

>себе иного метода. Нет, можно конечно одним процесом обрабатывает все запросы поочереди, но... Хм.

Я тут переносил Unix (HP-UX, Solaris, Linux) некоторые plug-ins для Apache и NCS серверов написанных в наший конторе под Windows и совсем немного поиграли с Apache 1.3 и 2.0. Так вроде управляешь и количеством изначально запущенных копий сервера и максимальным их количеством и количеством threads внутри одного сервера. Это я к тому, что имеется возможность взаимного влияния - а уж как это сделано - тут код надо смотреть.

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

>Всё же, скорее всего, как я отмечал, разница во времени работы приложений. PHP/Perl-скрипты (в Web! в системе, естестенно, что угодно может быть!) работают только для создания web-страниц и какой-то минимальной обработке данных, как правило - от долей секунды до секунд. За это время большие утечки не набегают

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

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

Я полностью его поддерживаю.

>Хотя иногда приходится (вот сейчас поисковик пишу под Авиабазу - 60Мб индекс) ворочать десятками мегабайт... Но это кошмар сервера

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

Mishka>Если мои высказывания покажуться резкими/не подходящими или обидел кого, то заранее прошу прощения.

Да нет, на редкость взвешенный подход

Спасибо. Просто я люблю поспорить и по мнению моих друзей, очень сильно возбуждаюсь.

Маленькая поправочка было - среды не этой JVM - надо - среды на этой JVM.

И еще, я говорил уже, что я из-за бугра - смещение по времени - 8 часов. Прошу прощения, что отвечаю не сразу - пока домой доберусь - уже 8 часов вечера по-местному (в Москве 4 утра), потом с детьми, по дому всякое - вообщем к компу подхожу часов в 11.

>>А то у нас на работе ожидается 20..30 гиг в месяц
Mishka>Я так понимаю, что это суммарное количество данных, которое надо где-то хранить - я правильно понял?

Да, фактически - только хранить. Доступ нужен будет нечастый. Но индексы на всё это делать придётся, т.к. нужно будет и просто искать иногда данные...

По существу - это архив издательства, со всеми фотографиями, статьями, вёрстками готовых номеров... Хотя, гм. Готовые номера там мег по 500 весят. Впрочем, их как раз можно и на CD сбрасывать.

Mishka>Если честно, то лучше чем mainframe-ы никто не справляется, но дорого очень.

Дык! А я с трудом $1300 выбил на вышеуказанную конфигурацию

>по-русски если, то "." - это разделитель тысяч, милиоенов и т.п.)

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

>богый советует бедному: питаться надо правильно, не кушать всякое там дерьмо - не надо жалеть денег на это!



Mishka>А вот про IDE-RAID тут много не скажу. Мой друг, вот пару недель назад, купил в компьютерном магазине за $100 IDE-RAID. Можно опять спорить - а RAID ли это? Он поддерживает уровни 0, 1, 0/1. То есть 3, 5 и далее там просто не существуют.

Нечто аналогичное, только за ~$150. 4 канала (т.е. до 8 HDD) с RAID 0, 1, 0/1. Кстати, более продвинутые IDE-RAID'ы есть, но стоят дороже. Что-то от $300.

>каждый из них может работать с 2 дисками и берет при этом одно прерывание

Ну, на PCI это не проблема. Да и на ISA даже, с некоторыми оговорками, иожно было разные устройства вешать на одно прерывание. А уж сейчас-то... В Win2K вообще была любовь все PCI-железки на одно прерывание вешать У меня на 11-м висели звуковуха, сетевая карта, видео и модем И всё работало замечательно. WinXP стала, кажется, раскидывать-таки по разным прерываниям по возможности.

>есть у меня чуство, что это IDE стандарт не позволяет иметь более 2-х HDD на одном канале - кто-то может прокомментировать?

Да, естественно. Master и Slave. Третьего не дано. Или Cable select, что всё равно даёт только два девайса. Это флопов можно было в теории до 4-х на канал вешать

Но в той машинке, что я собрал - 6 каналов (два на материнке и 4 в RAID-контроллере). Вероятно, ещё и расширить можно будет. Только корпус имеет всего 6 + 5 слотов на 5" и 3

[ слишком длинный топик - автонарезка ]

Mishka>А скази (SCSI) может на одном прерывании 15 дисков иметь легко, а по последним стандартам и поболее.

Зато эквивалентные диски стоят столько, что на пару таких винчестверов можно новый IDE-файлсервер собрать

Скорость пониже, конечно, процессор загружен поболее, но серверу ничем другим заниматься и не нужно будет

Mishka>Не люблю я M$.

Дык, кто ж его любит? С ним просто живут Хотя, справедливости ради, последние годы у них немало удачных решений...

Mishka>Да, с Apache так и обстоит, согласен. А с друми (Netscape Enterprise Server скажем) как обстоит дело?

Ну, Netscape сейчас совсем уж экзотика... Но, я просто как-то упустил из виду альтернативы. Уж настолько IIS не люблю, что про любые альтернативы Апачу забываю

Mishka>А про компиляцию скрипта - тут я не совсем согласен - я думаю, что интепретатор не запускается каждый раз, а вот скрипт интерпретируется каждый раз. Я не думаю, что кто-то кэщирует оттраслированный код

Ну, в mod_perl именно так. Компиляция происходит один раз и код кешируется. И с этим тоже куча проблем. Чуть ли не до рестарта web-сервера при изменении в коде скрипта Хотя я с mod_perl пока не сталкивался.

Mishka>Я думаю, что это правильно - скрипт хорош для этого, а про большую обработку - тут крепко думать надо и использовать подходящий интсрумент.

Если он есть... Пишу, вот, сейчас поисковик под Авиабазу. Индекс текстов выходит мегабайт под 60. То ли мириться с тормозами при поиске (60Мб перелопатить - это несколько секунд) с реализацией Perl+plain-text-base, то ли загнать всё в MySQL, и доставать через PHP - тогда всё быстро, но память жрёт... Да и встроенные средства индексации MySQL мне не нравятся - все слова, что короче 4-х символов не индексируются. А специфика Авиабазы требует поиска слов типа "Су-27"

Mishka>Тут надо что-то надо делать и не на скрипте, хотя скрипты могут использоваться в качестве прототипов. (не бейте сильно - просто на Унихе для отладки таких дел я ничего не знаю)

Вся беда, что у меня на Авиабазе нет возможности использовать что-то кроме Perl/PHP/MySQL (при чём последний - осторожно) и встроенных FreeBSD команд...

Mishka> Спасибо. Просто я люблю поспорить и по мнению моих друзей, очень сильно возбуждаюсь.

После того, что сейчас в Политическом творится с тобой просто отдыхаешь

Мы все дальше уходим от топика. Не знаю, интересно ли это всем. Если есть проблемы, то мы можем удалиться в частную переписку. Мое мыло: evstelerama.com.

>Да, фактически - только хранить. Доступ нужен будет нечастый. Но индексы на всё это делать придётся, т.к. нужно будет и просто искать иногда данные...

А как надо искать? По каким критериям? Это важно, т.к. позволяет оценить функциональность. Иногда легче написать самостоятельно свою специализированную СУБД, чем использовать общую. Я вот сделал именно так когда создавали spell-checker для Молдавского языка 8-10 лет назад - компы по респулики в основном 286 - 40 Мег винт - норма - задача амбициозна - вложить весь язык в 5 Мег. А язык-то не простой - у некоторых частей речи до 27 форм. Скорость работы должна была быть интерактивная. Вообщем я как раз за СУБД и отвечал. Пришлось писать свою - я там такого наворотил! - виртуальная адресация элементов на странице, иерархические индексы, специальная грамматическая упаковка/сжатие информации - ужас! Написано на TurboPascal 6.0. 650000 слов уложилось в 3.5 Мегов (со всеми индексами)и скорость поиска достигала 100 в секунду на 286-12 HDD 40 average seek ~ 40. Стыдно хвастать, но я был тогда горд страшно. Это к тому, что может надо и тебе что-то такое.

ЮНечто аналогичное, только за ~$150. 4 канала (т.е. до 8 HDD) с RAID 0, 1, 0/1. Кстати, более продвинутые IDE-RAID'ы есть, но стоят дороже. Что-то от $300.

А решит ли это проблему? 20 Гигов в месяц - 4 месяца и один диск вылетел, а 5 дисков - 20 месяцев - а потом что? Если такого срока хранения хватит, то и ладушки. Даже, если пойти на покупку 160 Г дисков, то 40 месяцев (дорого только пока). Вообще-то через 40 месяцев, как говорил Ходжа Насредин, то ли ишак сдохнет, то ли эмир помрет.

>Ну, на PCI это не проблема. Да и на ISA даже, с некоторыми оговорками, иожно было разные устройства вешать на одно прерывание.

Я тоже так думал. А потом купил Xtasy видео карточку когда обновлял младшей дочке комп - взял PCI (у нее AGP 1.0 на маме), установил - не пашет. Сижу читаю доки везде - а там приписочка в Troubleshooting Section - мелким шрифтом - наша карта не может делить прерывание с другими устройствами. Я чуть, как говорит один мой друг, весь на какашки от злости не изошел.

>Зато эквивалентные диски стоят столько, что на пару таких винчестверов можно новый IDE-файлсервер собрать

Я вот тут заходил на http://www.pricewatch.com, так там 36Г Ultra SCSI 2 от IBM стоят $135 http://www.pricewatch.com/1/26/1908-1.htm. Но опять - это я здесь, а вы ам (или ноборот ).

[ слишком длинный топик - автонарезка ]

>Дык, кто ж его любит? С ним просто живут Хотя, справедливости ради, последние годы у них немало удачных решений...

У меня впечатление такое, что ничего такого они не изобрели - все было скопированно у других и названо по-своему. Хотя у меня несколько очень хороших друзей в нем работает в R&D работает, должен сказать, что количество действительно умных людей там офигенное, только вот идей до реальных вещей почему-то очень мало доходит. Ничего не напоминает?

>Ну, Netscape сейчас совсем уж экзотика... Но, я просто как-то упустил из виду альтернативы. Уж настолько IIS не люблю, что про любые альтернативы Апачу забываю

Ага, еще различие - здесь он популярен среди больших компаний.

>Ну, в mod_perl именно так. Компиляция происходит один раз и код кешируется. И с этим тоже куча проблем. Чуть ли не до рестарта web-сервера при изменении в коде скрипта Хотя я с mod_perl пока не сталкивался.

Ну вот - руку сохранил . А как же с динамическим формированием скриптов? С JSP таже история вроде.

>Если он есть... Пишу, вот, сейчас поисковик под Авиабазу. Индекс текстов выходит мегабайт под 60. То ли мириться с тормозами при поиске (60Мб перелопатить - это несколько секунд) с реализацией Perl+plain-text-base, то ли загнать всё в MySQL, и доставать через PHP - тогда всё быстро, но память жрёт... Да и встроенные средства индексации MySQL мне не нравятся - все слова, что короче 4-х символов не индексируются. А специфика Авиабазы требует поиска слов типа "Су-27"

А вот здесь могу дать совет. Я бы сделал так - создал бы словарь вида число-слово. Причем слово - это общее определение набор символов. Т.е. "олл," тоже может быть словом. Потом надо набрать статистики по наиболее часто используемым "словам" и включить их в словарь. Далее все тексты перекодируются в числовое представление и хранятся как вектора/матрицы чисел (каждое число представляет слово) - индексация идеальная. 4 000 000 000 должно хватить с лихвой на словарь. Поиск - в два этапа - сначала в словаре, а потом в страницах. Шуршать должно очень прилично - поиск/индексация по целым числам работает намного быстрее, чем по строкам. Это примерно то, что я сделал пару раз. Единственное тонкое место - перевод текста требует времени, так я использовал жадный алгоритм. Вместе со статистикой это напоминает упаковку по Хофману, только статистику я вычислил раз и на всегда. И назад перекодировать легко.
Завершаюсь, а то чего-то я слишком много про себя говорю и советов много даю, а их к делу не пришьешь - скромнее надо бытью