ReSQL.ru
     
powered by simpleCommunicator - 2.0.30     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / hibernate кто нибудь тестил когда оно помирает?
25 сообщений из 92, страница 3 из 4
  3  все
hibernate кто нибудь тестил когда оно помирает?
    #39993794
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
andreykaT
вадя
пропущено...
для чего нужно?

для того чтоб проиндексировать в эластике эти 200 лямов сучностей
он тебя спросил про бизнес задачу, но ты как всегда ответил "проиндексировать".
...
Рейтинг: 0 / 0
29.08.2020, 18:28
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993847
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
PetroNotC Sharp
andreykaT
пропущено...

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

я в общих чертах описал задачу. что тебе даст точно название полей в ддлке? ты сразу выдашь идеальное решение или что?
...
Рейтинг: 0 / 0
30.08.2020, 10:24
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993854
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
Kachalov
Андрей Панфилов
Вы понимаете что означает фраза "causing inconsistencies while iterating"?

- конечно понимаю, это такие же "фантазии" которые и Вас посетили. Если у меня есть справочник который заполняется с помощью liquibase или flyway, то что в нем может изменится в процессе чтения? Могу читать его сто тысяч раз в день и ничего в нем не изменится, пока не выйдет новый релиз или специально обученные люди не проведут обновление справочника скриптом

Просто замечательно, у меня фантазии, у самого главного в JPA фантазии, но каким образом справочник в liquibase относится к топику?

Kachalov

Андрей Панфилов

Пагинация - отстой, подходит только для web
...
Странно... читать не хотите вы, а виноват в этом я..

- пока не увидел что надо читать? что именно лично Вы считает лучшим решением чем пагинация?

Увы, видимо не в коня корм, придется объяснять для особо одаренных.

Вот нам нужно каким-то образом обработать кучу записей, JPA для подобных вещей совершенно не предназначен - у него цели несколько иные, вы же предлагаете остаться в рамках JPA, но еще и делать это через откровенную жопу, а именно:

вот у нас есть какой-то запрос вида (для наглядности синтаксис из MySQL):

Код: plsql
1.
select * from tbl LIMIT M, N



Вопрос: какой контракт должна соблюсти СУБД для обращения типа: "ты там что-то повыбирай, а потом отдай некий кусок того что получилось"? контракт здесь только один: если количество строк между M и M+N, то количество возвращаемых строк должно не превышать N, т.е. когда вы пытаетесь с каждым запросом увеличивать OFFSET, БД не предоставляет никаких гарантий, что:
- вы не получите ранее прочитанные данные
- вы не пропустите данные

чтобы хоть какие-то "гарантии" появились нужно на таблице tbl вводить отношение порядка и указывать его в ORDER BY, тогда мы будем говорить базе следующее: ты там что-то выбери, потом отсортируй, а потом выкинь M строк и отдай N. Вопрос: вот зачем нам базе говорить "выбери все и выкинь M строк" (т.е. с каждым разом все будет происходить медленнее и медленнее) если у нас уже есть отношение порядка на таблице и мы можем сразу сказать "давай выбирай с этого места", нужно только запомнить предыдущее место?

ну вот мы вроде бы все соблюли, но есть одно "но": пока мы что-то там делаем в то же время из БД могут как удалять записи, так и вставлять новые, при этом если отношение порядка и существует, то нет никаких гарантий что в БД не напихают данных, который по этому отношению порядка окажутся "более старыми" нежели мы сейчас вычитываем? И вот вопрос: зачем все это делать, если есть куда более бронебойные способы, а именно:
- можно выбрать только идентификаторы - вполне возможно что они в память поместятся
- использовать getResultStream, вместо getResultList
- выставить JPA на улицу и использовать всю мощь JDBC
- сделать собственную очередь в которую никто залезть не будет (здесь из накладных расходов только insert select)

