|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
ViPRosваша решение тожебессмысленно Спасибо за ваше мнение, оно очень важно для меня, но мнение заказчика для меня важнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2015, 09:52 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
Sergueiно мнение заказчика для меня важнее. заказчик часто несет ахинею, поэтому нужно уметь его переубеждать. Если все делать в точности как хочет заказчик, то обычно получается говнософт. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.10.2015, 11:38 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
kdvДохтаРНа месте архитектора я бы такой функционал в продуктив не пустил бы. почитайте про "системы реального времени". Есть "мягкие" и "жесткие". Для "жестких" " Ситуация, в которой обработка событий происходит за время, большее предусмотренного, в системе жёсткого реального времени считается фатальной ошибкой. " Допустим, приложению нужен ответ на запрос в течение 1 секунды. Через 2 секунды результат запроса уже нафиг не будет нужен. Поэтому через 2 секунды запрос уже можно отрубать. А если такого ограничения нет, то запрос может выполняться и 3 и более секунд, что приведет к общему уменьшению отклика системы, что сделает неактуальным и ДРУГИЕ запросы. Так что при наличии данного требования (ограничения запросов по времени), и его отсутствия в реализации, система при определенной нагрузке просто встанет раком. Я в курсе, мне из оракла приходилось делать подобие системы реального времени , валидировать планы по гарантированному количесту иопсов не более чем, играться с размещением размерами блоков управлением экстентами в табличных пространствах , разбрасывать БД шпинделям где у каждой группы шпинделей свой кеш. Выделять отдельные шпиндели и отдельный кеш стораджа под редологи, так что бы в кеше помещалось минимум 2 редолога и никто их оттуда ни прикаких обстоятельствах не выбивал. СУБД не так умны как кажется, ограничения в секундах ничего не решают. Что бы из СУБД сделать настоящую систему реального времени она должна быть частью ядра ОС, а влиялющие друг на друга фоновые процессы дбрайтеры, лограйтеры , бекапы не оказывалия влияния на латентность работы с пользователями. Фоновое процессы БД наступающие друг другу и пользователям на хвосты по ресурсам вносят самую большую непредсказуемость в латентность работы БД с пользователями. Директивно на уровне опции к запросу такие вопросы не решаются. Ваши интерпретация хотелки ТС мне напоминает анекдот про прапорщика: Поезд, стой ! , рас два. А вобще он другое хочет, декларативно ткнуть в запрос пальцем и непредсказуемо терять в нем констистентность выборки. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2015, 10:36 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
Что бы построить что то похожее на систему реального времени из СУБД, группе адекватных сисадминов из минимум 3 человек знания которых дополняют друг друга в областях архитеркуры БД, стораджей, сетей, инфраструктуры ЦОД, бизнес логики приложения, мониторинга, выдать длинные линейки , и выдать картбланш на применение линеек по пальцам нарушающих установленные ими правила игры, не взирая на занимаемые должности. С техникой и ПО все ясно и предсказуемо, самое интересное начинается когда бизнес интересы начинают вступать в конфликт интересов и противоречия с SLA. Сама по себе система реального времени в вакуме не нужна, она должна уметь адаптироваться под бизнес, который оплачивает ее существавание. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2015, 11:02 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
ДохтаР, Насколько я понимаю, ТС и не просил СУБД реального времени (что бы это ни означало). Его хотелку я бы интерпретировал так: за указанное время СУБД должна вернуть один из четырех ответов: вот данные, и это все данные; вот данные, и, возможно, есть еще; данные не найдены, но, возможно, есть; данных точно нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2015, 15:42 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
ЫДохтаР, Насколько я понимаю, ТС и не просил СУБД реального времени (что бы это ни означало). Его хотелку я бы интерпретировал так: за указанное время СУБД должна вернуть один из четырех ответов: вот данные, и это все данные; вот данные, и, возможно, есть еще; данные не найдены, но, возможно , есть; данных точно нет. Я ничего не говрил по поводу систем реального времени , пока kdv не начал меня в чем то убеждать. Поставленный ТС впрос, не есть вопросом для серьезного технического обсуждения как добиться такой то гарантированной латентности, при таких то условиях. Это аналог вопроса из делфи форума , подскажите существует ли такой компонент, что бы нажать на кнопку и получить результат. Я ответил , что в системе такой компонент потенциально вносить неопределенность в поведение при эксплуатации и в продуктив я бы этот функционал не тащил бы. . ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2015, 18:10 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
ЫДохтаР, Насколько я понимаю, ТС и не просил СУБД реального времени (что бы это ни означало). Его хотелку я бы интерпретировал так: за указанное время СУБД должна вернуть один из четырех ответов: вот данные, и это все данные; вот данные, и, возможно, есть еще; данные не найдены, но, возможно, есть; данных точно нет. 1 флаг ["фетч прерван"] и данные[их отсутствие] кроют ваш список как бык овцу. можно эмулировать как declare + fetch next в асинхронном режиме со снятием. нужно ли -- вопрос. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.10.2015, 19:00 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
этта1 флаг ["фетч прерван"] и данные[их отсутствие] кроют ваш список как бык овцу. Ваш «бык» — лишь детали реализации, по смыслу он не отличим от моего списка. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.10.2015, 01:12 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
Недокументированный параметр _query_execution_time_limit в Oracle с 12.1.0.2: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
11.02.2016, 02:29 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
[quot]СУБД с возможностью указать сколько секунд делать выборку Первое что пришло в голову по названию темы - Аппарат событий (стр. 70) в ЛИНТЕР. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.02.2016, 13:28 |
|
СУБД с возможностью указать сколько секунд делать выборку
|
|||
---|---|---|---|
#18+
JDSsoftwarerВ общем случае очевидно неработоспособен. Впрочем, учитывая, что такой проект вообще неработоспособен, разница небольшая. Проверил ради интереса (правда таймаут маленький)): Код: plsql 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. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140.
И как только начал, сразу понял, что это не совсем корректно - запрос в лупе-то кто будет отсекать? А здесь получается только фетч и то похоже, что не корректно отсекается - во всяком случае на клиенте выйти точно на указанное время будет почти нереально ) В общем конечно не вариант. mikron, правильно вспомнил, параметр есть вроде как. В этом примере надо использовать не RAISE_APPLICATION_ERROR, а RAISE NO_DATA_NEEDED. Но с постановкой задачи все равно есть проблемы. Делать то, что хочет автор, нужно по-другому ... |
|||
:
Нравится:
Не нравится:
|
|||
24.02.2016, 04:23 |
|
|
start [/forum/topic.php?fid=35&msg=39075923&tid=1552289]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
others: | 287ms |
total: | 550ms |
0 / 0 |