Re[5]: Объектность; Persistence; Hibernate : что дальше?
От: Lloyd Россия  
Дата: 19.09.08 16:02
Оценка:
Здравствуйте, SteeLHeaD, Вы писали:

SLH>Я не говорю, что это единственное моё занятие, я как раз интеерсуюсь что еще можно делать. И с использованием каких ЭФФЕКТИВНЫХ подходов.


паттерны, архитектура, да мало ли чего на свете интересного
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[6]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 19.09.08 16:18
Оценка:
Здравствуйте, Anatolix, Вы писали:

C>>Да ладно, Hibernate прекрасно работает и в очень нагруженных системах.

A>очень нагруженных это сколько миллионов хитов в день в твоем понимании?
У меня нет хитов — не веб-приложение. Однако, под нагрузкой спокойно тысячу транзакций (данные и запросы с устройств, в основном) в секунду кластер держит.

Для эксперимента некоторые части переписывали на JDBC — смотрели выгодно ли будет перейти с Hibernate на собственный ORM. Изменения в скорости составили всего порядка 15%.

В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи
Sapienti sat!
Re[7]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 19.09.08 17:49
Оценка:
SLH>Это понятно, но мне, возможно, именно как новичку, получившему в свое распоряжение такой мощныый инструмент, как hibernate, кажется, что это инструмент искореняет ВСЕ узкие места в разработке приложений, ориентированных на "запись-можификацию-поиск" данных.

Вот пример такого приложения: у вас есть десятки тысяч работающих стратегий, который добавляются, удаляются да еще и меняются. Ну и все подряд присылают запросы. Почти все изменения хочется персистить. Насколько быстро это будет с hibernate etc?
Re[3]: Объектность; Persistence; Hibernate : что дальше?
От: Igor.K США  
Дата: 19.09.08 22:25
Оценка:
SLH>Ну, cloud computing всего — навсего представляет собой другой способ взымания платы с пользоватлей...
Который приводит к технологическим изменениям. Сначала был майнфрейм — один большой компьютер на всех. Потом, персональный компьютер для тебя одного. Потом сеть персональных компьютеров. Потом сеть ПК с выделенным сервером. Потом сеть ПК с выделенным сервером и виртуальным сервером. Сейчас все это де, плюс, облако. Появляются новые технологии, котоыре позволяют поддерживать старые конфигурации. Которые, увы, приходится изучать. А класс задач не меняется.
"СССР — четыре слова и все лживые" — Вагрич Бахчанян
Re[8]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 19.09.08 22:52
Оценка:
Здравствуйте, kosmik, Вы писали:

K>Вот пример такого приложения: у вас есть десятки тысяч работающих стратегий, который добавляются, удаляются да еще и меняются. Ну и все подряд присылают запросы. Почти все изменения хочется персистить. Насколько быстро это будет с hibernate etc?

Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.
Sapienti sat!
Re[7]: Объектность; Persistence; Hibernate : что дальше?
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 19.09.08 23:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи


Там не в этом проблема — есть общая проблема все OORM в том, что переход по обычно ссылке это константная операция, а в OORM в общем случае логарифмическая — т.к. базе нужно сходить по индексу и что-то получить. Это можно учесть во всех алгоритмах, но обычно про это все забывают и получается тормозилово страшное. Бороться с этим можно, но с какого-то уровня развития системы становится проще не бороться, а выкинуть OORM
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[8]: Объектность; Persistence; Hibernate : что дальше?
От: SteeLHeaD  
Дата: 20.09.08 11:08
Оценка: 1 (1)
Здравствуйте, Anatolix, Вы писали:

A> но с какого-то уровня развития системы становится проще не бороться, а выкинуть OORМ


Системы развиваются в разном направлении, напрмиер, могут быть системы с небольшим кол — вом транзакций, но сложные по своей структуре. Тогда как раз плевать на производительность, но крайне желательно не заниматься связями таблиц в базе, а работать только с объектами.
А вот интересно — как то класс "офисных" задач меняется со временем?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[5]: Объектность; Persistence; Hibernate : что дальше?
От: BulatZiganshin  
Дата: 20.09.08 12:07
Оценка:
Здравствуйте, SteeLHeaD, Вы писали:

A>>Сохрани туда в 10000 раз больше данных и увеличь transaction rate в 100 раз и ты поймешь что тебе еще есть что изучить, а хибернейт загибается при первом дуновении ветра. Системы которые я описал существуют достаточно массово, т.е. это не только интернет сервисы но и большие бизнес системы в компаниях типа билайна или газпрома.


SLH>Это не очень массовая задача. Она очень инетерсная


так в этом и состоит развитие. я вот например и с j2ee технологиями не работал — поскольку исчерпал эту ношу лет на 5 раньше и эти технологии для меня были достаточно предсказуемы и очевидны (ещё rbase/paradox/clarion были неким подобием ORM). если ты хочешь развиваться именно как программист — иди в области "не для всех"
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 20.09.08 16:29
Оценка:
C>Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.

А если я хочу оптимизировать количество копирований памяти по пути?
Re[10]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 20.09.08 16:34
Оценка:
Здравствуйте, kosmik, Вы писали:

C>>Hibernate — это просто интерфейс к БД. Если БД справляется нормально, не использует слишком много грязных трюков (типа очень странных триггеров) — то скорее всего Hibernate будет работать вполне нормально.