пагинация - это самый ущербный (и неработающий) способ.
...
Рейтинг: 0 / 0
30.08.2020, 12:45
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993894
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
окей, 200 мульонов записей
их надо обновить.
вариант 1) - я вычитываю 200 мильонов записей в память призывая патриарха кирилла, внутри одной транзакции, делаю апдейт каждой записи, закрываю транзакцию. чудо происходит где то там в недрах либ. все довольны.
вариант 2) - я начинаю вычитывать кусками и апдейтить кусками. сам. рукой. левой и правой.
ну на мое субъективное мнение вариант 2 - это пагинация. а как еще?
...
Рейтинг: 0 / 0
30.08.2020, 15:29
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993906
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
andreykaT
окей, 200 мульонов записей
их надо обновить.
что значит обновить?
...
Рейтинг: 0 / 0
30.08.2020, 16:32
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993915
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
вадя
что значит обновить?
Ну что ты дурацкие вопросы задаешь, обновить - значит обновить

PS.

У ТС, судя по тщетным попыткам в течение недели, примерно такой кейс:
нужно какие-то договоры "перекинуть" с одного контрагента на другого, причем у самого договора может быть несколько контрагентов (т.е. там M:N). Изначально источником правды у него является СУБД (PostgreSQL), но поскольку этот PostgreSQL крутится на каком-то особо стремном железе , поэтому горячие финские парни решили, что на обращения типа "а выдай-ка нам договоры с .. по .. с таким-то контрагентом" писать SQL в духе: select id from contract c where date between .. and ... and exists (select * from contract_counteragent cc where cc.contract_id=c.id and cc.counteragent_id=?) не особо хорошо, и делают примерно так:
- оно будет быстрее искаться в эластике - там и OLTP никакого нет, поэтому еще и горизонтально масштабируется
- в эластик таблица contract_counteragent заводится как атрибут типа "список" у сущности contract
- когда меняются данные в contract или в contract_counteragent, то в эластик отправляются новые данные

Но тут у ТС возникла некая "проблема": нужно договоры с одного контрагента перекинуть на другого, а таких договоров сколько-то миллионов, т.е. то что делается в БД обычным SQL типа "update contract_counteragent cc set cc.counteragent_id=? where cc.counteragent_id=?", теперь с учетом того что это все еще пуляется в эластик превращается в некий "геморрой", потому что нужно создать некое количество заданий на переиндексацию этих договоров и дождаться (?, а может и не нужно ждать) когда они рассосутся.

но вот чет я вообще проблемы не увидел: вот сделал "insert into reindex_job select cc.contract_id from contract_counteragent cc where cc.counteragent_id=?" и задания на переиндексацию готовы. Здесь предметом обсуждения может быть разве то, каким образом все это дело ускорить для эластика (идея: можно туда заранее новые данные скормить, O_o), но мы пока данные из БД вычитать не можем, потому что нужно всенепременно считывать их в j.u.List<Contract> и никак иначе
...
Рейтинг: 0 / 0
30.08.2020, 18:30
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993921
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
andreykaT
я начинаю вычитывать кусками и апдейтить кусками. сам. рукой. левой и правой.
ну на мое субъективное мнение вариант 2 - это пагинация. а как еще?
Какими еще кусками? Вот тебе же вендор пишет:
Example 6.4. Index rebuilding using index() and flushToIndexes()
This strategy consists in removing the existing index and then adding all entities back to the index using FullTextSession.purgeAll() and FullTextSession.index(), however there are some memory and efficiency constraints. For maximum efficiency Hibernate Search batches index operations and executes them at commit time. If you expect to index a lot of data you need to be careful about memory consumption since all documents are kept in a queue until the transaction commit. You can potentially face an OutOfMemoryException if you don’t empty the queue periodically: to do this you can use fullTextSession.flushToIndexes(). Every time fullTextSession.flushToIndexes() is called (or if the transaction is committed), the batch queue is processed applying all index changes. Be aware that, once flushed, the changes cannot be rolled back.

Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
fullTextSession.setFlushMode(FlushMode.MANUAL);
fullTextSession.setCacheMode(CacheMode.IGNORE);
transaction = fullTextSession.beginTransaction();
//Scrollable results will avoid loading too many objects in memory
ScrollableResults results = fullTextSession.createCriteria( Email.class )
    .setFetchSize(BATCH_SIZE)
    .scroll(ScrollMode.FORWARD_ONLY);
