ЛПШоб не быть голословным пиздаболом - выложили бы тестовые скрипты на создание тех самых 15 миллионов записей из 19 полей переменной длины, для сиквела и для каши. Ну а мы бы поглядели на это чудо, как это в "разреженных массивах" данные почему-то в два раза меньше места занимают, да еще и место для 240 миллионов индексов остается.
"Голословным", да еще и "пиздаболом", быть совсем не хочется, поэтому
поговорим немного детальнее (интересно, письмо лимитировано по размеру?)
Во-первых, я сначала объясню, откуда взялись такие числа: 250,000 - это
среднее число телефонных разговоров по нашей станции в день, множим
на 30 - получаем 7,5 млн. Фактически, это не совсем так, в разные месяцы
нагрузка скачет и например, данные, которые я использовал вчера для офф.тестирования, в сумме составляют 18 млн. записей за 3 месяца.
За это - Sorry. А ситуация выглядела так: данные за 2 месяца в MS SQL - 3.5Gb, данные за те же 2 месяца + еще 2 месяца (ну и + доп.индексы) -
3.7 Gb (сейчас в базе 16 месяцев, размер 15.336 Gb, в среднем на месяц ~5,700,000 записей).
Ну, а теперь к делу. Имеются тарификационные записи за 3 месяца вида:
---
0 010 ......1111111111 111111................ 030506 220939 000118 000006 00 00 0 0 0000 0019 3 0003 0164 0423 0007
---
сведены в plain файл, "." в 3,4 полях убраны
число строк - 18,047,848
размер файла - 1.521 Gb
---
Теперь дело за SQL. В наличии оказался только My SQL (ну, что есть).
Создаем таблицу, 19 полей, по типам:
v1 - tinyint
v2 - int(3)
v3 - varchar(16)
v4 - varchar(16)
v5 - data
v6 - time
v7 - int(6)
v8 - int(8)
v9 - int(2)
v10 - int(2)
v11 - tinyint
v12 - tinyint
v13 - int(4)
v14 - int(4)
v15 - tinyint
v16 - int(4)
v17 - int(4)
v18 - int(4)
v19 - int(4)
(null везде разрешен)
индексов нет... пока :)
---
шаг 2 - Import
ага, обычный импорт plain файла с разделителем (ну и какой скрипт от меня нужен?)
время не считал, а нафига? результат - 1.970 Gb

Передохнем. Выходит, снова я приврал. Не получается на 15 млн. записей
3.5 Gb. Значитца, индекс все же был. Ну вот, снова Sorry.
---
шаг 3 - Indexing
вводим индекс по полю v5 (data)
SQL резво начинает индексировать таблицу, шустро доводит ее до 4Gb
и сдыхает (у меня FAT32 дома). Так что свое заявление подкорректирую:
не 15 млн. записей в 3.5Gb, а скорее ~13 млн. + индекс по v5.

Так, с SQL вроде все. В следующем письме расскажу про Cache.

P.S. Просьба не пинать ногами и громко не смеяться, я никогда и не
называл себя специалистом по SQL.
P.P.S. Не уверен, что изменение типов данных с int на varchar даст
серьезные изменения в размере DB.

С уважением. Сергей

модсекрет каша в том что таблицу вида

ABC CDE 123
ABC CDE 456
ABC HRT 789
ABC HRT 123

каша хранит примерно вот так

ABC CDE 123 456 HRT 789 123

при этом ABC CDE HRT это индекс а 123 456 789 123 данные
немного не так:

a b reference d data
---------------------
0 7 "ABC CDE" 3 123
7 0 3 123
4 3 HRT 3 789
7 0 3 123

a - кол-во совпадающих символов с предыдущей ссылкой
b - кол-во несовпадающих символов с предыдущей ссылкой
reference - глобальная ссылка
d - количество символов в данных при индексе
data - строка данных

С уважением. Сергей

Пьяный Лохправильно ли я понимаю, что "секрет каша" - это есть хранение данных непосредственно в индексе... ээээ.... как бы это сказать... без хранения их где-либо еще?
секрет cache (вернее M) в произвольном структурировании массивов.
вот смотри:
я могу организовать хранение данных вида

a_b_date_time_... в виде "плоской таблицы", как

^dat(1)=a_";"_b_";"_date1_";"_...
^dat(2)=a_";"_b_";"_date2_";"_...
^dat(3)=a_";"_b_";"_date1_";"_...
^dat(4)=a_";"_b_";"_date2_";"_...

а индексов к ней как

^ind(date1,1)=
^ind(date1,3)=
^ind(date2,2)=
^ind(date2,4)=

а можно "совместить полезное с приятным":

^dat(date1,1)=a_";"_b_";"_date1_";"_...
^dat(date1,3)=a_";"_b_";"_date1_";"_...
^dat(date2,2)=a_";"_b_";"_date2_";"_...
^dat(date2,4)=a_";"_b_";"_date2_";"_...

теперь я могу просто выбросить date1 и date2 из данных, поскольку они
избыточны (уже есть в индексе)
ну и конечно использование многомерной индексации, про которую ты
пишешь ниже. только здесь она более удобнее реализована

Пьяный Лох
Т.е. если я в сиквеле сделаю индекс наподобие такого:
то полученный индекс будет по структуре напоминать кешовое хранилище? Однако сиквел будет хранить и индекс, и данные, и за счет этого проигрывать?

за счет того, что индексы не интегрированы в таблицу с данными - да.

Пьяный Лох
Если я правильно понял, то интересно было бы оценить накладные расходы. В сиквеле такие индексы вроде как место хорошо кушают.

сейчас перекурю и допишу письмо про Cache, там как раз об этом.

Пьяный Лох
Что делать, если помимо "ABC CDE HRT это индекс а 123 456 789 123 данные" потребуется иметь еще и "123 456 789 АВС это индекс а CDE HRT это данные" ? Как в этом случае хранится все будет?
как скажешь, так и будет :)
если это индексы разного логического уровня, то развешивай на разные ветки

^a("index type 1","ABC CDE")=123
...
^a("index type 1","ABC HRT")=789

^a("index type 2",123)="CDE HRT"

С уважением. Сергей