Гавриленко Сергей АлексеевичTaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.Что то я тоже разочаровался в сжатии. Самое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофически. Использую только ради места на дисках.

alexeyvgСамое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофическиОсобенно BULK - получить вместо 500 гб/с только 5 - это само собой, бай дизайн.

.Евгенийсчитаю свою оговорку про большинство случаев вполне достаточнойНе знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время.
Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога."

.ЕвгенийЯ бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не малВажно, будет ли профит от использования сжатия в виде уменьшения стоимости хранилища. Если храним мало, то стоимость низкая, и этот + сжатия можно не учитывать.
.ЕвгенийВажен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме.
.ЕвгенийТеперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяетсяСамо собой, это был просто крик души про сжатие :-)
.ЕвгенийПриняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
.ЕвгенийНо главнее другое - отмечена важность быстрого чтения лога.Отмечена необходимость быстрого выполнения запроса на выборку.
Про "соотношение чтения и записи" автор не говорил, возможно, оно такое же, как в типичных системах - на миллион запросов на вставку один запрос на чтение.
Вам "лень", вы советуете "собрать стенд", но даже не потрудились спросить у ТС об этом.
И тем более непонятно выглядит "в большинстве случаев".
Сколько видел систем, всегда чтение из логов происходит по письму больших начальников при разборках "кто виноват", "а я этого не вводила", "откуда тут НДС?", раз в месяц. А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".

.ЕвгенийalexeyvgЯ лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.Ок, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы.
Однако соотношение всё таки не 20000:1, как у вас.

.ЕвгенийalexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.Видимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.
.Евгений10 000 * 86 400 секунд = практически неуправляемая таблицаДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?
Нормально всё "управляется", не такая большая таблица, хранить можно столько, сколько скажет бизнес, технических ограничений тут нет, соответственно, в таких случаях это решает бизнес, а не технический специалист. Впрочем, если хранить такой лог, например, год, тогда уже можно подумать о сжатии.

.ЕвгенийalexeyvgВидимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.
Любопытство или хулиганство здесь не при чем. Хороший лог обеспечивает легкую и удобную локализацию любой мнимой или реальной проблемы с данными или производительностью. Кому-то не нравится цифра, результат действий или время реакции - лог покажет, кем, какие и когда элементы системы (хп, задачи и т.п.) были запущены, с какими аргументами и в какой последовательности, свяжет их с интерфейсом или конкретными процессами. В подавляющем большинстве случаев этого достаточно для воспроизведения и дальнейшего анализа проблемы. Дальнейшая детализация в логе возможна только по отдельному запросу. Так я делал сам, такой же подход видел в чужих системах, с которыми приходилось работать.Именно. Так почему тогда вы писали:
.ЕвгенийalexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.?
Это оно и есть - "редкие чтения для исследование проблем", а не "читается чаще, чем пишется".

.ЕвгенийalexeyvgДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?
Потому что с таблицей в миллиарды записей и более нельзя произвести ad-hoc действия за разумное время. Ходить можно только по дорожкам индексов, сошел с них - сиди и жди. Можешь час ждать, можешь более. Да и индексы не панацея - уровней больше, бегать дольше. Неуправляемую глыбу можно послать в оперативу, кубы или какую-нибудь бигдатую систему, но зачем? Надо просто взять и отсечь лишнее - 99 и 9 в периоде процентов.Повторю за TaPaK - "синее и мягкое".
"Исследование проблем" абсолютно не связано с временем хранения. Даже если храним сотню петабайт лога за годы, это не на миллисекунду не замедлит эти самые "ad-hoc действия" с этим логом, по сравнению с хранением одних суток. Ну, может, как раз на миллисекунду замедлит, прочитать пару лишних страниц индекса.
"Сходить с дорожки индекса" не надо, как минимум должен быть индекс по времени (в том или ином виде, например, у ТС для этого есть ID), что делает нагрузку при изучении лога независимой от его размера.

.ЕвгенийalexeyvgЭто оно и есть - "редкие чтения для исследование проблем", а не "читается чаще, чем пишется".
Я не понимаю, о чем вы говорите. Кто сказал "читается чаще, чем пишется", кому вы возражаете? Мне указанную фразу приписывать не надо. Я могу считать желательным более активное использование просмотра лога, нежели раз в сутки, но не надо доводить мое мнение до полного абсурда.Вы советуете решение, которое замедлит работу системы.
Для того, что бы выполняемый раз в неделю (несколько раз в день) разработчиками в целях отладки запрос выполнялся на n процентов быстрее. Я утверждаю, что это вредный совет, и ещё есть люди, придерживающиеся такого же мнения.

Вы там что то сначала говорили, что в типичных системах чтений лога будет намного, намного больше, чем записей. Кто такое говорил? Вы говорили: "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога." 21416958

Теперь вы это не говорите (Мне указанную фразу приписывать не надо), но продолжаете настаивать, что для типичных систем нужно включать сжатие.
.ЕвгенийalexeyvgДаже если храним сотню петабайт лога за годы, это не на миллисекунду не замедлит эти самые "ad-hoc действия" с этим логом, по сравнению с хранением одних суток.
Это заведомая неправда.
1.Вы знаете, как количество индексированных строк связано с количеством уровней индекса, а оно, в свою очередь, со временем поиска по индексу? Вы точно не хотите отдать хотя бы миллисекунду на лишний уровень?Вы не увидели мою фразу "Ну, может, как раз на миллисекунду замедлит, прочитать пару лишних страниц индекса."? Просто случайно недоцитировали, бывает :-)
.Евгений2.Когда ваши действия не ложатся на индекс, в случае относительно небольшой таблицы у вас есть фуллскан. В случае относительно большой - у вас его фактически нет.Я описывал подход, повторю ещё раз - при наличии кластерного индекса на инкрементное ID или на Дату, вы будете фактически работать с локальным фрагментом данных, далее делая фильтры хоть по LIKE %%
Т.е. вместо того, что бы оставить данные за последний день, вы можете поставить условие "последний день", и наслаждаться выборками с любыми условиями. При этом вам точно так же будет доступен и пребыдущий день, и вообще все дни года.

.ЕвгенийПусть у нас будет лог с некластерным индексом по времени.Отличный пример!

А давайте лучше сделаем таблицу с полем IMAGE, лог будем хранить в нём в виде документа WORD, и на этих данных докажем необходимость стирания лога каждый день?

Разумеется, для лога работы чего либо делают кластерный индекс по дате или инкременту, как же иначе? Это же лог!