int index = 0;
while(results.next()) {
    index++;
    fullTextSession.index(results.get(0)); //index each element
    if (index % BATCH_SIZE == 0) {
        fullTextSession.flushToIndexes(); //apply changes to indexes
        fullTextSession.clear(); //free memory since the queue is processed
    }
}
transaction.commit();


ScrollableResults results - олицетворяет собой открытый курсор в БД, getResultStream() в JPA - тоже олицетворяет собой открытый курсор БД, никакой "пагинации" там нет.
...
Рейтинг: 0 / 0
30.08.2020, 19:09
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993961
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
andreykaT
окей, 200 мульонов записей
их надо обновить.
вариант 1) - я вычитываю 200 мильонов записей в память призывая патриарха кирилла, внутри одной транзакции, делаю апдейт каждой записи, закрываю транзакцию. чудо происходит где то там в недрах либ. все довольны.
вариант 2) - я начинаю вычитывать кусками и апдейтить кусками. сам. рукой. левой и правой.
ну на мое субъективное мнение вариант 2 - это пагинация. а как еще?

Вариант0 - делаешь update table set a=b и время сюда на форум.
А потом уже из этого факта решаем куда двигаться.
...
Рейтинг: 0 / 0
30.08.2020, 23:32
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993965
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
andreykaT
PetroNotC Sharp
пропущено...
он тебя спросил про бизнес задачу, но ты как всегда ответил "проиндексировать".

я в общих чертах описал задачу. что тебе даст точно название полей в ддлке? ты сразу выдашь идеальное решение или что?

Названия полей наверное не имеют значения. Но вот их типы - важны.
Обычно я половину информации о доменной модели собираю из декларации таблицы.
Даже такой пустяк как длина поля - вобщем может определять архитектуру.
Что там. Идентификатор типа счетчика? GUID? Или varchar(255), или XML/Json.
Некоторые из этих типов легко индексируются. Некоторые пригодны для поиске
в диапазоне (т.н.) index-range-scan. Даже есть целое направление в ДБМС под названием
TimeSeriesDB. Они заточены под данные имеющие монотонную темпоральную природу.
И дисковые структуры данных в них - соотв. И текущее количество datarows тоже интересно.
И результат выборки или результат dml в среднем сколько строк собирает? Это любому
DBA интересно. Без этого грамотно нельзя задизайнить.
...
Рейтинг: 0 / 0
30.08.2020, 23:59
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39993999
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
mayton,
Третю страницу уговаривают "этого нехорошего человека редиску" выложеть Модель.)))
Но он в неадеквате.
...
Рейтинг: 0 / 0
31.08.2020, 08:22
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994008
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Может NDA, или просто технически сложно. Но нам не нужно все-все бизнес-данные. Хотябы статистика.
...
Рейтинг: 0 / 0
31.08.2020, 10:07
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994024
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Андрей Панфилов

Вы понимаете что означает фраза "causing inconsistencies while iterating"?
...
Просто замечательно, у меня фантазии, у самого главного в JPA фантазии, но каким образом справочник в liquibase относится к топику?

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

Андрей Панфилов

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

- ну и когда в JPA перестали работать JPQL запросы SELECT, UPDATE и DELETE, которые прекрасно могут обработать таблицу одним запросом (при желании можно посмотреть что за запрос - никакой мистики, обычный SQL-запрос)? Да и возможность отправки native SQL через JPA не случайно предусмотрели.


