unutcon MephiПередо мной изначально поставили задачу "Разработки реляционной БД", поэтому я и выбрал MySQL( изначально требования к хранимым данным были в районе 1 ТБ).
Если это ВПК, то в первую очередь смотрите на сертифицированные средства, например Линтер-ВС. Ну или posgresql, проще будет потом адаптировать к сертификации.

unutcon MephiТребования к быстродействию определенно- "оптимальные". Конкретных значений никто сказать не может, но хотелось бы иметь мощную машину, которая сможет обрабатывать подобные объёмы и проводить выборки достаточно быстро.
Если требований нет, то проектируйте приложение с учетом возможности использования кэша в памяти. Это может быть как стороннее решение, так и возможности СУБД - какие нить промежуточные таблицы, располагающиеся исключительно в оперативке.


unutcon MephiТолько сейчас увидел что написал про обьёмы в 2-3 ГБ
На самом деле Речь идет о 2-3 ТБ.
Тут, конечно, все уже в оперативку не поместить. Хотя я не уверен, что все эти данные вам нужны одновременно. Нужно понимать, какие именно запросы идут к таблицам. Но я не понимаю, это что получается, вы храните всю историю значений по каждому конкретному элементу? А все расчеты у вас только по последним измерениям? Если да, то грандиозный объем оперативки не нужен. Можете для ускорения последние данные держать на SSD RAID10, а основную массу старых данных на более дешевые носители (секционирование)


unutcon MephiВсе остальные запросы на данный момент это выборки без JOIN и группировок, с использованием индексов.
Т.е. из родительских таблиц получаем id_afx и по этому значению из таблицы "Значение" получаем необходимые данные.
То есть вы выдаете данные, и их считает какой то другой процесс? Или хотите, чтобы СУБД в процессе считало?


В принципе, если у вас бюджет резиновый (вы ведь его не озвучили), нужно быть проще и считать по максимуму. Мне почему то кажется, что 128 оперативки, 4 ядра и raid 10 на 2-4 терабайта (не обязательно SSD) должно хватить, при условии, чтоб вы своевременно будете архивировать неактуальные данные. А если вдруг нужно больше, то это уже дисковые массивы
unutcon Mephimiksoft,

А если использовать тип данных BLOB , то будут ли работать для таблицы "Значение" с DDL представленным выше
запросы вида:

SELECT faza FROM znachenie WHERE id_afx = x AND kod_fazi = X;

Ну или другие условия выборки??

Возможно, вам стоит каждый набор значений от блока подрешеток хранить как массив байтов и выдавать в ответ на id_afx этот массив, возлагая ответственность за парсинг на клиента? Скорее всего, ведь имеет значение анализ всего подблока, а не элемента? Или это нормальная ситуация, когда один клиент запросом берет значение элемента в одном блоке, следующим запросом смотрит на элемент из другого блока и так далее? Такой рендомный access получится.

tanglir,

ясно дело )))) откуда уверенность то, не зная ни характера нагрузки, ни типа запросов. Есть только мои фантазии, основанные на скудном описании ТС. Под них все подходит