ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
25 сообщений из 108, страница 2 из 5
  2  все
JPA и наследование
    #39327089
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Локшин МаркPetro123Вот когда ты ссылку на практику из ветки Оракла покажешь. Тогда тут будут шевелиться и и ВОЗМОЖНО включать в свою практику.
Пока там в ветке IMHO ноль твоих ссылок.
Заблуждайтесь дальше, ваше право.

Жесть ты упоротый. Ещё раз для тех кто в танке.
Выбирать 2 поля без индекса и 10 полей без индекса - разница в производительности околонулевая.
Выбирать 2 поля с "покрывающим индексом" или 10 полей с "покрывающим индексом" - разница в производительности околонулевая.
Отсюда вывод - производительность от ширины выборки не зависит.
А есть там индекс или нет, это совершенно другой вопрос к теме отношения не имеющий.
...
Рейтинг: 0 / 0
14.10.2016, 14:16
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327100
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Локшин МаркЕсли более-менее быть в курсе и понимать что и как работает
извини, но уметь оличать мелочи от важностей - это уже уровень программиста а не кодировщика.
BlazkowiczОтсюда вывод - производительность от ширины выборки не зависит.
А есть там индекс или нет, это совершенно другой вопрос к теме отношения не имеющий.
+1
...
Рейтинг: 0 / 0
14.10.2016, 14:25
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327142
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
BlazkowiczЖесть ты упоротый. Ещё раз для тех кто в танке.
Выбирать 2 поля без индекса и 10 полей без индекса - разница в производительности околонулевая.
Выбирать 2 поля с "покрывающим индексом" или 10 полей с "покрывающим индексом" - разница в производительности околонулевая.
Отсюда вывод - производительность от ширины выборки не зависит.
А есть там индекс или нет, это совершенно другой вопрос к теме отношения не имеющий.

Таблицы без индексов на продакшене row-based СУБД бывают очень редко. Разве что у крутых java-ынтерпрайз программистов... Наличие индекса определяет возможные оптимизации, которыми пользуется СУБД. Возможность применения обсуждаемой оптимизации зависит от итогового ResultSet'а. Поэтому вывод абсолютно неверный, т.к. производительность существенным образом зависит от того, попадает ли дополнительное поле в индекс или нет, и поэтому совет твой про производительность крайне плохой и вредный.

PS. А ты - хамло.
...
Рейтинг: 0 / 0
14.10.2016, 14:56
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327159
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Локшин МаркТаблицы без индексов на продакшене row-based СУБД бывают очень редко.

Как это опровергает моё утверждение?

Локшин МаркРазве что у крутых java-ынтерпрайз программистов...

ЧСВ зашкаливает?

Локшин МаркНаличие индекса определяет возможные оптимизации, которыми пользуется СУБД.

И?

Локшин МаркВозможность применения обсуждаемой оптимизации зависит от итогового ResultSet'а.
Какой конкретно оптимизации? У автора темы она одна у тебя другая.

Локшин МаркПоэтому вывод абсолютно неверный, т.к. производительность существенным образом зависит от того, попадает ли дополнительное поле в индекс или нет
ППЦ у тебя логика. То есть это не индексы нужны чтобы оптимизировать запросы которые поступают БД, а программист, который использует БД должен учитывать те индксы которые нахерачил DBA чтобы не дай бог не получить не оптимальную выборку?

Локшин Марк, и поэтому совет твой про производительность крайне плохой и вредный.
Ты даже не вникаешь в то что здесь пишут. У меня совет был использовать ленивые свойства вместо того что изобретает ТС. А влияние ширины выборки на производительность это констатация факта, а не совет.

Локшин МаркPS. А ты - хамло.
Добро пожаловать в интернет.
...
Рейтинг: 0 / 0
14.10.2016, 15:07
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327213
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
BlazkowiczВыбирать 2 поля с "покрывающим индексом" или 10 полей с "покрывающим индексом" - разница в производительности околонулевая.
Отсюда вывод - производительность от ширины выборки не зависит.


Разница есть в контексте плана Index Only Scan. Сама таблица не будет сканиться все данные в чистом виде из индекса будут браться.

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

Но это сферический случай. Выборка идет только по самой таблицы ни каких join и никаких дополнительных полей не из индекса выбираться не будут.

все в контексте Postgres
...
Рейтинг: 0 / 0
14.10.2016, 16:02
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327259
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
BlazkowiczППЦ у тебя логика. То есть это не индексы нужны чтобы оптимизировать запросы которые поступают БД, а программист, который использует БД должен учитывать те индксы которые нахерачил DBA чтобы не дай бог не получить не оптимальную выборку?