Андрей Панфилов
чтобы хоть какие-то "гарантии" появились нужно на таблице tbl вводить отношение порядка и указывать его в ORDER BY, тогда мы будем говорить базе следующее: ты там что-то выбери, потом отсортируй, а потом выкинь M строк и отдай N.

- вроде тоже уже обсудили, что первичный ключ это (в РСУБД) как правило кластеризованный индекс и как раз ситуация что при повторной выборке я получу отличный от предыдущей результат возможна только при вставке или удалении записей (а это фантазийное предположение которое даже и не всегда допустимо - пример со вставкой в справочники с помощью скриптов, при котором никаких конкурентных вставок или изменений не возможно, я уже приводил)

Андрей Панфилов
есть куда более бронебойные способы, а именно:
- можно выбрать только идентификаторы - вполне возможно что они в память поместятся
- использовать getResultStream, вместо getResultList
- выставить JPA на улицу и использовать всю мощь JDBC
- сделать собственную очередь в которую никто залезть не будет (здесь из накладных расходов только insert select)
.

- ну наконец то что то конкретное (а то наркоманы, кони, жопы, web):

а) "использовать getResultStream, вместо getResultList" - имеет смысл не для всех ORM (надо смотреть реальную имплементацию в конкретной версии ORM, т к может быть имплементирован как getResultList().stream()), принципиально подходит только для ситуаций с итерированием результата (а это не всегда нужно), а самое главное это никак не решает проблемы длительного выполнения запроса, так как не дает распараллелить задачу. А если фантазировать и вспомнить что ТС еще чего то в выборке апдейтить хочет, то похоже мы опять приходим к ситуации когда надо выбрать все пусть и более оптимальным методом.

б) "выставить JPA на улицу и использовать всю мощь JDBC" - см. выше: в JPA есть возможность выполнять JPQL и Native SQL запросы. Никаких чудес тут не будет. Чем JDBC окажется в этой ситуации лучше мне лично не понятно.

в) "сделать собственную очередь в которую никто залезть не будет" - тут мы уходим в архитектурные дали и в абстрактные рассуждения о том зачем ТС делает то что делает


Андрей Панфилов
пагинация - это самый ущербный (и неработающий) способ.

- это работающий (для большинства РСУБД и ситуаций не связанных с конкурентной вставкой/удалением и изменением данных) способ, который позволяет распараллелить выборку данных или использовать их пошаговую обработку без длительных блокировок БД
...
Рейтинг: 0 / 0
31.08.2020, 11:19
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994025
andreykaT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andreykaT
Участник
PetroNotC Sharp
andreykaT
окей, 200 мульонов записей
их надо обновить.
вариант 1) - я вычитываю 200 мильонов записей в память призывая патриарха кирилла, внутри одной транзакции, делаю апдейт каждой записи, закрываю транзакцию. чудо происходит где то там в недрах либ. все довольны.
вариант 2) - я начинаю вычитывать кусками и апдейтить кусками. сам. рукой. левой и правой.
ну на мое субъективное мнение вариант 2 - это пагинация. а как еще?

Вариант0 - делаешь update table set a=b и время сюда на форум.
А потом уже из этого факта решаем куда двигаться.

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

ну ты ж понимаешь что чудес не бывает и одна строчка у тебя это может быт какой-то мегатяжелый процесс под колпаком.
...
Рейтинг: 0 / 0
31.08.2020, 11:21
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994031
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Kachalov


Андрей Панфилов
чтобы хоть какие-то "гарантии" появились нужно на таблице tbl вводить отношение порядка и указывать его в ORDER BY, тогда мы будем говорить базе следующее: ты там что-то выбери, потом отсортируй, а потом выкинь M строк и отдай N.

