2009-05-12 4 views
0

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

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`) 

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

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

ответ

3

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

+0

Как мой дедушка говорил, дисковое пространство дешево –

+0

Возможно, еще один случай, когда я пытаюсь оптимизировать преждевременно. Но я хотел посмотреть, есть ли что-то еще, что я просто совсем не видел или не думал. Благодарю. – brianz

1

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

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

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

. Создайте файл csv с вашими измерениями. . zip it (gzip -9 дает максимальное сжатие) . сохранить его как блоб (или LONGBLOB в зависимости БД вы используете) NOT как LONGTEXT

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

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

0

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

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

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

Смежные вопросы