|
|
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevAlexey TominНе сходится. Если из 2..6 часов чтение с диска занимает 10-15 минут, то что делает сервер остальное время? .... sanBez...это аццкий отжиг. Админа ораклового вам надо... поддерживаю sanBez. Запускать реальный код, смотреть на чем тормозит, _те_куски_ которые тормозят и оптимизировать. я же вроде подробно разложил? в чем проблема. у оракла своя сфера применения, я лучше чем кто-либо другой эту сферу знаю. проблема в том, что для такой задачи не нужен оракл. задачи не нужна его сложная структура блока, которая резервирует место на заголовок, блокировки и прочую дребедень. задачи не нужен навороченный оракловый оптимизатор, не нужно построчное хранение. почти ничего в чем силен оракл не нужно. я уже написал один раз, повторюсь, оптимизатор оракла применяет fullscan если запросу необходимо более 25% блоков и блоков нет в кеше. выходит, что показатель1 читает таблицу, показатель2 читает другую, вытесняет блоки первой, потом показатель3 снова вынужден читать с диска таблицу1. что и почему понятно. оптимизировать можно, можно увеличить размер блока, уменьшить кол-во слотов в блоке, расставить близкие показатели друг за другом. да этим наверно займемся, но сюда я пришел с другой задачей. у меня задача посмотреть на in-memory вариант и прокачать джава скилы. давайте на джава сосредоточимся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2015, 14:58 |
|
||
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
hck1я же вроде подробно разложил? в чем проблема. у оракла своя сфера применения, я лучше чем кто-либо другой эту сферу знаю. Весьма смелое заявление. hck1я уже написал один раз, повторюсь, оптимизатор оракла применяет fullscan если запросу необходимо более 25% блоков и блоков нет в кеше. выходит, что показатель1 читает таблицу, показатель2 читает другую, вытесняет блоки первой, потом показатель3 снова вынужден читать с диска таблицу1 Стоп. Если стран много (я так понял, больше десятка), а данные разных стран лежат в разных партициях, то не может быть, чтобы ради каждой страны поднималось более 25% строк таблицы. hck1но сюда я пришел с другой задачей. у меня задача посмотреть на in-memory вариант и прокачать джава скилы. давайте на джава сосредоточимся. Надо понимать, что никто не пришёл сюда ради помощи hck1. Кто-то мозги чешет интересными задачками, кто-то своё самолюбие. Так что на чём бы Вы не хотели сосредоточится- я всё одно не понимаю, почему вдруг java тут сильно ускорит дело... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2015, 15:23 |
|
||
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
Alexey TominСтоп. Если стран много (я так понял, больше десятка), а данные разных стран лежат в разных партициях, то не может быть, чтобы ради каждой страны поднималось более 25% строк таблицы. у SE редакции нет партиций. данные стран лежат в разных схемах и даже в разных таблеспейсах, я об этом упоминал тут hck1P.S. у каждой страны свой набор данных (даже таблеспейс) и свой набор показателей, обрабатываются страны независимо, часто параллельно. у стран схожи 70% таблиц, но не идентичны. где-то чуть шире таблички, где-то чуть меньше полей. размер полей у стран может быть разным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2015, 15:41 |
|
||
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
hck1Alexey TominСтоп. Если стран много (я так понял, больше десятка), а данные разных стран лежат в разных партициях, то не может быть, чтобы ради каждой страны поднималось более 25% строк таблицы. у SE редакции нет партиций. данные стран лежат в разных схемах и даже в разных таблеспейсах, я об этом упоминал тут hck1P.S. у каждой страны свой набор данных (даже таблеспейс) и свой набор показателей, обрабатываются страны независимо, часто параллельно. у стран схожи 70% таблиц, но не идентичны. где-то чуть шире таблички, где-то чуть меньше полей. размер полей у стран может быть разным. Но при этом hck1выходит, что показатель1 читает таблицу, показатель2 читает другую, вытесняет блоки первой, потом показатель3 снова вынужден читать с диска таблицу1 А! Понял. Страны-то разные, но "показатели" читают одно и то же. Тогда sql должен читать таблицу1 и собирать его сразу в несколько агрегатов. Скорее всего в готовые показатели это не соберётся, но это не беда- собрать во временную таблицу (небольшую) и из неё- в показатели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2015, 16:52 |
|
||
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
да, что-то мои расчеты на компактность объектов жава в сравнению с субд совсем не оправдываются. я сгенерил с помощью NetBeans классы из базы данных для хибера. заменил LAZY на EAGER, запустил с такими параметрами -XX:MaxHeapSize=11g -XX:PermSize=256m. вылетело так Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: java 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. запускал профайлер от NetBeans, выглядит что вся проблема в том, что ресурсы уходят на работу GC. сейчас попробовал отключить L2 кеш у хибера, подозреваю если и поможет, то не принципиально. может я что-то делаю принципиально не так ? и второй вопрос, я верно понимаю, что с EAGER хибернейт не будет долбить в цикле запросы, как это я наблюдаю с LAZY. будет один большой запрос или так и продолжит долбить в цикле на каждого Customer запросом для Bookings ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.04.2015, 16:52 |
|
||
|
hibernate и in memory calc
|
|||
|---|---|---|---|
|
#18+
наверно я понял почему мой фокус не удался. java ведь при инициализации объекта резервирует память на тот размер, какой продефинирован в классе, а в оракле данные хранятся более компактно. если в оракловом Number(12) храниться 0, то это всего 2 байта на диске, в то время как в Java объекте у меня заняло 32-бит (BigDecimal). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.04.2015, 10:59 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38903980&tid=2125527]: |
0ms |
get settings: |
6ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
77ms |
get topic data: |
6ms |
get forum data: |
1ms |
get page messages: |
27ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 370ms |

| 0 / 0 |