- вроде тоже уже обсудили, что первичный ключ это (в РСУБД) как правило кластеризованный индекс и как раз ситуация что при повторной выборке я получу отличный от предыдущей результат возможна только при вставке или удалении записей (а это фантазийное предположение которое даже и не всегда допустимо - пример со вставкой в справочники с помощью скриптов, при котором никаких конкурентных вставок или изменений не возможно, я уже приводил)

Kachalov,
Большинство баз данных и язык SQL НЕ гарантирует порядок записей при отсутствие ORDER BY.

за такое "ситуация что при повторной выборке я получу отличный от предыдущей результат возможна только" разработчиков можно смело увольнять. IMHO

Причем тут "первичный ключ" вообще не понятно. Если это __редкий__ случай СУБД, когда все таблицы хранятся как кластеризованные (SQL Lite, Paradox и некоторые другие) то первичный ключ на порядок записей может влиять. Но в БОЛЬШИНСТВЕ случаев, связи между первичным ключом и порядков возврата записей НЕТ и быть не может.
...
Рейтинг: 0 / 0
31.08.2020, 11:30
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994034
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Kachalov

Андрей Панфилов
пагинация - это самый ущербный (и неработающий) способ.

- это работающий (для большинства РСУБД и ситуаций не связанных с конкурентной вставкой/удалением и изменением данных) способ, который позволяет распараллелить выборку данных или использовать их пошаговую обработку без длительных блокировок БД

Вы говорите о разных вещах. Первое - это про согласовнность.

А второе это скорее про перформанс партишенинг или splittable для BigData
для тех случаев когда партишены изолированы физически (разные файлы
или сегменты данных).
...
Рейтинг: 0 / 0
31.08.2020, 11:37
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994055
Андрей Панфилов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Андрей Панфилов
Участник
mayton
Вы говорите о разных вещах.
Да не о разных, он просто работает с MSSQL и наблюдаемые особенности в поведении выдает за действительность (ага, топик-то про PostgreSQL и Hibernate), в MSSQL же и "конкуренции" никакой нет - там, по умолчанию, читатели блокируют писателей, а писатели читателей.
...
Рейтинг: 0 / 0
31.08.2020, 12:00
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994063
PetroNotC Sharp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PetroNotC Sharp
Участник
andreykaT,
1. Мы не можем рассуждать об эластике пока не знаем ЧТО НАДО СОХРАНЯТЬ. То есть Модель данных.
2. Да, есть батч апдейт но он ускоряет пачку операций.
Что мы ускоряем если ты не выдал ВРЕМЯ?
3. Ждем и разлекаемся Модель и Время update.
...
Рейтинг: 0 / 0
31.08.2020, 12:10
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994110
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Leonid Kudryavtsev

Большинство баз данных и язык SQL НЕ гарантирует порядок записей при отсутствие ORDER BY.

- да конечно, отсортируйте по ключу. Это абсолютно верно и необходимо и в РСУБД никакого оверхеда, которым тут запугивают, не произойдет, потому что ключ уже отсортирован (хотя в языке SQL об этом и не сказано).

Leonid Kudryavtsev
можно смело увольнять. IMHO

- сказали "А", скажите и "Б": считаете что "пагинация - это самый ущербный (и неработающий) способ"?
...
Рейтинг: 0 / 0
31.08.2020, 13:38
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994118
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Kachalov
Leonid Kudryavtsev

Большинство баз данных и язык SQL НЕ гарантирует порядок записей при отсутствие ORDER BY.

- да конечно, отсортируйте по ключу. Это абсолютно верно и необходимо и в РСУБД никакого оверхеда, которым тут запугивают, не произойдет, потому что ключ уже отсортирован (хотя в языке SQL об этом и не сказано).

Где и что отсортировано?

Primary Key в "обычных" ( TM ) СУБД (типа Oracle, PostgreSQL) AFAIK ничем не отличается от любого Unique Index.

