Мысли об оптимизации

Статистика

На 23.03.2009 (после удаления форума "Мусор", id = 0):

Групп   : 12
Форумов : 77

Всего сообщений : 3 082 626
Всего топиков   :   402 621 (~13% от числа сообщений)

Топиков в форуме
   максимум     : 28 199 (1% от общего числа сообщений, 7% от общего числа топиков, форум .NET, id = 8)

Сообщений в форуме
   максимум     : 250 001 (8% от общего числа сообщений, форум )

Сообщений в топике
   максимум     : 5 150 (тема http://www.rsdn.ru/forum/message/279396.1.aspx - Windows vs Linyx)
   среднее      :    10 (мода 1)

Высота дерева темы:
   максимум : 1 555 (тема http://www.rsdn.ru/forum/message/1099540.1.aspx - Багрепорты)
   среднее  :     2 (мода 1)

На 09.03.2009:

Всего оценок: 1 413 737

Для топика:
   максимум : 3 004 (0.21% от общего числа)
   среднее  :    10

Для сообщения:
   максимум : 770 (0.05% от общего числа)
   среднее  :   3

Распределение по оценкам:
   2  (спасибо)     :  6.29%
   3  (супер)       :  9.24%
   -  (не согласен) : 10.27%
   1  (интересно)   : 12.00%
   +  (согласен)    : 23.26%
   ;) (смешно)      : 38.92%

Всего бомб  : 54 060
   максимум :     27
   среднее  :      2

На 28.03.2009. Проверка возможности сжатия тел сообщений при помощи zlib 1.2.3:

Длина тела сообщения:
   сумма    : ~3 077 MB
   средняя  :  1 046 B
   максимум : ~1 829 KB
   мода     :   ~400 B

Тест сжатия:
   всего сообщений           :  3 089 296
   несжатых сообщений        :     83 035 (2.69%, средняя длина несжимаемого сообщения 51 байт)
   размер несжатых сообщений :     ~3 077 MB
   размер сжатых сообщений   :     ~1 535 MB (49.90%)

Дополнительно

• Время отправки сообщения растет вместе с его id, т.к. id автоинкрементальный первичный ключ. Поскольку упорядочивание по PK всегда будет быстрее нежели выборка с его участием и последующая сортировка по дате, то можно пытаться использовать сортировку по PK (хотя это и нарушает принципы работы с БД). Для хранилища на базе MySQL это дает выигрыш ~50%, для хранилища на базе SQLite это дает выигрыш более чем в 10 раз.
• Очень много времени занимает преобразование значений результата SQL запроса из QVariant, по этому имеет смысл не заполнять ненужные/неиспользуемые поля структур (query->value(n).toXXX). Это имеет смысл для двух "тяжелых" методов IAStorage::getTopicInfoList и IAStorage::getTopicMessageList.
• Обход дерева в ширину на тестовых больших топиках получается быстрее обхода дерева в высоту.