Здравствуйте, уважаемые старожилы.

В БД на движке InnoDB есть таблица "znachenie" c колонками
ID BIGINT PRIMARY KEY
id_afx SMALLINT
kod_amplitudi TINYINT(2)
kod_fazi TINYINT(2)
amplituda FLOAT
faza FLOAT.
По моим скромным подсчетам это 8+2+1+1+4+4= 20 байт на каждую строку.
Информация в колонки faza и amplituda загружается путем LOAD DATA INFILE из кучи текстовых файлов. Коды амлитуды и фазы программно расчитываются и также заполняются в таблицу путем Load data из другого файла.

SHOW STATUS TABLE LIKE 'table_name' говорит о том, что в сумме c размером индексного файла и data_free на одну запись в таблице уходит порядка 60 байт, что сильно настораживает и озадачивает.

Я хотел бы узнать, можно ли как-то понять сколько будет занимать одна запись в данной таблице, чтобы можно было ориентироваться, так как планируется хранение данных до 1 ТБ.

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

CREATE TABLE IF NOT EXISTS `AntennaModel`.`Znachenie` (
`ID` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
`id_afx` SMALLINT UNSIGNED NOT NULL,
`kod_amplitud` TINYINT(2) UNSIGNED NOT NULL,
`kod_fazi` TINYINT(2) UNSIGNED NOT NULL,
`amplituda` FLOAT NOT NULL,
`faza` FLOAT NOT NULL,
PRIMARY KEY (`ID`),
INDEX `key_id_afx_znachenie_idx` (`id_afx` ASC),
CONSTRAINT `key_id_afx_znachenie`
FOREIGN KEY (`id_afx`)
REFERENCES `AntennaModel`.`AFX` (`ID`)
ON DELETE CASCADE
ON UPDATE CASCADE)
ENGINE = InnoDB;

Кодировка utf8 и правила сравнения utf8_general_ci

miksoft, спасибо за участие.

miksoft,
innodb_file_per_table был включен ( использую MySQL WorkBench для создания)


OPTIMIZE TABLE не делал, почему-то до нынешних времен считал что это для таблиц типа MyISAM. Обязательно разберусь.

Прокомментируйте пожалуйста вопрос по поводу выбранного движка, учитывая амбиции целей, правильно ли выбран InnoDB?

miksoft Сильно зависит от задач, которые должны будет решать СУБД.
Может статься так, что СУБД вовсе не нужна, а достаточно файлов фиксированной структуры.

Основная задача - структурированно хранить данные , использовать сортировки и выборки в интерфейсе управления.
На данный момент данные хранятся в текстовых файлах, которых очень много и это слишком неудобно. Желание устраненить этот недостаток и вызвало мысли о использовании РСУБД.
innodb_file_per_table лучше не включать? Почитал немного, как понял - в основном влияет на производительность. Поправте если не так.

Загружаю в таблицу znachenie 408792 строк.
Data_lenght = 17350656 байт ~ 16.5 МБ
index_lenght = 6832128 байт ~ 6.52 МБ
data_free = 4194304 байт ~ 4МБ
В сумме 27 МБ

Размер на диске znachenie 31744 килобайт~ 31 МБ

Miksoft,а подскажите пожалуйста, реально ли файлы БД хранить на разных дисках в разных файлах? Предположим БД 1.06 ТБ а диск на 1 ТБ, поэтому добавляем еще 1 жесткий и храним вылазящую из диапазона информацию там? Подскажите ,если возможно, что изучить по данному вопросу чтобы более-менее "плавать" в нем теоретически.

Tanglir, а не подскажите, предположим у меня включен 'innodb_file_per_table' , на каждую таблицу создается файл .ibd и .frm.
Но файл ibdata также растет, причем в большем обьеме чем данные, т.е. если теоретически в моей таблице планируется около 1 ТБ данных, то файл ibdata будет заниматься еще больше места?

Как я понял ibdata хранит все данные и индексы InnoDB таблиц( у меня все 9 табилц innoDB , но 8 из них будут занимать мало места и лишь одна(znachenie ) о которой писалось выше много) .Файл ibdata создан по умолчанию, их можно изменить и создать сколько угодно с помощью опции innodb_data_file_path.

Влияет ли переменная 'innodb_file_per_table' на файлы типа ibdata?? Не получится ли так, что если таблица (файл .ibd) весит X гигабайт, то и "ibdata файл(ы)" будут весить столько же(что в сумме 2Х)?
Спасибо большое за участие, задаю вопросы не из-за собственной лени, а из-за неполного понимания предмета.

Прошу прощения, я так и не понял можно ли редактировать свои сообщения.

Верно, что если включена опция innodb_file_per_table, то для нас файл ibdata уже не актуален,а актуальны .ibd файлы таблиц?( т.е. все данные забиваются в ibd и не лезут в ibdata)

tanglir, не сочтите за наглость, но позвольте еще поинтересоваться.

Предположим опция innodb_file_per_table включена, на каждую таблицу создается файл frm и данные хранятся в нем.Как я понимаю там будут храниться и индексы, и загруженные значения. Я могу (судя по мануалу который на который вы мне указали) хранить этот файл frm на другом жестком(внешнем) диске, но не могу его разбивать на части. Грубо говоря загрузил в таблицу 100 ГБ файл будет весить в районе 100 гб и никак его не разбить на кучу одинаковых файлов по 25г.

Если использовать общее хранилище(innodb_file_per_table 0) , файлов ibdata можно будет сделать сколько угодно, указывая приращение, но видимо нельзя будет хранить их на разных дисках?

Если ibdata можно разбить на части и хранить некоторые на разных дисках, то для меня это будет более приемлимый вариант, но я к сожалению еще не вижу подводных камней, которые ожидают при использовании этого варианта.
Спасибо за обьяснения.