Не вдаваясь в подробности кто там должен создавать индексы, поясняю, что небрежным отношением к полям выборки (производительность от ширины выборки не зависит (с) ) ты лишаешь возможности СУБД применить оптимизацию, а DBA сделать индекс для оптимизации, если его почему-то нет.
...
Рейтинг: 0 / 0
14.10.2016, 16:35
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327268
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Локшин МаркНе вдаваясь в подробности кто там должен создавать индексы, поясняю, что небрежным отношением к полям выборки (производительность от ширины выборки не зависит (с) ) ты лишаешь возможности СУБД применить оптимизацию, а DBA сделать индекс для оптимизации, если его почему-то нет.
Ерунда. Система тестируется в условиях близких к боевым, DBA смотрит статистику и оптимизирует базу под запросы. Если критические запросы занимают слишком много времени никто не мешает в ORM их сузить. Только бывает это нужно исключительно после запуска боевого продакшна, если действительно узкое место выявлено на отдельно взятом запросе в реальных условиях. А закладывать подобные тонкие оптимизации на этапе написания кода это бред. Усложнять код только ради того чтобы в будущем рассчитывать на подобный тюнинг - бред в двойне.
Поэтому своё "лишает возможности" можете оставить при себе. Тонкий тюниг всегда требует изменений с обоих сторон - БД и Middle Tier. И никаких ограничений для него нет ни в JDBC ни в ORM.
...
Рейтинг: 0 / 0
14.10.2016, 16:50
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327270
Фотография Паша01
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Паша01
Участник
Все равно я бы загружал меньше колонок из бд, потому что тогда java-обьект будет меньше памяти занимать.
...
Рейтинг: 0 / 0
14.10.2016, 16:55
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327290
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
Паша01,

Вопрос не в меньше колонок, вопрос в наследовании.

Условно говоря

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
  User {
    int id;
    String name;
  }

  UserWithPassport  extends User  {
    String passportNumber;
    ....
  }

  UserWithSvidetelstvoORojdenii  extends User  {
    String svidetelstvoSeria;
    String svidetelstvoNumber;
    ....
  }

  ...



С точки зрения СУБД если тебе нужны только сущности типа User, то их можно получить только индексным покрытием.
Но с позиции философии ООП надо создавать объекты соответствующих класов, хоть и работать с ними как с классом User. А значит при считывании объектов надо: либо заморачиваться с ленивой подгрузкой полей (и разными запросами на то и другое), либо забыть про индексное покрытие.

Вот о чем, как мне кажется, идет философский диспут, который со стороны выгладит как: "Сам ты это слово". :)
...
Рейтинг: 0 / 0
14.10.2016, 17:16
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327292
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Паша01Все равно я бы загружал меньше колонок из бд, потому что тогда java-обьект будет меньше памяти занимать.
Вы к нам на машине времени прямиком из 90х? Планка DDR4 64Gb cо штатной частостой 3000 стоит 400 USD. Это примерно 1 день работы программиста на нормальной зарплате в штатах. На серверную мать можно впихнуть 512Gb!! Это пол Гига оперативы! А вы тут байтики в ваших несчастных объектах экономите, а потом думаете как же потом запустить ещё 5 запросов, чтобы недостающие поля загрузить.
...
Рейтинг: 0 / 0
14.10.2016, 17:17
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327296
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сергей АрсеньевВот о чем, как мне кажется, идет философский диспут, который со стороны выгладит как: "Сам ты это слово". :)
Философский диспут тут только у тех кто мнит себя DBA а про ORM знает только то что "оно медленное". Грузите всегда все поля сущности. Всё. Когда нужны будут тонкие оптимизации - никто не мешает их применить в тех кейсах, где это действительно нужно.
Появился толстый BLOB, который нет смысла тоскать по сети - добавили ленивое свойство.
Решили читать колонки из индекса? Меняем загрузку на SELECT new User(id, name) и только там где это, действительно , требуется.
Вот и всё. Никаких выдуманных ограничений.
...
Рейтинг: 0 / 0
14.10.2016, 17:22
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327701
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
BlazkowiczФилософский диспут тут только у тех кто мнит себя DBA а про ORM знает только то что "оно медленное".
Ну да, ну да использую не один год разные ORM, и знаю только то, что "оно медленное". Опять мимо тазика.
BlazkowiczГрузите всегда все поля сущности. Всё. Когда нужны будут тонкие оптимизации - никто не мешает их применить в тех кейсах, где это действительно нужно.