И сортировка по ключу, в большинстве случаев будет именно сортировка. В некоторых случаев, если в плане запроса СУБД сможет и захочет (или разработчик специально застивит) использовать INDEX_ASC / INDEX_DESC метод доступа к данным, то физической сортировки не будет (будет проход по индексу)

Kachalov
- сказали "А", скажите и "Б": считаете что "пагинация - это самый ущербный (и неработающий) способ"?

Для чего и в каких ситуациях?

Ну таки да, назову 100500 случаев, когда даже для вывода на экран, "тупая пагинация" будет совершенно неработающим способом.

P.S. У меня опыт работы с Oracle, в других СУБД, разумеется, все может быть немного подругому.
...
Рейтинг: 0 / 0
31.08.2020, 14:07
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994127
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Пример из Oracle 11.2.0.4:
 

set echo on
drop table test1;
create table test1 ( id number, v varchar2(10), CONSTRAINT test1_pk primary key (id) );
insert into test1 (id,v) values ( 99, 'aaa' );
insert into test1 (id,v) values ( 70, 'aaa' );
insert into test1 (id,v) values ( 60, 'aaa' );
insert into test1 (id,v) values ( 75, 'aaa' );
select * from test1;
-- План замечательно показывает, что есть сортировка
select * from test1 order by id;
explain plan for select * from test1 order by id;
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
-- Здесь Index Full Scan поэтому "как бы" отсортированы
select /*+ INDEX_ASC( test1 test1_pk) */ * from test1;
explain plan for select /*+ INDEX_ASC( test1 test1_pk) */ * from test1;
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

Результат выполнения в PL/SQL Developer command window

 

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
select * from test1;
 
        ID V
---------- ----------
        99 aaa
        70 aaa
        60 aaa
        75 aaa
select * from test1 order by id;
 
        ID V
---------- ----------
        60 aaa
        70 aaa
        75 aaa
        99 aaa
explain plan for select * from test1 order by id;
 
Explained
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1692556001
----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     4 |    80 |     3  (34)| 00:00:01 |
|   1 |   SORT ORDER BY      |       |     4 |    80 |     3  (34)| 00:00:01 |
|   2 |   TABLE ACCESS FULL| TEST1 |     4 |    80 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------
Note
-----
   - 'PLAN_TABLE' is old version
   - dynamic sampling used for this statement (level=2)
 
14 rows selected
select /*+ INDEX_ASC( test1 test1_pk) */ * from test1;
 
        ID V
---------- ----------
        60 aaa
        70 aaa
        75 aaa
        99 aaa
explain plan for select /*+ INDEX_ASC( test1 test1_pk) */ * from test1;
 
Explained
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());
 
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 2426924228
--------------------------------------------------------------------------------
| Id  | Operation                   | Name     | Rows  | Bytes | Cost (%CPU)| Ti
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |          |     4 |    80 |   852   (4)| 00
|   1 |   TABLE ACCESS BY INDEX ROWID | TEST1    |     4 |    80 |   852   (4)| 00
|   2 |    INDEX FULL SCAN            | TEST1_PK |     4 |       |    29  (11)| 00
--------------------------------------------------------------------------------
Note
-----
   - 'PLAN_TABLE' is old version
   - dynamic sampling used for this statement (level=2)
 
14 rows selected
...
Рейтинг: 0 / 0
31.08.2020, 14:26
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994150
Kachalov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kachalov
Участник
Leonid Kudryavtsev
Где и что отсортировано?

Primary Key в "обычных" ( TM ) СУБД (типа Oracle, PostgreSQL) AFAIK ничем не отличается от любого Unique Index.

1) Отличается или нет, допустим не так важно как факт существования самой структуры позволяющей более эффективно получать доступ к данным чем при ее отсутствии.
2) При создании primary key индекс создается автоматически
3) Сортируя по primary key мы обходимся без full scan таблицы так как это индекс
Leonid Kudryavtsev

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

