|
|
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
Доброго времени суток, коллеги. Вопрос про кластеризацию большой (40+ млн записей) таблицы (логи) по индексу по полю времени вставки записи: Есть индекс на время вставки записи в таблицу (время хранится в timestamp int8). Код: sql 1. Этот индекс DESC. Я хочу кластеризовать таблицу по этому индексу. Насколько я понимаю, таблица в этом случае будет "перевёрнутой", т.е. последние записи после кластеризации будут в начале таблицы. Вопрос: будет ли таблица реально "перевёрнута" на диске? Не получится ли так, что сразу после кластеризации последние записи будут в начале таблицы, а новые будут писаться в её конец? Как это скажется на производительности? В мануалах ничего толкового не нашёл, но кажется, я делаю что-то не то. Кластеризация идёт уже несколько часов, и конца ей не видно. Не будет ли более правильно сделать этот индекс ASC? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 00:16 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
sKot, в документации явно написано, что кластер - это единоразовая операция по реорганизации данных в таблице, и новые данные будут ложится в неё не обращая внимания на произведённую операцию, т.е. новые данные будут в конце таблицы. если надо реорганизовать новые данные, придётся делать кластер заново. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 08:11 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
sKot, покажите ради интереса вывод Код: sql 1. есть подозрение что смысла делать кластеризацию по этому полю немного т.к. данные и так уже могут быть отсортированы. одноколоночные индесы с порядком сортировки desc делать по идее смысла нет, обычный индекс может в обратном порядке сканироваться так же хорошо как и в прямом. будет ли таблица реально "перевёрнута" на диске? Не получится ли так, что сразу после кластеризации последние записи будут в начале таблицы, а новые будут писаться в её конец? Как это скажется на производительности? да, верно. возможно никак не скажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 13:24 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
Alexius, спасибо за ответ. Код: sql 1. -0.9996 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 17:34 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
sKot, судя по значению уже кластеризовали в обратном порядке log_begin) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 17:41 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
Lonepsycho, да, я это читал, поэтому и задал такой вопрос. Получается, что после кластеризации по обратному индексу таблица не будет монотонно возрастать, а будет сначала убывать (до момента окончания процесса кластеризации), а потом будет возрастать. Мне кажется, что это может сказаться на производительность, т.к. при линейной выборке из этой таблицы на моменте разрыва серверу придётся сделать "прыжок" дисковой подсистемой, плюс таблица поменяет направление сортировки, что тоже может сказаться на производительности. Думаю, что зря это затеял. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 18:16 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
Alexius, да, вчера ночью и кластеризовал. Я так понимаю, что это число будет постепенно приближаться к нулю, т.к. таблица будет расти в противоположном направлении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 18:17 |
|
||
|
Кластерный индекс
|
|||
|---|---|---|---|
|
#18+
sKot, будет расти, в пределе, когда отсортированных в прямом порядке данных будет сильно больше, будет стремиться к +1. то что зря - это скорей всего да, то что станет хуже по описанной причине - очень врядли. для производительности запроса (с условием по log_begin) будет иметь значение, расположены ли 1000 (например) выбираемых строк на 1000 различных страницах или на 10 страницах рядом друг с другом. а на это влияет, отсортированны ли данные на диске по выбираемому полю вообще, а не в каком порядке их сортировали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2018, 19:02 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=39636916&tid=1995802]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
30ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
1ms |
| others: | 294ms |
| total: | 415ms |
| 0 / 0 |
