Размер таблицы

Quasar · Сообщение **Quasar** » 08 дек 2006, 10:54

Моя БД стала расти значительно быстрее, чем я предполагал. Решил разобраться. В БД есть таблица CHARTPOINTS, которая на порядки больше всех остальных, поэтому предварительные оценки я делал по ней:

Код: Выделить всё

CREATE TABLE CHARTPOINTS (
    ID         DID /* DID = INTEGER NOT NULL */,
    POINTTIME  DTIMESTAMP /* DTIMESTAMP = TIMESTAMP DEFAULT 'now' NOT NULL */,
    CHARTID    DID /* DID = INTEGER NOT NULL */,
    XVAL       DVALUE /* DVALUE = DOUBLE PRECISION */,
    YVAL       DVALUE /* DVALUE = DOUBLE PRECISION */
);

Вот статистика:

CHARTPOINTS (168)
Primary pointer page: 230, Index root page: 231
Average record length: 35.90, total records: 908713
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 8641, data page slots: 8641, average fill: 68%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 8640
80 - 99% = 0

Index FK_CHARTPOINTS_CHARTID (1)
Depth: 2, leaf buckets: 549, nodes: 908713
Average data length: 0.00, total dup: 908085, max dup: 2159
Fill distribution:
0 - 19% = 0
20 - 39% = 1
40 - 59% = 0
60 - 79% = 0
80 - 99% = 548

Index PK_CHARTPOINTS (0)
Depth: 2, leaf buckets: 662, nodes: 908713
Average data length: 1.00, total dup: 0, max dup: 0
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 1
80 - 99% = 661

Считаю:
Размер таблицы = Data pages * Размер страницы = 8641*8192 = 68mb
Теперь по другому.
Размер таблицы = (Total records * Aver record length / average fill) + Размер индексов(смотрел в IBanalyst) = (908713*35.9/0.68) + 9mb = 55mb.
Не сошлось.

Вопросы:
- Где ошибка в расчетах?
- Так ли это, что сервер целенаправленно поддерживает уровень заполнения страниц в районе 70%, оставляя свободное место для последующих добавлений и других манипуляций? Если да, то получается оценки роста БД надо было делать с учетом этого факта.
- Почему средний размер записи равен 35,9? Если просуммировать размеры всех полей таблицы, получится 32.

Спасибо.

Quasar · Сообщение **Quasar** » 08 дек 2006, 11:02

Еще вопросы.
- В БД есть таблица с блобами. Как посмотреть сколько занимает эта таблица? Статистика блобы не считает.
- Если я удаляю большой блоб останутся ли занимаемые им в прошлом страницы "висеть мертвым грузом" (предположим, что бэкап/рестор не делаю) или они займутся впоследствии другими данными?

Dimitry Sibiryakov

Забыл умножить на Average Fill. В результате получаешь свои 46мб обратно.
Не учитываешь расходы на alignment и служебные поля, типа таблицы нуллов. Ну и TIP может иметь неслабый размер...
Ты за сервер не беспокойся. Это не фокс какой-нибудь чтобы оставлять за собой мертвые страницы. Он любое место повторно использовать может. Твоя же работа как разработчика следить за транзакциями, не давать им застаиваться.

ЗЫ: А скольких гигабайт достигла твоя база что ты стал так заботиться о ее размере?

Сообщение **kdv** » 08 дек 2006, 13:34

- Где ошибка в расчетах?

IBAnalyst же показывает размер таблиц и индексов в мегабайтах. ориентируясь именно на страницы. Предполагать, что страницы будут всегда забиты на 100% - наивно.

Если да, то получается оценки роста БД надо было делать с учетом этого факта.

забей. просто ежедневно замеряй размер БД, получишь средний рост. Соберешь данные за четкий интервал времени, когда у тебя в базе делается все, что можно - получишь цифры для оценки роста БД на будущее.

- Почему средний размер записи равен 35,9? Если просуммировать размеры всех полей таблицы, получится 32.

потому что сервер посчитал реальные записи, и вывел средний размер 35.9.

Quasar · Сообщение **Quasar** » 08 дек 2006, 14:16

Dimitry Sibiryakov писал(а):Забыл умножить на Average Fill. В результате получаешь свои 46мб обратно.
Не учитываешь расходы на alignment и служебные поля, типа таблицы нуллов. Ну и TIP может иметь неслабый размер...
Ты за сервер не беспокойся. Это не фокс какой-нибудь чтобы оставлять за собой мертвые страницы. Он любое место повторно использовать может. Твоя же работа как разработчика следить за транзакциями, не давать им застаиваться.

ЗЫ: А скольких гигабайт достигла твоя база что ты стал так заботиться о ее размере?

На Average fill я поделил, когда считал размер таблицы через записи.

Размер базы пока мал - около 150mb. Но это за месяц не слишком интенсивной работы (только что внедрил) и если дело так пойдет, то за год будет под 2 гига, что уже не мало.

Quasar · Сообщение **Quasar** » 08 дек 2006, 14:20

kdv писал(а):потому что сервер посчитал реальные записи, и вывел средний размер 35.9.

Хотелось бы разобраться. Что значит "реальные записи"? Если в таблице только числа, то по-идее ведь все записи должны иметь одинаковый размер?

Dimitry Sibiryakov

Quasar писал(а):за год будет под 2 гига, что уже не мало.

За 5 лет 10 гиг, что совсем немного. Приличная база в 100 гиг нарастет за 50 лет. Я бы на твоем месте расслабился.

Quasar писал(а):по-идее ведь все записи должны иметь одинаковый размер?

Неправильная твоя идея. RLE compression применяется к записям.

Сообщение **kdv** » 08 дек 2006, 15:51

Что значит "реальные записи"? Если в таблице только числа, то по-идее ведь все записи должны иметь одинаковый размер?

хоть бы сайт сначала почитал... запись имеет заголовок. данные записи упаковываются rle. Опять же, IBAnalyst, если получает статистику с сервера, и включено load metadata, показывает на столбце RecLength хинтом максимально возможный размер записи для сравнения с реальным усредненным размером записи.

Кстати. В статистике пишется средний размер записи без заголовка (номер транзакции, номер формата, и т.п.). Однако при макс.размере записи меньше 40-50 байт фактический размер показывается почему-то больше. Например, если размер записи 9 байт, то статистика может показать 12 байт. Или как в твоем случае, 32 и 36. Я исходники не копал, почему так получается, но сильно ломать голову по этому поводу не стоит. Для записей длиной 70 байт и выше упаковка работает.

Quasar · Сообщение **Quasar** » 08 дек 2006, 19:50

Спасибо.