Сортировка по отсортированному (организованному в дерево или хз чему, исходя из особенностей имплементации БД, но оптимальное для прохода) это совсем не то же самое что сортировка по произвольному полю

Leonid Kudryavtsev

Kachalov
- сказали "А", скажите и "Б": считаете что "пагинация - это самый ущербный (и неработающий) способ"?

Для чего и в каких ситуациях?

Ну таки да, назову 100500 случаев, когда даже для вывода на экран, "тупая пагинация" будет совершенно неработающим способом.

- ближе к делу, есть интересная задачка: пройтись по таблице из 200 млн записей, как делать? В приоритете скорость обработки и расход памяти
...
Рейтинг: 0 / 0
31.08.2020, 16:11
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994160
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Kachalov

3) Сортируя по primary key мы обходимся без full scan таблицы так как это индекс

Вашу мысл с примари кей вообще не понял.

Индекс оно конечно хорошо, но он только в РЕДКИХ случаях помогает избежать сортировки.

Во многих случаях, план с INDEX_ASC / INDEX_DESC:
1) может банально не получится сделать или он будет крайне не эффективен.
(что колонка cost как-бы и показывает, что по мнению СУБД нафиг индекс на 4 записи не сделся)
2) под каждое условие индексы строить - то еще себе занятие

Kachalov

Сортировка по отсортированному (организованному в дерево или хз чему, исходя из особенностей имплементации БД, но оптимальное для прохода) это совсем не то же самое что сортировка по произвольному полю

Cылку на доку плиз!
Сортировка она в любом случае сортировка. AFAIK

Kachalov

- ближе к делу, есть интересная задачка: пройтись по таблице из 200 млн записей, как делать? В приоритете скорость обработки и расход памяти

Что в ней интересного?
Андрей Панфилов

- выставить JPA на улицу и использовать всю мощь JDBC
...
Рейтинг: 0 / 0
31.08.2020, 16:49
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994162
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mayton
Участник
Kachalov

- ближе к делу, есть интересная задачка: пройтись по таблице из 200 млн записей, как делать? В приоритете скорость обработки и расход памяти

Можно распараллелить этот процесс по технологиям Map-Reduce и получим те цифры которые вы хотите.
Вопрос будет только в том сколько EMR instances вы будете готовы оплатить.
...
Рейтинг: 0 / 0
31.08.2020, 16:59
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994163
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Kachalo, Ваши утверждения:

"первичный ключ это (в РСУБД) как правило кластеризованный индекс и как раз ситуация что при повторной выборке я получу отличный от предыдущей результат возможна только при вставке или удалении записей"

"да конечно, отсортируйте по ключу. Это абсолютно верно и необходимо и в РСУБД никакого оверхеда, которым тут запугивают, не произойдет,"

хорошо бы подкрепить ссылками на доки по конкретной СУБД.

AFAIK Для ряда редких случаев СУБД (SQL Lite, Paradox) и запросов без WHERE - оно может и верно, но в общем случае произвольного запроса - это не так.
...
Рейтинг: 0 / 0
31.08.2020, 17:03
| Ответить | Цитировать | Написать  
hibernate кто нибудь тестил когда оно помирает?
    #39994164
вадя
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
вадя
Участник
вариантов можно предложить несколько, но пока не будет ясно что и как обновляется - смысла предлагать нет.
интересует не конкретные значения а принцип и алгоритм данных
...
Рейтинг: 0 / 0
31.08.2020, 17:06
| Ответить | Цитировать | Написать  
25 сообщений из 92, страница 3 из 4
  3  все
Форумы / Java [игнор отключен] [закрыт для гостей] / hibernate кто нибудь тестил когда оно помирает?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=59&msg=39994063&tid=2120694]:
 0ms
get settings:
 25ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 47ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 500ms
get tp. blocked users:
 2ms
others: 302ms
total:  914ms
созд. / загр.: 914ms
x
x
Закрыть


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