powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Правильное создание индекса
25 сообщений из 42, страница 1 из 2
Правильное создание индекса
    #39645681
Фотография шК0ДЕР
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Господа, добрый вечер. Прошу дать совет
Исходные данные
есть таблица с логами
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
create table dbo.tLogs
(id dsidentifier identity not null
,ObjType int not tull
,DateStart datetime not null
,DateEnd datetime 
,infoObj varchar(300)
,nameObj varchar(40)
,constraint pktLogs primary key (id))

пока в ней пара десятков тестовых дынных, на бою ожидается их большой прирост
есть запрос вида
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
select ObjType,  
         DateStart, 
         DateEnd, 
         infoObj 
 from tLogs 
where nameObj = @nameObj  /*уникальных значений не больше 10 000*/
  and ObjType = @ObjType      /*уникальных значений не больше 20*/
  and DateStart >= @DateStart  /*@DateStart всегда равна getdate() минус пара часов*/ 
  and DateEnd > @DateEnd /*@DateEnd всегда равна getdate() минус пара часов, но она больше @DateStart*/


Предикаты можно поменять местами, составной индекс на таблице пока один - на полях id, ObjType
Сторонние запросы к данной таблице используют лишь индекс описанный выше.
Верным ли будет создать такой составной индекс или есть более приемлемые вариации?
Код: sql
1.
2.
3.
create index someindname
   on dbo.tLogs(nameObj, ObjType, DateStart, DateEnd) 
with (fillfactor = 80)
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39645712
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
шК0ДЕР,

Код: sql
1.
2.
create index someindname
   on dbo.tLogs(nameObj, ObjType, DateStart) include (DateEnd, infoObj);
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39645849
Фотография шК0ДЕР
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm, благодарю!
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646058
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
шК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646060
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийшК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).
это кто такое рекомендует?
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646081
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TaPaK.ЕвгенийшК0ДЕР,

Также для большинства случаев рекомендую страничное сжатие, как индекса, так и самой таблицы (data_compression = page).
это кто такое рекомендует?
Это я такое рекомендую.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646085
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгений,

нагруженные таблицы-то лучше не жать.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646102
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Владислав Колосов.Евгений,
нагруженные таблицы-то лучше не жать.
В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.

Копать глубже и рассматривать прирост нагрузки в разрезе ресурсов мне сейчас лень. Может, TaPaK соберет стенд и статистику выполнения?
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646133
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийВладислав Колосов.Евгений,
нагруженные таблицы-то лучше не жать.
В большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.

Копать глубже и рассматривать прирост нагрузки в разрезе ресурсов мне сейчас лень. Может, TaPaK соберет стенд и статистику выполнения?
зачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646137
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646141
TaPaK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичTaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.
и платим за всё это cpu
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646152
Гавриленко Сергей Алексеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TaPaKГавриленко Сергей Алексеевичпропущено...
Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.
и платим за всё это cpuНу так не у всех же дефицит CPU, а всего остального навалом.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646166
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийВ большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает? Когда физически пишутся страницы данных/индексов в БД?
Код: 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.
use msdb;
set xact_abort, nocount on;
go

print @@version;

create table dbo.tr (id tinyint, description varchar(30), elapsed_time int, log_bytes_used bigint);

create table dbo.t1 (id int identity, s varchar(50));
alter table dbo.t1 add constraint PK_t1 primary key clustered (id);

create table dbo.t2 (id int identity, s varchar(50));
alter table dbo.t2 add constraint PK_t2 primary key clustered (id) with (data_compression = page);

create table dbo.t3 (id int identity, s varchar(50));
alter table dbo.t3 add constraint PK_t3 primary key clustered (id) with (data_compression = row);
go

declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t1 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 1, 'data_compression = none', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go

declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t2 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 2, 'data_compression = page', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go


declare @dt datetime2 = sysdatetime(), @c int = 1000000;

begin tran;

while @c > 0
 begin
  insert into dbo.t3 values (cast(newid() as varchar(36)));
  select @c -= 1;
 end;

insert into dbo.tr
select
 3, 'data_compression = row', datediff(ms, @dt, sysdatetime()), sum(dbt.database_transaction_log_bytes_used + dbt.database_transaction_log_bytes_used_system)
