Я не могу комментировать скорость записи массивов по сравнению с обычными таблицами, но, насколько я могу судить, дизайн с двумя массивами будет довольно громоздким для запросов.
Я также не знаю о производительности чтения массивов, но из того, что я могу сказать, посмотрев документацию, весь доступ к массиву осуществляется через позиционные ссылки (индексы), так что это будет королевской болью позади найти конкретное измерение - вам нужно пройтись по массиву имен, чтобы найти правильный индекс, а затем использовать его, чтобы найти значение. Я сомневаюсь, что это может быть сделано в чистом SQL, и это, вероятно, потребует пользовательской функции.
Теперь о дизайне с таблицами: кажется, вас беспокоит скорость записи. 24 миллиона компонентов в день, это 1 миллион строк в час, что не так много. умножить на 50, в худшем случае, для измерений, это 51 миллион строк в час, то есть менее 1 миллиона строк в минуту. Я думаю, что это должно быть выполнимо, хотя было бы целесообразно выполнять пакетные вставки и избегать выполнения множества вставок в одну строку в течение многих недолговечных транзакций (лучше вставлять их и фиксировать в пакетах, скажем, 10.000 или 100.000).
Я действительно думаю, что вам нужно будет также разработать решение для архивации и / или агрегации, поскольку кажется, что вставлять эти тома не очень удобно. Я сомневаюсь, что это тоже полезно, но, возможно, это только я не понимаю цели этой базы данных. Я имею в виду, что мне кажется маловероятным, что вы хотите иметь возможность точно определить индивидуальное измерение одного компонента, скажем, через 1 год после его изготовления. Принимая во внимание, что полезно сохранять статистику, такую как средние, минимальные, максимальные и стандартные измерения в течение долгого времени. Но, возможно, вы можете объяснить немного об этом.
Еще одна вещь, о которой я подумал, - это то, что она может помочь сохранить исходные данные измерений сначала в дешевом и быстром журнале (просто текстовые файлы, скажем, в формате CSV), а затем использовать несколько считывателей, чтобы прочитать их и вставить их. в базу данных. Эти читатели могли работать довольно постоянным образом. Это сделало бы базу данных менее узким местом и сделало бы систему более надежной (при условии, что вероятность того, что ваш журнал продолжит работать, выше, чем сбой базы данных). Конечно, этот подход менее подходит, если вам нужна отчетность в реальном времени от вашей базы данных для мониторинга процесса (хотя, опять же, мне кажется очень странным, что вам нужно делать это на уровне отдельных компонентов)