.Евгений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, и на этих данных докажем необходимость стирания лога каждый день?

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