from
 sys.dm_tran_current_transaction ct join
 sys.dm_tran_database_transactions dbt on dbt.transaction_id = ct.transaction_id

commit;
go

select
 tr.*,
 cast(tr.elapsed_time * 100. / a.min_elapsed_time - 100. as money) elapsed_time_impact_percent,
 cast(tr.log_bytes_used * 100. / a.max_log_bytes_used - 100. as money) log_bytes_used_impact_percent
from
 dbo.tr cross apply
 (select min(elapsed_time), min(log_bytes_used) from dbo.tr) a(min_elapsed_time, max_log_bytes_used)
order
 by id;
go

drop table dbo.tr, dbo.t1, dbo.t2, dbo.t3;
go


Код: plaintext
1.
2.
3.
4.
Microsoft SQL Server 2008 R2 (SP3) - 10.50.6220.0 (X64) 
	Mar 19 2015 12:32:14 
	Copyright (c) Microsoft Corporation
	Developer Edition (64-bit) on Windows NT 6.3 <X64> (Build 17134: ) (Hypervisor)
descriptionelapsed_timelog_bytes_usedelapsed_time_impact_percentlog_bytes_used_impact_percentdata_compression = none51901731167720,002,6408data_compression = page727216866265640,11560,00data_compression = row673216866265629,7110,00


Код: plaintext
1.
2.
3.
4.
Microsoft SQL Server 2017 (RTM-CU4) (KB4056498) - 14.0.3022.28 (X64) 
	Feb  9 2018 19:39:09 
	Copyright (C) 2017 Microsoft Corporation
	Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 17134: ) (Hypervisor)
descriptionelapsed_timelog_bytes_usedelapsed_time_impact_percentlog_bytes_used_impact_percentdata_compression = none68461767626640,002,7216data_compression = page874017207964827,66580,0002data_compression = row835017207930021,9690,00
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646174
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm.ЕвгенийВ большинстве случаев нагрузка логирования не превышает считанных процентов от общей нагрузки на систему. Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога.Вы точно знаете как работает сжатие? Для чего предназначен лог и как он работает?
Я говорил про пользовательское логирование (шК0ДЕР - "...есть таблица с логами..."). Либо вы несколько поспешили, либо я выразился недостаточно определенно - выбирайте любой вариант.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646198
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гавриленко Сергей АлексеевичTaPaKзачем, я точно никому не рекомендую, никогда. Разве что с местом проблемы(в 2018 году :))Выигрыш по месту -- это минимальное из преимуществ сжатия (хотя кому как -- место на производительных но маленьких SSD тоже важно не транжирить). При этом так же экономятся iops'ы и память.Что то я тоже разочаровался в сжатии. Самое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофически. Использую только ради места на дисках.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646200
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgСамое большое разочарование - вставка данных, там не то, что "требует CPU", а оно просто упирается в одно ядро, и производительность снижается катастрофическиОсобенно BULK - получить вместо 500 гб/с только 5 - это само собой, бай дизайн.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646269
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийЯ говорил про пользовательское логированиеТем более.
А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов".
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646332
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm.ЕвгенийЯ говорил про пользовательское логированиеТем более.
А рекомендовать что-то, не зная как это работает и не сделав хотя бы раз нагрузочное тестирование на конкретной системе - удел бустобрехов, вроде некоторых самопровозглашенных "экспертов".
Подчеркну специально для вас: моя рекомендация относилась к большинству случаев возможных вариантов использования логирования, описанного в первом сообщении. И добавлю: прежде всего к тем вариантам, которые мне кажутся естественными, типичными и ожидаемыми для пользовательского логирования.
Разумеется, можно придумать ситуации и наборы данных, когда сжатие практически не даст положительного эффекта, зато проявит все отрицательные. Например, когда вся деятельность системы шК0ДЕР-а будет заключаться в пакетной вставке почти не повторяющихся данных (в рамках страницы) в таблицу лога, запросам к ней, и ничего сверх того. Но я не ставил себе задачей подобное фантазирование и считаю свою оговорку про большинство случаев вполне достаточной.
Наконец, мне показалось, что вы захотели обосновать мою некомпетентность в теме сжатия данных MS SQL единственной, хотя и очень веской фразой "Тем более". Извините, но я не смог увидеть в ней ничего похожего на аргументацию даже при максимальной снисходительности. Я допускаю, что вы можете считать нецелесообразным сжатие таблицы логирования в большинстве типичных случаев, но мне это не мешает. Некоторые наши современники даже верят в плоскую Землю.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646355
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийНаконец, мне показалось, что вы захотели обосновать мою некомпетентностьОбычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646366
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгенийсчитаю свою оговорку про большинство случаев вполне достаточнойНе знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время.
Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога."
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646381
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
invm.ЕвгенийНаконец, мне показалось, что вы захотели обосновать мою некомпетентностьОбычно собственную компетентность доказывают чем-то большим, чем словоизвержением ни о чем, в стиле "эффективных менеджеров" с "видением". А делать это, как вы честно написали, - лень.
Эта тема была открыта для получения советов (и я дал таковой), а не для демонстрации доказательств моей компетентности всем желающим и нежелающим, равно как и не для наездов. Вам не лень замусоривать чужую тему "эффективными менеджерами" и т.п оффтопными наездами?
alexeyvg.Евгенийсчитаю свою оговорку про большинство случаев вполне достаточнойНе знаю, как конкретно у ТС, но "в большинстве случаев" логирование предполагает запись, не предполагает частое чтение, и не предполагает хранение за большое время.
Соответственно, странно было прочитать ваше "Крохотное увеличение нагрузки при записи будет более чем компенсировано приростом скорости чтения лога."
Я бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс. Миллионы строк? Но главнее другое - отмечена важность быстрого чтения лога.

Теперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяется. Во-вторых, оно неразрывно связано с действием, ресурсозатратным относительно логирования и не должно его значимо замедлять. Приняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646397
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийЯ бы слегка поспорил с "большим временем хранения". Какое оно имеет отношение к теме? Важен объем данных, а он не малВажно, будет ли профит от использования сжатия в виде уменьшения стоимости хранилища. Если храним мало, то стоимость низкая, и этот + сжатия можно не учитывать.
.ЕвгенийВажен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме.
.ЕвгенийТеперь по записи. Характерным для логирования я бы назвал другие признаки: во-первых, оно вставляет в таблицу одну строку и bulk insert здесь не применяетсяСамо собой, это был просто крик души про сжатие :-)
.ЕвгенийПриняв это за норму, поставлю вопрос: какова доля операций вставки в таблицу логирования в общей нагрузке сервера? Какую разницу мы увидим между действиями с логированием в несжатую и сжатую таблицу? А примерно следующую: 1 секунда действия + 100 микросекунд логирования против 1 секунды действия + 200 микросекунд логирования. Другими словами, разницу малую и размазанную по времени, а потому малую пренебрежимо.Я лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
.ЕвгенийНо главнее другое - отмечена важность быстрого чтения лога.Отмечена необходимость быстрого выполнения запроса на выборку.
Про "соотношение чтения и записи" автор не говорил, возможно, оно такое же, как в типичных системах - на миллион запросов на вставку один запрос на чтение.
Вам "лень", вы советуете "собрать стенд", но даже не потрудились спросить у ТС об этом.
И тем более непонятно выглядит "в большинстве случаев".
Сколько видел систем, всегда чтение из логов происходит по письму больших начальников при разборках "кто виноват", "а я этого не вводила", "откуда тут НДС?", раз в месяц. А лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646414
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvg.ЕвгенийВажен объем данных, а он не мал: требуется не просто индекс, а оптимизированный индекс.Сжатие к оптимальному индексу не имеет отношения. Самый оптимальный индекс предложен invm в первом же ответе в теме.
Да что вы говорите?! А затраты на чтение сжатого и несжатого индекса не имеют какого-либо отношения к оптимальности (в случае, когда он занимает несколько страниц)? Как же он оптимален, если его читать дольше?
alexeyvg.ЕвгенийНо главнее другое - отмечена важность быстрого чтения лога.Отмечена необходимость быстрого выполнения запроса на выборку.
Про "соотношение чтения и записи" автор не говорил...
Перечитайте мою фразу и заметьте - я тоже про него не говорил!
Возможно, что лог читается раз в сутки. Однако оптимизируют именно это единственное (или не единственное) чтение, а не запись. Отмечу, что шК0ДЕР не делал оговорки относительно границы допустимого торможения записи в лог. Ну и?
alexeyvgЯ лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.
alexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646423
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.ЕвгенийalexeyvgЯ лучше приму другую норму - 100 микросекунд действия + 100 микросекунд логирования.
Положа руку на сердце, вы всерьез считаете подобное соотношение действия и логирования типичным? Поскольку равное по времени логирование - это один insert, то вы постулируете логирование каждого отдельного оператора SQL.Ок, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы.
Однако соотношение всё таки не 20000:1, как у вас.

