Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
Господа, добрый вечер. Прошу дать совет Исходные данные есть таблица с логами Код: sql 1. 2. 3. 4. 5. 6. 7. 8. пока в ней пара десятков тестовых дынных, на бою ожидается их большой прирост есть запрос вида Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Предикаты можно поменять местами, составной индекс на таблице пока один - на полях id, ObjType Сторонние запросы к данной таблице используют лишь индекс описанный выше. Верным ли будет создать такой составной индекс или есть более приемлемые вариации? Код: sql 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2018, 17:10 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
шК0ДЕР, Код: sql 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.05.2018, 17:55 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
invm, благодарю! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 08:01 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
шК0ДЕР, Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 12:57 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийшК0ДЕР, Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page). это кто такое рекомендует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 13:02 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
TaPaK.ЕвгенийшК0ДЕР, Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page). это кто такое рекомендует? Это я такое рекомендую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 13:29 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.Евгений, нагруженные таблицы-то лучше не жать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 13:32 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов.Евгений, нагруженные таблицы-то лучше не жать. В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога. Копать глубже и рассматривать прирост нагрузки в разрезе ресурсов мне сейчас лень. Может, TaPaK соберет стенд и статистику выполнения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 13:53 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийВладислав Колосов.Евгений, нагруженные таблицы-то лучше не жать. В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога. Копать глубже и рассматривать прирост нагрузки в разрезе ресурсов мне сейчас лень. Может, TaPaK соберет стенд и статистику выполнения? зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:12 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
TaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:15 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичTaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память. и платим за всё это cpu ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:19 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
TaPaKГавриленко Сергей Алексеевичпропущено... Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память. и платим за всё это cpuНу так не у всех же дефицит CPU, а всего остального навалом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:37 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийВ большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает? Когда физически пишутся страницы данных/индексов в БД? Код: sql 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. Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 14:52 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
invm.ЕвгенийВ большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает? Я говорил про пользовательское логирование (шК0ДЕР - "...есть таблица с логами..."). Либо вы несколько поспешили, либо я выразился недостаточно определенно - выбирайте любой вариант. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 15:06 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичTaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.Что то я тоже разочаровался в сжатии. Самое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофически. Использую только ради места на дисках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 15:36 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvgСамое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофическиОсобенно BULK - получить вместо 500 гб/с только 5 - это само собой, бай дизайн. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 15:38 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийЯ говорил про пользовательское логированиеТем более. А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 17:07 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
invm.ЕвгенийЯ говорил про пользовательское логированиеТем более. А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов". Подчеркну специально для вас: моя рекомендация относилась к большинству случаев возможных вариантов использования логирования, описанного в первом сообщении. И добавлю: прежде всего к тем вариантам, которые мне кажутся естественными, типичными и ожидаемыми для пользовательского логирования. Разумеется, можно придумать ситуации и наборы данных, когда сжатие практически не даст положительного эффекта, зато проявит все отрицательные. Например, когда вся деятельность системы шК0ДЕР-а будет заключаться в пакетной вставке почти не повторяющихся данных (в рамках страницы) в таблицу лога, запросам к ней, и ничего сверх того. Но я не ставил себе задачей подобное фантазирование и считаю свою оговорку про большинство случаев вполне достаточной. Наконец, мне показалось, что вы захотели обосновать мою некомпетентность в теме сжатия данных MS SQL единственной, хотя и очень веской фразой "Тем более". Извините, но я не смог увидеть в ней ничего похожего на аргументацию даже при максимальной снисходительности. Я допускаю, что вы можете считать нецелесообразным сжатие таблицы логирования в большинстве типичных случаев, но мне это не мешает. Некоторые наши современники даже верят в плоскую Землю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 18:58 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийНаконец, мне показалось, что вы захотели обосновать мою некомпетентностьОбычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 20:02 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.Евгенийсчитаю свою оговорку про большинство случаев вполне достаточнойНе знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время. Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 20:48 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
invm.ЕвгенийНаконец, мне показалось, что вы захотели обосновать мою некомпетентностьОбычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень. Эта тема была открыта для получения советов (и я дал таковой), а не для демонстрации доказательств моей компетентности всем желающим и нежелающим, равно как и не для наездов. Вам не лень замусоривать чужую тему "эффективными менеджерами" и т.п оффтопными наездами? alexeyvg.Евгенийсчитаю свою оговорку про большинство случаев вполне достаточнойНе знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время. Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога." Я бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс. Миллионы строк? Но главнее другое - отмечена важность быстрого чтения лога. Теперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяется. Во-вторых, оно неразрывно связано с действием, ресурсозатратным относительно логирования и не должно его значимо замедлять. Приняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 21:34 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийЯ бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не малВажно, будет ли профит от использования сжатия в виде уменьшения стоимости хранилища. Если храним мало, то стоимость низкая, и этот + сжатия можно не учитывать. .ЕвгенийВажен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме. .ЕвгенийТеперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяетсяСамо собой, это был просто крик души про сжатие :-) .ЕвгенийПриняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования. .ЕвгенийНо главнее другое - отмечена важность быстрого чтения лога.Отмечена необходимость быстрого выполнения запроса на выборку. Про "соотношение чтения и записи" автор не говорил, возможно, оно такое же, как в типичных системах - на миллион запросов на вставку один запрос на чтение. Вам "лень", вы советуете "собрать стенд", но даже не потрудились спросить у ТС об этом. И тем более непонятно выглядит "в большинстве случаев". Сколько видел систем, всегда чтение из логов происходит по письму больших начальников при разборках "кто виноват", "а я этого не вводила", "откуда тут НДС?", раз в месяц. А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 22:25 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvg.ЕвгенийВажен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме. Да что вы говорите?! А затраты на чтение сжатого и несжатого индекса не имеют какого-либо отношения к оптимальности (в случае, когда он занимает несколько страниц)? Как же он оптимален, если его читать дольше? alexeyvg.ЕвгенийНо главнее другое - отмечена важность быстрого чтения лога.Отмечена необходимость быстрого выполнения запроса на выборку. Про "соотношение чтения и записи" автор не говорил... Перечитайте мою фразу и заметьте - я тоже про него не говорил! Возможно, что лог читается раз в сутки. Однако оптимизируют именно это единственное (или не единственное) чтение, а не запись. Отмечу, что шК0ДЕР не делал оговорки относительно границы допустимого торможения записи в лог. Ну и? alexeyvgЯ лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования. Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL. alexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем". 10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 23:18 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
.ЕвгенийalexeyvgЯ лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования. Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.Ок, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы. Однако соотношение всё таки не 20000:1, как у вас. .ЕвгенийalexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем". 10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.Видимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства. .Евгений10 000 * 86 400 секунд = практически неуправляемая таблицаДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли? Нормально всё "управляется", не такая большая таблица, хранить можно столько, сколько скажет бизнес, технических ограничений тут нет, соответственно, в таких случаях это решает бизнес, а не технический специалист. Впрочем, если хранить такой лог, например, год, тогда уже можно подумать о сжатии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.05.2018, 23:36 |
|
||
|
Правильное создание индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvgОк, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы. Однако соотношение всё таки не 20000:1, как у вас. Тогда взгляните на это с другой стороны. Сопоставимая нагрузка действий и их логирования означает, что оптимизация последнего посредством исключения избыточных сведений означает соответствующий рост производительности системы. Утрируя, на одном и том же оборудовании одновременно обслуживается тысяча клиентов с полным логированием, или две тысячи - с сокращенным. А то и больше. Или бизнесу неведомо, что такое стоимость владения? alexeyvgВидимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства. Любопытство или хулиганство здесь не при чем. Хороший лог обеспечивает легкую и удобную локализацию любой мнимой или реальной проблемы с данными или производительностью. Кому-то не нравится цифра, результат действий или время реакции - лог покажет, кем, какие и когда элементы системы (хп, задачи и т.п.) были запущены, с какими аргументами и в какой последовательности, свяжет их с интерфейсом или конкретными процессами. В подавляющем большинстве случаев этого достаточно для воспроизведения и дальнейшего анализа проблемы. Дальнейшая детализация в логе возможна только по отдельному запросу. Так я делал сам, такой же подход видел в чужих системах, с которыми приходилось работать. alexeyvgДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли? Потому что с таблицей в миллиарды записей и более нельзя произвести ad-hoc действия за разумное время. Ходить можно только по дорожкам индексов, сошел с них - сиди и жди. Можешь час ждать, можешь более. Да и индексы не панацея - уровней больше, бегать дольше. Неуправляемую глыбу можно послать в оперативу, кубы или какую-нибудь бигдатую систему, но зачем? Надо просто взять и отсечь лишнее - 99 и 9 в периоде процентов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2018, 00:28 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39645849&tid=1689679]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
45ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 232ms |
| total: | 354ms |

| 0 / 0 |