Вот как раз сущность + поле "someBigData" - хороший случай для оптимизации. Конечно, когда у системы 3,5 пользователя и в таблице 100 записей можно грузить и все. Но если мы говорим о реальной высоко нагруженной системе, то это как раз хорошее место для оптимизации, притом такое место видно заранее (если конечно не знать, что "Ширина выборки на производительность имеет совершенно никакого влияния."). Ну и конечно, можно же все замазать гигагерцами процов и терабайтами оперативы.
А пассаж про "это нужно исключительно после запуска боевого продакшна" вообще шикарен. Такой продакшен может очень сильно огорчить заказчика. И если все вопросы оптимизации относить на этап поддержки в продакшене, то может оказаться, что дешевле все взять и переписать, чем пытаться оптимизировать.
...
Рейтинг: 0 / 0
16.10.2016, 10:18
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327770
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Локшин Марк,
тут были такие методы озвучены:
- ничего не делать т.к. экономия на спичках в CRUD системе
- поставить тяжёлым полям ленивую загрузку по требованию
- вынести тяжёлые поля в отдельный класс с ленивой загрузкой
- ВашСпособ.
Вы считаете что ваш способ настолько важен что его первым в списке поставить?
...
Рейтинг: 0 / 0
16.10.2016, 13:54
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327820
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Локшин Марк
Участник
Petro123Вы считаете что ваш способ настолько важен что его первым в списке поставить?
Да у меня был не столько способ, сколько констатация факта того, что игнорирование ширины выборки может в реальных кейсах весьма ощутимо ударить по производительности...
...
Рейтинг: 0 / 0
16.10.2016, 18:36
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327837
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Локшин МаркНо если мы говорим о реальной высоко нагруженной системе
Бла-бла-бла. Каждый разработчик мнит что его проект будет высоко нагруженной системой. А по факту таких единицы.

Локшин Марк то это как раз хорошее место для оптимизации
Привентивной оптимизации.

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

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

Локшин МаркТакой продакшен может очень сильно огорчить заказчика.
Понятно. Аутсорс к тому же. Бывает.

Локшин МаркИ если все вопросы оптимизации относить на этап поддержки в продакшене, то может оказаться, что дешевле все взять и переписать, чем пытаться оптимизировать.
Ооо, молодой, горячий, руссский программист. Такого видно за версту. Взять и переписать. Других решений не знает.
...
Рейтинг: 0 / 0
16.10.2016, 20:45
| Ответить | Цитировать | Написать  
JPA и наследование
    #39327838
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Локшин МаркДа у меня был не столько способ, сколько констатация факта того, что игнорирование ширины выборки может в реальных кейсах весьма ощутимо ударить по производительности...
Ну, то есть про упоротость я не ошибся.
Во-первых. Ширина выборки таки на производительность не влияет. Вы до сих пор не удосужились это никак опровергнуть кроме как закатыванием глаз и ахами по поводу мегагерц.
Во-вторых. Если вы вдруг решили оптимизировать выборку путём сужения и индексации, то выше я привел как это делается путём простейшей замены способа выборки. Вам же снова по делу нечего возразить, так как по-вашему можно только "всё переписать".
...
Рейтинг: 0 / 0
16.10.2016, 20:49
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328249
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
[quot Blazkowicz]Локшин МаркВо-первых. Ширина выборки таки на производительность не влияет
А почему не влияет-то? По сети трафика гонять меньше, жавских объектов создавать меньше, ну и собственно памяти нужно меньше, CPU тоже.
...
Рейтинг: 0 / 0
17.10.2016, 14:58
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328257
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Андрей ПанфиловА почему не влияет-то? По сети трафика гонять меньше, жавских объектов создавать меньше, ну и собственно памяти нужно меньше, CPU тоже.
Влияет если текст в поле из >1000 букв или картинка в пару мегов.
Тогда уже все решения разобрали.
Вы про какой случай?
...
Рейтинг: 0 / 0
17.10.2016, 15:03
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328279
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
Андрей ПанфиловА почему не влияет-то? По сети трафика гонять меньше, жавских объектов создавать меньше, ну и собственно памяти нужно меньше, CPU тоже.

Имеется ввиду что при выборке записей, в общем случае, неважно два поля выбирать или 12. Производительность запроса при этом практически одинаково, план исполнения от этого не поменяется(ну за исключением случая когда всю запись можно вынять из индекса). Вопрос трафика и тд перпендикулярен всему этому.
...
Рейтинг: 0 / 0
17.10.2016, 15:14
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328280
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Андрей ПанфиловА почему не влияет-то?
Нет, но если буквоедствовать, то да влияет. Но вот только разница между передачей 20 полей с 2 полей на несколько порядков меньше чем затраты RDBMS на поиск записей и передачи этих данных по сети, в принципе.

Андрей ПанфиловПо сети трафика гонять меньше

На сколько меньше?

Андрей Панфиловжавских объектов создавать меньше

Речь о "ширине" выборки. Количество объектов это количество записей в БД. Это уже длина выборки.

