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

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.]

Я бы хотел повысить уровень абстракции, повысить производительность и уменьшить хрупкость (например, текущий код не может вставить день между двумя существующими!).Мы повозились со взломами СУБД на основе больших двоичных объектов и даже повторили каждую строку формата текстового файла в виде строки в таблице (по одной строке на пару метка времени / широта, по одному столбцу на приращение долготы - yecch!).

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

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

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

Answer 1

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

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

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

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

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

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

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

"использование 40-летнего опыта оптимизации базы данных"

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

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

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

Честно говоря, для этого потребуются ИНСТРУМЕНТЫ.Перестаньте думать о нем как о текстовом файле.Начните думать об обычных задачах, которые вы выполняете, и напишите небольшие инструменты - на ЛЮБОМ ЯЗЫКЕ (ах), - чтобы сделать эти вещи ТРИВИАЛЬНЫМИ для выполнения.

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

Answer 5

Мэтт, большое спасибо, а также длинношеему и джирву.

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

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

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

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