Какой хороший способ хранения растровых данных?

Question

У меня есть множество данных временных рядов, хранящихся в более или менее географически привязанной сетке, например, одно значение на 0,2 градуса широты и долготы. В настоящее время данные хранятся в текстовых файлах, поэтому в день года 251 вы можете увидеть:

251
 12.76 12.55 12.55 12.34 [etc., 200 more values...]
 13.02 12.95 12.70 12.40 [etc., 200 more values...]
 [etc., 250 more lines]
252
 [etc., etc.]

Я бы хотел повысить уровень абстракции, повысить производительность и уменьшить хрупкость (например, текущий код не может вставить день между двумя существующими!). Мы возились с хабами BLOB-y RDBMS и даже реплицировали каждую строку формата текстового файла как строку в таблице (одна строка на пару временной отметки / широты, один столбец на приращение долготы - да!).

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

Я разбираюсь в том, чтобы все поместить в файлы NetCDF, но думаю, что нам нужно полностью избавиться от мышления файлов - я ненавижу, что все мое программное обеспечение должно определять имена файлов по датам, работать с несколькими файлами в течение нескольких лет и т. д. Альтернативный вариант - собрать все данные за десять лет (и рассчитать) в одном файле - тоже не представляется возможным.

Какие-нибудь яркие идеи или продукты?

Answer 1

Я собрал ваши комментарии здесь:

1. Я хотел бы сделать все это "без написания собственного кода ввода / вывода для файла"
2. Мне нужен доступ из "Java Ruby MATLAB" и "подпрограмм FORTRAN"

Когда вы добавляете их, вам определенно не нужен новый формат файла. Придерживайтесь того, что у вас есть.

Если мы можем заставить вас ослабить ваше первое требование, т. Е. Если вы захотите написать свой собственный код ввода / вывода, то для вас есть несколько интересных вариантов. Я написал бы классы C ++ и использовал бы что-то вроде SWIG, чтобы сделать ваши новые классы доступными для нескольких языков, которые вам нужны. (Но я не уверен, что вы сможете использовать SWIG для предоставления вам доступа из Java, Ruby, MATLAB и FORTRAN. Возможно, вам понадобится что-то еще. Сам я не совсем уверен, как это сделать.)

Вы также сказали: «На самом деле, если мне нужны файлы, я предпочитаю текст, потому что тогда я могу просто войти и отредактировать вручную, когда это необходимо».

Я считаю, что это ошибочное утверждение. Если вы захотите сделать свои собственные процедуры ввода / вывода файлов, тогда есть очень умные вещи, которые вы могли бы сделать ... И, в конечном итоге, вы можете дать себе инструмент, который преобразует новый формат файла в тот же старый текстовый формат, к которому вы привыкли ... И еще один инструмент, который конвертирует обратно. Я вернусь к этому в конце своего поста ...

Вы сказали что-то, на что я хочу обратиться:

«использовать 40 лет оптимизации БД»

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

Вот самое полезное, что я могу вам сказать, основываясь на всем, что вы нам сказали. Вы сказали это:

"Меня больше интересует оптимизация моего времени, чем процессорного времени, хотя скорость исполнения хороша!"

Честно говоря, это потребует ИНСТРУМЕНТОВ. Хватит думать об этом как о текстовом файле. Начните думать об общих задачах, которые вы делаете, и напишите небольшие инструменты - в WHATEVER LANGAUGE (S) - чтобы сделать эти вещи тривиальными.

А если ваши инструменты оказываются паршивыми? Угадайте, что - это потому, что ваш плоский текстовый файл имеет грубый формат. Но это только мое мнение. :)

Answer 2

Мэтт, большое спасибо, а также longneck и jirv.

Этот пост был частично экспериментом, проверяющим качество дискурса stackoverflow. Если вы, ребята / девочки / инопланетные формы жизни, представляете, я продан.

И в этот момент вы значительно прояснили мои мысли. Имейте в виду, я все еще не обязательно выполню ваш совет, но знаю, что я буду думать об этом очень серьезно. >; -)

Я вполне могу оставить формат файла таким же, добавить к существующим подпрограммам C и / или Ruby, чтобы использовать несколько низкоуровневых функций, которых мне не хватает (например, вставить недостающие временные шаги), и повесить интерфейс HTTP на Все это так, что данные могут быть использованы любой коробкой, на каком бы языке в настоящее время это ни было. Хотя это в основном неизменное устаревшее программное обеспечение, которое создает эти данные, мы всегда придумываем новых потребителей для него, поэтому требование многоязыкового / мультикомпьютерного (ну, забыл ли я это?) Применимо к стороне чтения, а не пишущая сторона. Это также устраняет целый ряд проблем безопасности.

Еще раз спасибо, ребята.

Answer 3

Разъяснения:

Я удивлен, что вы добавили «базу данных» в качестве одного из тегов и рассматривали ее как вариант. Почему ты это сделал?

По сути, у вас есть 2D, однокомпонентное изображение с плавающей точкой на каждом временном шаге. Согласитесь ли вы с таким способом просмотра ваших данных?

Вы также упомянули о желании вставить день между двумя существующими, что кажется очень странным. Зачем вам это нужно? Есть ли новый день между 4 и 5 мая, о котором я не знаю?

Является ли "сжатие" одной из вещей, которая вас волнует, или вы просто устали от плоских файлов?

Будет ли число с плавающей запятой или двойное число достаточным для хранения ваших данных, или вы считаете, что вам нужна более произвольная точность?

Кроме того, на каких языках программирования вы хотите получить доступ к этим данным?

Answer 4

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

опишите, пожалуйста, как вам нужно иметь доступ к данным /

Answer 5

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