.ЕвгенийalexeyvgА лог пишется 10 000 раз в секунду. Легко вычислить соотношение, типичное для "большинства систем".
10 000 * 86 400 секунд = практически неуправляемая таблица, если не чистится каждые сутки. Извините, здесь я могу только процитировать великого поэта: "Печально я гляжу на наше поколенье! Его грядущее - иль пусто, иль темно..." В такой лог действительно смотрят исключительно из-под палки. Это действительно типично для большинства систем, с которыми вы имели дело? С моим профессиональным опытом это категорически расходится.Видимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.
.Евгений10 000 * 86 400 секунд = практически неуправляемая таблицаДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?
Нормально всё "управляется", не такая большая таблица, хранить можно столько, сколько скажет бизнес, технических ограничений тут нет, соответственно, в таких случаях это решает бизнес, а не технический специалист. Впрочем, если хранить такой лог, например, год, тогда уже можно подумать о сжатии.
...
Рейтинг: 0 / 0
Правильное создание индекса
    #39646443
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alexeyvgОк, логирование нескольких операций. Но часто бывало и один на один, и даже несколько записей в лог на одну запись в рабочие таблицы.
Однако соотношение всё таки не 20000:1, как у вас.
Тогда взгляните на это с другой стороны. Сопоставимая нагрузка действий и их логирования означает, что оптимизация последнего посредством исключения избыточных сведений означает соответствующий рост производительности системы. Утрируя, на одном и том же оборудовании одновременно обслуживается тысяча клиентов с полным логированием, или две тысячи - с сокращенным. А то и больше. Или бизнесу неведомо, что такое стоимость владения?
alexeyvgВидимо да, расходимся, у меня системы были высоконагруженные, работали надёжно, так что читать из лога приходилось редко, причём, как вы говорите, "из-под палки", то есть выполняя запросы бизнеса по исследованию какого то редкого инцидента, а не просто из любопытства или хулиганства.
Любопытство или хулиганство здесь не при чем. Хороший лог обеспечивает легкую и удобную локализацию любой мнимой или реальной проблемы с данными или производительностью. Кому-то не нравится цифра, результат действий или время реакции - лог покажет, кем, какие и когда элементы системы (хп, задачи и т.п.) были запущены, с какими аргументами и в какой последовательности, свяжет их с интерфейсом или конкретными процессами. В подавляющем большинстве случаев этого достаточно для воспроизведения и дальнейшего анализа проблемы. Дальнейшая детализация в логе возможна только по отдельному запросу. Так я делал сам, такой же подход видел в чужих системах, с которыми приходилось работать.
alexeyvgДа, интересно ваше замечание, что значит "неуправляемая"? Из неё запрос нельзя сделать, что ли?
Потому что с таблицей в миллиарды записей и более нельзя произвести ad-hoc действия за разумное время. Ходить можно только по дорожкам индексов, сошел с них - сиди и жди. Можешь час ждать, можешь более. Да и индексы не панацея - уровней больше, бегать дольше. Неуправляемую глыбу можно послать в оперативу, кубы или какую-нибудь бигдатую систему, но зачем? Надо просто взять и отсечь лишнее - 99 и 9 в периоде процентов.
...
Рейтинг: 0 / 0
25 сообщений из 42, страница 1 из 2
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Правильное создание индекса
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]