[quot Blazkowicz]Локшин МаркВо-первых. Ширина выборки таки на производительность не влияет
А почему не влияет-то? По сети трафика гонять меньше, жавских объектов создавать меньше, ну и собственно памяти нужно меньше, CPU тоже.

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

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


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

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

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

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

Речь о ширине и идет. Пришел пакет L7 - его JDBC-драйвер должен разобрать и превратить байты в строки, числа и пр., а только потом ORM превратит это все в бины. Соответственно тратим время на то чтобы получить жавские объекты, потом будем заставлять GC их вычищать.

BlazkowiczБлеснем познаниемс в OSI?
Тут блистать не чем, данных больше - пропускную способность нужно иметь выше, ограничение на размер пакетов и TCP ACK убивают производительность, или это не очевидно?

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

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




разница в скорости выборки между 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)

BlazkowiczВыборки далеко не всегда имеют единственную строку как результат.
Не понял утверждения. База шлет клиенту не по одной строчке, а как клиент захочет ( https://docs.oracle.com/javase/7/docs/api/java/sql/Statement.html#setFetchSize(int)) в оракле значение по-умолчанию - 10. Если знать что резалтсет заведомо узкий, то строки можно упаковывать плотнее. В оракле разница между 1 и 10 на запросе "select '100 chars' from dual connect by level < 1000000" - порядок, что как бы ожидаемо. Причем разница получается исключительно засчет сети.

BlazkowiczАндрей Панфиловт.е. между 1 и 10 разница есть, а между 5 и 10 уже нет?

Не понял связи. Мой посыл в том что затраты на поиск и чтение не сопоставимы с разницей в передаче по сети 5 и 50 колонок.
У вас не предыдущей странице был вопрос: "Вы к нам на машине времени прямиком из 90х?". К вам вопрос: а вы из какого года прибыли? из 2000? Сейчас скорость IO у СУБД перекрывает скорость сетевых интерфейсов. Про поколоночное хранение в СУБД слышали что-нибудь? А про InMemory database?

BlazkowiczОбоснования не обнаружено. Вы указываете на то что разница должна быть. Таки - да, она есть. Но вы игнорируете тот факт что на фоне всех остальных накладных расходов на выполнения запроса ею можно принебречь.

Андрей Панфиловразница в скорости выборки между 2 и 20 колонками - 10%, а между 50 и 100 - уже 100%, по CPU тоже разница видна невооруженным взглядом: http://screencast.com/t/h6kM7yDx
Ну, таблицы на 50+ колонок живут в легаси БД, где таки да, есть смысл сужать выборки. А в пределах до 50 я таких значений в разнице не наблюдал в своих тестах в SQL Server. Но дело давно было.Так есть разница или нет? Может просто MSSQL не так хорошо работает как хотелось бы?

BlazkowiczМы всё ещё говорим об ORM. Вычитали RS в объекты и закрыли. Открытым в серверных решениях его держать нет смысла.И какой вывод я из этого должен сделать? Резалтсет читается некоторое время, можете с ходу сказать сколько запусков GC эти объекты переживут?