Как эффективно хранить этот большой объем данных?База данных или что?

Question

Я должен сделать приложение, которое будет проверять изменения 35 пунктов каждую секунду.Каждый элемент имеет 3 значения, каждый из которых умещается в 5 байтов, поэтому для элемента - 15 байтов.Значения не будут меняться каждую секунду, но шаблон не меняется, может быть, они постоянно меняются или они на некоторое время останавливаются ...

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

35 * 15 байтов * 60 секунд * 60 минут * 24 часа * 365 = 16,5 ГБ в год.

Это слишком много для SQLбаза данных.Что бы вы сделали, чтобы уменьшить размер данных?Я думал о сохранении данных только тогда, когда есть изменение, но затем вам нужно сохранить, когда изменение было сделано, и если данные изменяются слишком часто, это может потребовать больше места, чем другой подход.

Я неЯ не знаю, есть ли другие репозитории, кроме баз данных SQL, которые лучше соответствуют моим требованиям.

Как вы думаете?

РЕДАКТИРОВАТЬ: Дополнительная информация.

Нет связимежду данными, отличными от тех, которые я мог бы создать для экономии места.Мне просто нужно сохранить эти данные и запросить их.Данные могут выглядеть следующим образом (складывая все в одну таблицу и сохраняя данные каждую секунду):

  Timestamp    Item1A      Item1B     Item1C     Item2A    Item2B ....

   whatever     1.33        2.33       1.04       12.22     1.22 
   whatever     1.73        2.33       1.04       12.23     1.32
   whatever     1.23        2.33       1.34       12.22     1.22
   whatever     1.33        2.31       1.04       12.22     1.21

Я чувствую, что должны быть лучшие решения, а не этот подход ...

РЕДАКТИРОВАТЬ 2:

Обычно я запрашиваю данные о значениях элемента за определенный период времени, обычно я не запрашиваю данные более чем из одного элемента ...

Answer 1

Это слишком много для базы данных SQL

С каких это пор слишком много?
Это действительно арахис практически для любой СУБД (~ 17 ГБ данных каждый год).

MySQL может это делать, как и PostgreSQL, Firebird и многие другие, но не такие как Sqlite. Я бы сам выбрал PostgreSQL.

В наши дни наличие баз данных SQL с сотнями ТБ данных не является чем-то необычным, поэтому на самом деле 17 ГБ не о чем думать. Не говоря уже о 170 ГБ за 10 лет (с машинами того времени).

Даже если он получает до 30 ГБ в год для учета других данных и индексов, для базы данных SQL это по-прежнему нормально.

Редактировать
Учитывая вашу структуру, которая выглядит мне солидно, минимальные вещи, которые вам нужны, уже есть, и нет никаких дополнений, которые вам не нужны.
Вы не можете стать лучше, не используя уловки, которые имеют больше недостатков, чем преимуществ.

Answer 2

В настоящее время я рассматриваю возможность использования сжатых файлов вместо баз данных SQL.Я буду держать пост обновленным с информацией, которую я получаю.