Андрей Панфиловну и собственно памяти нужно меньше, CPU тоже.
По поводу памяти, сильно зависит от того что у вас там за типы. По поводу CPU - смешно. Тормоза в работе с БД они реже всего из CPU приходят.
...
Рейтинг: 0 / 0
17.10.2016, 15:15
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328318
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
BlazkowiczАндрей ПанфиловПо сети трафика гонять меньше

На сколько меньше?


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

BlazkowiczАндрей Панфиловжавских объектов создавать меньше

Речь о "ширине" выборки. Количество объектов это количество записей в БД. Это уже длина выборки.

Андрей Панфиловну и собственно памяти нужно меньше, CPU тоже.
По поводу памяти, сильно зависит от того что у вас там за типы. По поводу CPU - смешно. Тормоза в работе с БД они реже всего из CPU приходят.

Речь о ширине и идет. Пришел пакет L7 - его JDBC-драйвер должен разобрать и превратить байты в строки, числа и пр., а только потом ORM превратит это все в бины. Соответственно тратим время на то чтобы получить жавские объекты, потом будем заставлять GC их вычищать.
...
Рейтинг: 0 / 0
17.10.2016, 15:43
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328330
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Андрей Панфиловвот есть транспортный уровень, под ним канальный и физический,

Блеснем познаниемс в OSI?

Андрей Панфиловвы выбираете за раз некоторое внушительное количество записей, которое не влезает в пакет транспортного уровня. Есть разница в одном пакете вы данные получите или в десяти?
Вы не получите выборку одним пакетом почти наверняка. Это раз.
И вы ушли от моего вопроса про величину разницы. Это два.

Андрей Панфиловпотом будем заставлять GC их вычищать.
Ну, давайте про GC ещё поговорим. Например о том что производительность большинства (если не всех) сборщиков в Hotspot зависит от количества живых объектов, а не от количествуа "вычищаемых". Поэтому гадить большим количеством быстроумирающих объектов не страшно.
...
Рейтинг: 0 / 0
17.10.2016, 15:53
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328332
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Андрей Панфилов,
интересно вы копаете).
А вы верите что на прикладном уровне маппинга монописуальна ваша ширина и размер пакетов в нижних уровнях?
...
Рейтинг: 0 / 0
17.10.2016, 15:54
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328362
lleming
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
lleming
Участник
Андрей ПанфиловЕсть разница в одном пакете вы данные получите или в десяти?

есть гарантия что запрос будет выбирать данные точно влезающие либо в 1 либо в 10 TCP пакетов ?
т.е это наиболее распространенный сценарий сетевого соединения?
насколько часто вам приходится подгонять SQL запросы под длину сетевого пакета ?
...
Рейтинг: 0 / 0
17.10.2016, 16:12
| Ответить | Цитировать | Написать  
JPA и наследование
    #39328466
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
BlazkowiczБлеснем познаниемс в OSI?
Тут блистать не чем, данных больше - пропускную способность нужно иметь выше, ограничение на размер пакетов и TCP ACK убивают производительность, или это не очевидно?

BlazkowiczВы не получите выборку одним пакетом почти наверняка. Это раз.
т.е. между 1 и 10 разница есть, а между 5 и 10 уже нет?

BlazkowiczИ вы ушли от моего вопроса про величину разницы. Это два.
Ну по правде говоря, вопрос "почему" на абсурдное, на мой взгляд, утверждение задал я, при этом я свое мнение обосновал. Вопрос "на сколько меньше трафика по сети гонять" тоже сам по себе абсурден, ибо и так очевидно, что в переделе зависимость линейная, а не в переделе зависит от. Что касается изначального постулата, о том что производительность не зависит от ширины выборки, то на запросах вида:

Код: plsql
1.
SELECT '100 chars' AS A1, ... '100 chars' AS AN FROM DUAL CONNECT BY LEVEL < 1000000;



разница в скорости выборки между 2 и 20 колонками - 10%, а между 50 и 100 - уже 100%, по CPU тоже разница видна невооруженным взглядом: http://screencast.com/t/h6kM7yDx

BlazkowiczНу, давайте про GC ещё поговорим. Например о том что производительность большинства (если не всех) сборщиков в Hotspot зависит от количества живых объектов, а не от количествуа "вычищаемых". Поэтому гадить большим количеством быстроумирающих объектов не страшно.А чего вы решили что они быстро умирают-то? В PostgreSQL, к примеру, по-умолчанию данные оседают в резалтсете ( https://jdbc.postgresql.org/documentation/head/query.html#fetchsize-example)
...
Рейтинг: 0 / 0
17.10.2016, 18:01
| Ответить | Цитировать | Написать  
25 сообщений из 108, страница 2 из 5
  2  все
Форумы / Java [игнор отключен] [закрыт для гостей] / JPA и наследование
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39327296&tid=2123600]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 147ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 244ms
total:  494ms
созд. / загр.: 494ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]