Хранение температурно-временных данных в БД

Question

Я храню данные времени и температуры в базе данных, которая на самом деле является просто данными CSV. Первый столбец - это время в секундах, начиная с нуля, а следующий (один или более) столбец (столбцы) - это температура:

0,197.5,202.4 
1,196.0,201.5
2,194.0,206.5 
3,192.0,208.1 ....etc

Каждый график представляет около 2000 секунд. В настоящее время я сжимаю данные перед сохранением их в поле output_profile longtext.

CREATE TABLE `outputprofiles` (
  `id` int(11) NOT NULL auto_increment,
  `output_profile` longtext NOT NULL,
PRIMARY KEY  (`id`)

Это немного помогает ... Я могу сжать сюжет, который составляет 10 КБ простого текста, примерно до 2,5 КБ. Для этих данных нет необходимости в поиске или индексации, поскольку они просто указаны в другой таблице.

Мой вопрос: есть ли другой способ хранения этих данных, о котором я не думаю, который является более эффективным с точки зрения места для хранения?

Answer 1

Есть ли основания полагать, что объем памяти будет ограничивать ваше приложение? Я постараюсь быть уверенным в этом, прежде чем придавать этому более высокий приоритет по сравнению с простотой доступа и использования; для какой цели это звучит как то, что у вас есть, удовлетворительно.

Answer 2

Я на самом деле не очень хорошо понимаю, что вы имеете в виду под «сжатием сюжета». Означает ли это, что вы сжимаете 2000 измерений или сжимаете каждую строку?

Во всяком случае, пространство дешево. Я сделал бы это традиционным способом, то есть две колонки, одна запись для каждого измерения.

Если по какой-то причине это не работает и если вы хотите сохранить 2000 измерений в виде одной записи, то вы можете сделать это намного лучше.

. Создайте CSV-файл с вашими измерениями. , застегните его (gzip -9 дает максимальное сжатие) , сохраните его как blob (или longblob в зависимости от используемой БД), НЕ как longtext

Тогда просто сохраните его в БД.

Это даст вам максимальное сжатие.

Answer 3

PostgreSQL имеет большой объем памяти, поскольку каждый кортеж (предварительное представление строки в таблице) составляет 28 байт, исключая данные (PostgreSQL 8.3). Есть 2, 4 и 8 байтов целых чисел, а отметка времени составляет 8 байтов. Я думаю, что число с плавающей запятой составляет 8 байт. Таким образом, для хранения 1 000 000 000 строк в PostgreSQL потребуется на несколько ГБ больше памяти, чем в MySQL (в зависимости от того, какой механизм хранения используется в MySQL). Но PostgreSQL также отлично справляется с огромными данными по сравнению с MySQL. Попробуйте выполнить несколько запросов DDL к огромной таблице MySQL, и вы поймете, что я имею в виду. Но эти простые данные, которые вы храните, вероятно, должны быть легко разделены, поэтому простой MySQL может хорошо справиться с этой задачей. Но, как я всегда говорю, если вы не совсем уверены, что нуждаетесь в особой функции MySQL, вам следует обратиться к PostgreSQL.

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

Редактировать: Извините, я не видел, что вы на самом деле храните CSV в БД.