|
|
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
FB 2.5. База FW=OFF В одной таблице 4 477 968 записей. нужно перекачать их в соседнюю таблицу похожей структуры. Решил проверить будет ли быстрее работа на ramdisk. Оказалось что на ramdisk экономия всего 24%. CREATE TABLE RCP_RAW_QLT ( RCPREP_ID ID, QLT_ID ID, QLT_VAL REAL_WNULL, VALUE_IN_DM REAL_WNULL, VALUE_NATIVE REAL_WNULL, VALUE_PREMIX REAL_WNULL, CONSTRAINT PK_RCP_RAW_QLT PRIMARY KEY (RCPREP_ID, QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_QLT_ID FOREIGN KEY (QLT_ID) REFERENCES QM_DICT (QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_RCPREP_ID FOREIGN KEY (RCPREP_ID) REFERENCES RCPREP (RCPREP_ID) ON DELETE CASCADE ); запрос insert into RCP_RAW_QLT (RCPREP_ID, QLT_ID, QLT_VAL, VALUE_NATIVE, VALUE_PREMIX) select RR.RCPREP_ID, RQ.QLT_ID, RQ.QLT_VAL, RQ.VALUE_NATIVE, RQ.VALUE_PREMIX from RCPREP RR join RCPRQLT RQ on RR.RCP_ID = RQ.RCP_ID and RR.RAW_ID = RQ.RAW_ID; RAM 2.23 минуты Query Time ------------------------------------------------ Prepare : 16,00 ms Execute : 142 195,00 ms Avg fetch time: 0,00 ms Memory ------------------------------------------------ Current: 262 186 112 Max : 264 527 168 Buffers: 60 480 Operations ------------------------------------------------ Read : 85 882 Writes : 135 689 Fetches: 136 491 901 Marks : 18 418 925 HDD 2.56 минуты Query Time ------------------------------------------------ Prepare : 16,00 ms Execute : 176 749,00 ms Avg fetch time: 0,00 ms Memory ------------------------------------------------ Current: 262 186 956 Max : 264 528 436 Buffers: 60 480 Operations ------------------------------------------------ Read : 85 881 Writes : 270 810 Fetches: 136 491 901 Marks : 18 486 521 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 13:56:35 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77CREATE TABLE RCP_RAW_QLT ( RCPREP_ID ID, QLT_ID ID, QLT_VAL REAL_WNULL, VALUE_IN_DM REAL_WNULL, VALUE_NATIVE REAL_WNULL, VALUE_PREMIX REAL_WNULL, CONSTRAINT PK_RCP_RAW_QLT PRIMARY KEY (RCPREP_ID, QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_QLT_ID FOREIGN KEY (QLT_ID) REFERENCES QM_DICT (QLT_ID), CONSTRAINT FK_RCP_RAW_QLT_RCPREP_ID FOREIGN KEY (RCPREP_ID) REFERENCES RCPREP (RCPREP_ID) ON DELETE CASCADE );Констрейнты на target-таблице можете временно drop, а после инсертов add ? если да, то попробуйте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 14:18:47 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
PS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 14:25:19 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидPS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. Спасибо за рекомендации. Но вопрос у меня чисто риторический. Задача не практическая, а тестовая. Почему выигрыш ramdiska на данной операции всего 25%. TempDir кстати тоже на ramdisk. Я ожидал большего. Получается в этой задаче мы упираемся в производительность самого сервера (чисто процессорная задача). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:08:17 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидPS. Если констрейнты на target-таблице заглушать нельзя, покажите значение параметра TempCacheLimit. Судя по PK = (RCPREP _ID , QLT _ID ), для создания этого индекса "внутри" TempCacheLimit'a надо установить его не менее 4500000 * (20 + 4 +4 ) = ~126 Mb. Спасибо за рекомендации. Но вопрос у меня чисто риторический. Задача не практическая, а тестовая. Почему выигрыш ramdiska на данной операции всего 25%. TempDir кстати тоже на ramdisk. Я ожидал большего. Получается в этой задаче мы упираемся в производительность самого сервера (чисто процессорная задача).Вы не показали свой TempCacheLimit. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:17:09 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидВы не показали свой TempCacheLimit. Стандартный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:20:22 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидВы не показали свой TempCacheLimit. Стандартный. Кстати при чем тут TempCacheLimit если и база и TempDir находятся на ramdiske ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:22:26 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидВы не показали свой TempCacheLimit. Сделал TempCacheLimit 250 Мб. Ничего не поменялось Время 2:21. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:31:30 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77ТаблоидВы не показали свой TempCacheLimit. Сделал TempCacheLimit 250 Мб. Ничего не поменялось Время 2:21. А загрузка ядра процессора какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:32:17 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77Стандартный.Он разный для SS (64 М) vs SC/CS (8M). bazilio77Кстати при чем тут TempCacheLimit если и база и TempDir находятся на ramdiskeКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. В виндузе это видно просмотром соотв. каталога, в линухе - командой lsof -a +L1 <temp_folder_mount_point>: там появляются и растут времянки. Ну так вот: даже если параметр TempDirs указывает на ram-диск, обмен между "внутренней" памятью, которая была зарезервирована под TCL, и "наружней", настолько затратен, что там почти без разницы, жесткий это диск или ram. Совсем недавно я напоролся как раз на это, вот тынц . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:34:41 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77Почему выигрыш ramdiska на данной операции всего 25% потому что FW=OFF ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:39:32 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. вот любишь ты по результатам пары экспериментов обобщенные выводы делать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:40:32 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrТаблоидКогда движку не хватает TempCacheLimit, он начинает выталкивать данные на диск, в каталог, заданный параметром TempDirs. ДАЖЕ ЕСЛИ В СИСТЕМЕ ЕЩЕ ПОЛНО ПАМЯТИ. вот любишь ты по результатам пары экспериментов обобщенные выводы делать...Но ведь ФБ не будет оттяпывать себе еще памяти под темпспейс, если TCL исчерпан ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:45:10 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, не будет. Но пишет он в кеш файловой системы, так что СВОБОДНАЯ ПАМЯТЬ В СИСТЕМЕ ТАКИ БУДЕТ ИСПОЛЬЗОВАТЬСЯ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 18:55:28 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrне будет. Но пишет он в кеш файловой системы, так что СВОБОДНАЯ ПАМЯТЬ В СИСТЕМЕ ТАКИ БУДЕТ ИСПОЛЬЗОВАТЬСЯ.да, но я *сразу* после старта видел fb_* файлы в tempfs или в /tmp (когда TCL был мал) - это что получается, сама операционка их начинала записывать ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 19:00:07 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоидда, но я *сразу* после старта видел fb_* файлы в tempfs или в /tmp (когда TCL был мал) - это что получается, сама операционка их начинала записывать ? они создаются сразу по исчерпании TCL, с нулевым размером. А вот писать туда ось начинает отнюдь не сразу. И уж тем более читает из своего кеша, а не с диска. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 19:06:50 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Резюме: FW=OFF при достаточном кэше нисколько не проигравыет ramdisk. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 21:13:23 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77, во-первых, только при установленных в -1 параметрах MaxUnflushed* в конфиге. Во-вторых, все-таки проигрывает, пусть и немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2014, 22:13:14 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrвсе-таки проигрывает, пусть и немного.на линухе при следующих изменённых параметрах конфига (NB: DefaultDBCachePages = 2048; арх-ра = SuperClassic; версия = LI-T3.0.0.30876): Код: plaintext 1. 2. 3. 4. - и вставке 5 млн строк в таблицу c последующим их удалением, картина следующая: DDL: Код: 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. log Код: 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. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. log Код: 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. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. Вставки выигрывают примерно на 16%. Удаления и подсчет числа записей, как видно, остались одинаковыми. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 01:38:38 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
0xFF. Когда вставка идёт в индексированную GTT, то было бы круто обновлять её индексы НЕ на каждой записи, а после окончания обработки "входного потока". Т.е. пока идёт заливка строк с 1-ой по 100499-ю - плевать на индексы, оставляем их в "несоответствующем" (новым данным) виде. /* Роллбак посередине случился - тем лучше, меньше откатывать надо (для gtt on commit preserve rows). Авария хоста - вообще по барабану, GTT и не должны при этом ничего сохранять. */ Когда же заканчивается добавление 100500-ой строки - обновляем все индексы на основе новых данных. Есть смутное сомнение, что так будет быстрее, чем сейчас. Да, я помню прекрасно, что "в GTT сделано почти всё также, как в fixed-таблицах", ибо времени было в обрез и проч. Это я просто высказал идею на будущее, чтобы в воздухе не растворилась... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 01:48:24 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидКогда вставка идёт в индексированную GTT, то было бы круто обновлять её индексы НЕ на каждой записи, а после окончания обработки "входного потока". Т.е. пока идёт заливка строк с 1-ой по 100499-ю - плевать на индексы, оставляем их в "несоответствующем" (новым данным) виде.А что такое "входной поток" ? Где он начинается и где заканчивается ? И где найти ключи от всего только что вставленного "потока" ? Перечитывать 100500 записей ? Или копить всё в (резиновой) памяти по ходу вставок ? За контроль уникальности я даже не заикаюсь. При чём тут вообще GTT\не GTT ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 02:30:53 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, насколько я в курсе, сейчас можно либо обновить один ключ, либо построить все ключи по всем записям, и пофиг это ГТТ или нет. для "отложенного до-индексирования" все равно пришлось бы целиком сканировать таблицу, проверяя, есть уже такие ключи, или нет. Хотя, по идее, "достроить" ключи быстрее, чем целиком перестроить весь индекс. Но такого механизма все равно (пока) нет. И он достаточно опасен. Например, в таблицу с 10 млн записей добавляем 1000 записей с "отложенным индексированием". В результате придется потом прочитать все 10млн записей, да еще и 10млн индексных чтений сделать. Так что спорная штука. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 02:33:05 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladА что такое "входной поток" ? Где он начинается и где заканчивается ?эммм... ну вот когда движок начинает делать вот такое: Код: sql 1. - то разве он не "чувствует", когда заканчиваются данные из источника ? Трейс же имеет ключик log_statement_finish - он же "видит" каким-то образом этот самый "финиш"... hvladИ где найти ключи от всего только что вставленного "потока" ? Перечитывать 100500 записей ? Или копить всё в (резиновой) памяти по ходу вставок ?Даже если перечитывать (тест см ниже), будет ощутимый выигрыш. А если накапливать в памяти, так еще больше. Ибо чтобы исчерпать современные 16/32/64 Гб - это постараться надо. К тому же, накапливая ключи в памяти, можно "на ходу" понять, хватит ли имеющейся памяти или нет и прекратить это накопление, выполенив в итоге простое перечитывание. hvladЗа контроль уникальности я даже не заикаюсь.Я вёл речь только об insert'ах; delete & update тоже сюда подойдут. Merge - нет, тут безусловно надо контролировать сразу для каждой записи. Если же прога написана так, что делает insert'ы недопустимых дубликатов - разраб ССЗБ, пусть переписывает на merge. hvladПри чём тут вообще GTT\не GTT ???При том, что на них: 1) должен получиться наибольший выигрыш, т.к. их данные хранятся в /dev/shm (если настроить TempDirs как надо), там выключены careful writes; 2) в случае реализации такой фичи всякие ошибки (алгоритма этой реализации) будут менее болезненными. Ибо времянки. Результат теста предсказуем и не интересен, но пусть будет как аргумент. variant #1. Создаем GTT, напихиваем в неё данные (5 млн строк), а затем перечитываем её всю для построения индексов:] perfins_deferred_index_rebuild.sql Код: 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. 133 + 33 = 266 sec Код: 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. variant #2 . Создаем GTT и к ней сразу - те же самые индексы. Заливаем данные, заставляя движок обновлять на каждой записи 4 индекса: perfins_immediate_index_updating.sql Код: 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. 472 sec Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:13:13 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
kdvв таблицу с 10 млн записей добавляем 1000 записей с "отложенным индексированием". В результате придется потом прочитать все 10млн записей, да еще и 10млн индексных чтений сделать. Так что спорная штука.в идеале было бы накапливать добавленные ключики в памяти. Сейчас век дешёвых гига/терабайтов, времена поменялись уже лет 10 как бэ... :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:14:41 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, времена поменялись, сервера уже давно многопользовательские, а ты все оптимизируешь исключительно для себя любимого. Выкинет твой волшебный инсерт все конкурентные сортировки в своп и придут по твою душу злые клиенты и/или админы. Будешь им рассказывать про новые времена и свой подход к дешевым гигабайтам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:24:15 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrВыкинет твой волшебный инсерт все конкурентные сортировки в своп и придут по твою душу злые клиенты и/или админы. Будешь им рассказывать про новые времена и свой подход к дешевым гигабайтам.Они и так придут, если я не выставлю адекватный TempCacheLimit, а не эти нищебродские 64 Мб :-) И, кстати: а ведь можно ввести такой параметр, как максимальная квота использования TempSpace одним аттачем ? Тогда ко мне в комнату точно никто не придёт с б/битой. Кажеццо... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:29:52 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladЗа контроль уникальности я даже не заикаюсь.Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ? ТаблоидЕсли же прога написана так, что делает insert'ы недопустимых дубликатов - разраб ССЗБ, пусть переписывает на merge.Так и сделаем - введём новый код ошибки isc_app_dev_is_a_fool и будем её возвращать. Всегда. ТаблоидРезультат теста предсказуем и не интересен, но пусть будет как аргумент.С этим у тебя всегда проблемы. Твой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки). И вернёмся к начальному вопросу: ТаблоидhvladА что такое "входной поток" ? Где он начинается и где заканчивается ?эммм... ну вот когда движок начинает делать вот такое: Код: sql 1. - то разве он не "чувствует", когда заканчиваются данные из источника ?А теперь найди этот вот Код: sql 1. в своём предсказуемом и не интересном (полностью согласен!) тесте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:32:15 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, отложенные индексы - бред. Я ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 13:45:40 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидпропущено...Я вёл речь только об insert'ахА их что - не надо контролировать ? А что делать параллельным коннектам, которые тоже что-то вставляют ?куда, в GTT ? (разговор только о времянках!) hvladТвой тест не отражает реальности. Ибо при построении индекса применяется совсем не дакой алгоритм, как при добавлении ключей в индекс (пусти и пачки).я знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ? hvladА теперь найди этот вот Код: sql 1. в своём предсказуемом и не интересном (полностью согласен!) тестекогда insert-команда содержит values(), то ясен пень, что тут нет окончания "входного потока". Этот пример был просто скопипастен с другого, с минимальными изменениями. Речь идёт именно о случае, когда есть многострочный "источник" данных. 3.2 млн строк, deferred index rebuild: 96 + 21 = 117 сек Код: 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. 3.2 млн строк, immediate index update: 285 sec Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. PS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу. А также (как минимум с 11.1.0) - deferred index maintenance - судя по тексту, это как раз то самое , "с ключиками в памяти". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:08:27 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денисотложенные индексы - бред.Обоснуй. Симонов ДенисЯ ещё понимаю если бы ты отложенных FK требовал. И чего ты так к этим GTT доматался? Если ты их используешь только для оптимизации выборок, то может лучше просить фич оптимизатора?Использую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении. Но GTT'шки юзаются не только для ускорения джойнов. Например, загрузить из файла прайс-лист поставщика с предпросмотром его перед окончательным импортом. Там может быть 1...2 млн строк (речь о запчастях), юзера могут выполнять в нём поиск, всякие модификации цен, скидочных категорий и проч. Джойнов тут нет вообще. Надо просто загрузить его побыстрее и проиндексировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:13:25 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидPS. у Cтаршего Брата много лет существует deferred constraints , проверяемые при commit'e транзакции (даже не по окончаниии стейтмента). Сильно подозреваю, что индексы, которыми обеспечиваются эти самые deferred-констрейнты (UK/FK), также обновляются в самом заду, не сразу. с чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия. Что касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:29:08 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values. Array DML было бы эффективнее. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:31:58 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид(разговор только о времянках!)Это ты так думаешь Таблоидя знаю, что там всё по-другому; но сравнить, хотя бы с точностью два лаптя, - как еще ?Ты делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики Таблоиду Cтаршего Брата много лет существуетЯ знаю. Но у него много чего ещё существует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:39:28 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денисс чего ты взял, что deferred constraints будут работать быстрее чем построчные? Да и применяются они не для скорости, а именно чтобы отложить проверку, что как бы следует из названия.я знаю, что они для откладывания проверки. Скорость не сравнивал, в лом. А второй ссылки, про deferred index maintenance, разве не достаточно, чтобы просто обратить внимание на это ? Симонов ДенисЧто касается ускорения загрузки (insert), то тут лучше бы ты просил bulk insert. По-моему даже в трекере где-то есть insert со множественным values.а что ты вкладываешь в эту фразу, bulk insert ? что при этом должно/ не должно происходить ? ЗЫ. тикета не вижу; есть только фикс регресса, недавний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:40:49 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, ну или это Таблоид, подозреваю что вот это deferred constraints требует блокировки. Да и часто ли ты их применял в ORA. Лично я вижу их пользу только для отложенных FK, да и то только для случая когда в таблицу запихивается древовидная структура и не возможно вставить какую либо запись до вставки её родителя. В остальных случаях порядок вставки всегда можно определить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:41:38 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? при отсутствии чего-то типа "обнови индекс только по добавленным строкам" ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:44:04 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денис CORE-1978 как по мне так это часть CORE-3880 Это не bulk insert, а именно "конструктор" с заранее известными числами внутри values(). Просто что бы не ходить на поклон к rdb$database. Индексы по-прежнему будут обновляться для каждой добавляемой записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:47:56 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоид, я тут только об уменьшении кол-ва round-trip на массовых вставках и это полезно не только для GTT. Про индексы я тут не говорил. Что касается именно отложенных констрейнов, то тебе уже говорили, что если и делать, то для всех таблиц, а не только для GTT. А это куда сложнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:51:55 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидhvladТы делаешь утверждения - ты их обосновываешь. Пока что твои обоснования не выдерживают критики.ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:53:21 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
hvladТаблоидпропущено...ну, а как еще сравнивать-то ? Проблемы индейцев ... (ц)дежурно-казённая отговорка :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 14:58:26 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
ТаблоидИспользую, и не я один. Запрос такой фичи оптимизатора (материализацию промежуточных результатов) делать не нужно, она есть вроде бы. По кр. мере, я точно знаю, что ДЕ в трёшке что-то делает (или почти сделал) в этом направлении. я тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач? Материализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:33:58 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Симонов Денися тоже в некоторых местах использую. Но это от бедности. Кстати разве оконные функции не покрывают 50% таких задач?ты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ? Симонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:41:09 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
Таблоидты про sum()over() и сравнение с ним значений в соседних столбах для последующего фильтра или про что ? да и не только. Жаль пока нету спецификации кадрирования. ТаблоидСимонов ДенисМатериализацию промежуточных результатов покроет ещё 15%. Правда есть у меня одна задачка в которой пока заменить GTT никак не удаётся.я видел её, но не вчитывался, по правде сказать. Надо будет глянуть как-нить. на самом деле там упрощённая формулировка, на самом деле там помимо коэффициента надо ещё вывести полную родословную с пометкой всех инбредных лошадей и раскрасить их разными цветами. Я пробовал на досуге решить это с помощью оконных функций, но до конца так и не добил. Да и работало оно медленней, чем с GTT. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 15:48:18 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
dimitrbazilio77, во-первых, только при установленных в -1 параметрах MaxUnflushed* в конфиге. Во-вторых, все-таки проигрывает, пусть и немного. Ви таки будете смеяться. Оказалось что на том диске где я проводил тесты оказалась включена компрессия NTFS. Выключил компрессию в каталоге где лежала БД и получил результат равный рамдиску или даже быстрее 2:17 vs 2.21 на рамдиске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 18:36:03 |
|
||
|
Еще раз о ramdisk
|
|||
|---|---|---|---|
|
#18+
bazilio77, а индексация ? :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.02.2014, 19:07:01 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1563883]: |
0ms |
get settings: |
6ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
181ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
80ms |
get tp. blocked users: |
1ms |
| others: | 186ms |
| total: | 484ms |

| 0 / 0 |