K>А если я хочу оптимизировать количество копирований памяти по пути?
А зачем?
Sapienti sat!
Re[6]: Объектность; Persistence; Hibernate : что дальше?
От: SteeLHeaD  
Дата: 20.09.08 19:22
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>если ты хочешь развиваться именно как программист — иди в области "не для всех"


я подумал и с некоторой грустью — признаю, что видимо это верный совет.Спасибо за четкую формулировку.
Но меня все равно инетерсует развитие области, в которой я работаю, (написание приложений для бизнеса) и это как бы отдельный вопрос.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[8]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 20.09.08 19:30
Оценка:
Здравствуйте, Anatolix, Вы писали:

C>>В Hibernate есть несколько мест, где код писали тупые индусы. В основном там, где мало кто на них натыкается. Часть этих мест, на которые я лично всё-таки наткнулся — пришлось поправить и послать им патчи

A>Там не в этом проблема — есть общая проблема все OORM в том, что переход по обычно ссылке это константная операция, а в OORM в общем случае логарифмическая — т.к. базе нужно сходить по индексу и что-то получить.
Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.

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

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

Так ведь в результате получится ровно то, что будет, если оптимизировать использование ORM.
Sapienti sat!
Re[11]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 20.09.08 21:18
Оценка:
C>А зачем?

Быстрее хочется.
Re[11]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 20.09.08 21:29
Оценка:
C>А зачем?

Ну и вообще — иногде весь этот оверхед в виде маппинга обектов на базу абсолютно не нужен. Далеко не всегда нужно графы объектов поднимать из базы. Особенно когда очень хочется скорости.
Re[12]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 20.09.08 22:10
Оценка:
Здравствуйте, kosmik, Вы писали:

C>>А зачем?

K>Быстрее хочется.
А нужно ли?

Оно обычно важно только когда в транзакции нужно обработать очень большое число объектов. А это достаточно редкий use-case.
Sapienti sat!
Re[12]: Объектность; Persistence; Hibernate : что дальше?
От: Cyberax Марс  
Дата: 20.09.08 22:11
Оценка:
Здравствуйте, kosmik, Вы писали:

C>>А зачем?

K>Ну и вообще — иногде весь этот оверхед в виде маппинга обектов на базу абсолютно не нужен. Далеко не всегда нужно графы объектов поднимать из базы. Особенно когда очень хочется скорости.
Ну так ведь никто и не мешает напрямую работать. Если хочется — берёшь голый SQL Connection и работаешь. Никто же не запрещает.
Sapienti sat!
Re[9]: Объектность; Persistence; Hibernate : что дальше?
От: Anatolix Россия https://www.linkedin.com/in/anatolix/
Дата: 21.09.08 01:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Логарифмическое время доступа — это ерунда. Для всех практических случаев можно считать log(N)=C. Проблема тут чисто техническая — roundtrip до базы стоит очень дорого.

log2(1M)=10, это уже не то чем нужно пренебрегать. На счет roundtrip-а согласен.

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


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

C>Так ведь в результате получится ровно то, что будет, если оптимизировать использование ORM.
Только не факт что это проще.
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Re[13]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 21.09.08 05:39
Оценка:
C>Оно обычно важно только когда в транзакции нужно обработать очень большое число объектов. А это достаточно редкий use-case.

Речь шла о том что так называемые бизнес-приложения — разные. Иначе можно было бы сказать что кроме Visual Basic ничего не нужно, потому что большинство бизнес-приложений писали на нем
Re[13]: Объектность; Persistence; Hibernate : что дальше?
От: kosmik Россия http://www.linkedin.com/in/kosmik
Дата: 21.09.08 05:40
Оценка:
C>Ну так ведь никто и не мешает напрямую работать. Если хочется — берёшь голый SQL Connection и работаешь. Никто же не запрещает.

Ну вот, hibernate тут и не нужен. Хотя у высокопроизводительных баз данных и SQL-то не всегда присутствует
Re[7]: Объектность; Persistence; Hibernate : что дальше?
От: BulatZiganshin  
Дата: 21.09.08 09:06
Оценка:
Здравствуйте, SteeLHeaD, Вы писали:

BZ>>если ты хочешь развиваться именно как программист — иди в области "не для всех"


SLH>я подумал и с некоторой грустью — признаю, что видимо это верный совет.Спасибо за четкую формулировку.

SLH>Но меня все равно инетерсует развитие области, в которой я работаю, (написание приложений для бизнеса) и это как бы отдельный вопрос.

понимаешь в чём дело — когда и создание GUI-программ для виндов было областью не для всех, когда вручную приходилось писать функцию окна и обработку всех событий. такие технологии сложны и автоматом означают малое кол-во программистов, их освоивших, и малое кол-во программ. написание типовых бизнес-приложений по определению не может себе такие технологии позволить — оно начинается тогда, когда появляются удобные RAD-средства разработки. и тут уже главным становится просто умение быстро гнать код. поэтому массовая разработка => невысокий уровень разработчиков

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

интересная же работа может быть если ты сам разрабатываешь эти библиотеки. фишка как раз в том что тут у тебя no chances, а в областях "не для всех" ты сам пишешь для себя велосипед. поэтому и работа там более сложная и творческая
Люди, я люблю вас! Будьте бдительны!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.