Строки и двоичные файлы для хранения переменных в формате файла
Мы стремимся использовать HDF5 для нашего формата данных. HDF5 был выбран, потому что это иерархический кросс-платформенный формат данных, похожий на файловую систему и поддерживающий большие объемы данных.
Файл будет содержать массивы и некоторые параметры. Вопрос заключается в том, как хранить параметры (которые не состоят из большого количества данных), учитывая также проблемы с версиями файлов и усилия по созданию библиотеки. Параметры внутри HDF5 могут быть сохранены как (A) удобочитаемые пары атрибут / значение или (B) двоичные данные в форме составных типов данных HDF5.
В качестве примера рассмотрим в качестве параметра многоугольник с тремя вершинами. В случае А мы могли бы иметь переменную с именем Polygon со строковым представлением ряда вершин, например, например (1, 2); (3, 4); (4, 1), В случае B мы могли бы вместо этого иметь переменную с именем Polygon состоит из матрицы [2 x 3].
У нас есть некоторая идея, но было бы здорово получить отзывы от людей, которые уже работали с чем-то похожим. Точнее, не могли бы вы перечислить плюсы и минусы A и B, а также сказать, при каких обстоятельствах это было бы предпочтительным?
Решение
Говоря, как кто-то, кто должен был делать то, о чем вы говорите много раз, г-н понял это правильно, но я бы немного изменил акцент.
- Для управления версиями текст в основном победитель.
- Поскольку вы используете библиотеку hdf5, я предполагаю, что и сериализация, и разбор эквивалентны человеческим усилиям.
- текстовые файлы более переносимы. Вы можете передавать файлы между поколениями оборудования с минимальным риском.
-
текстовые файлы для людей легче работать. Если вы хотите извлечь подмножество данных и манипулировать ими, вы можете сделать это с помощью многих программ на многих компьютерах. Если вы работаете с двоичными данными, вам понадобится программа, которая позволяет вам это делать. В зависимости от того, как вы видите людей, работающих с вашими данными, это может иметь огромное значение для доступности данных и затрат на обслуживание. Вы сможете sed, grep и даже редактировать данные в Excel.
-
ввод и вывод двоичных данных (для больших наборов данных) будет значительно быстрее, чем текст.
- работа с этими бинарными файлами в новой среде (например, 128-битный компьютер с прямым порядком байтов в будущем) потребует некоторой разработки.
- аналогично, если вы пишете приложения на других языках, вам необходимо одинаково обрабатывать кодирование между приложениями. Это будет означать либо инженерные усилия, либо наличие одинаковых библиотек на всех платформах. Обычным текстом это проще …
- Если вы хотите, чтобы другие писали приложения, которые работают с вашими данными, простой текст проще. Если вы предоставляете двоичные файлы, вам нужно будет предоставить спецификацию файла, которой они могут следовать. С простым текстом любой может просто посмотреть на файл и выяснить, как его проанализировать.
- Вы можете архивировать текстовые файлы со сжатием, поэтому проблемы с пространством являются в первую очередь проблемой для данных, с которыми вы активно работаете.
- Отладка хранилища двоичных данных — это значительно больше работы, чем отладка простого текстового хранилища.
Так что, в конце концов, это немного зависит от вашего варианта использования. Имеет ли смысл просматривать данные в бесчисленных инструментах, которые обрабатывают простой текст? Имеет ли смысл смотреть на это с помощью просмотра больших данных hdf5? Будет ли писать простой текст обременительным для вас с точки зрения времени и пространства?
В общем, когда я сталкиваюсь с этой проблемой, я в основном всегда делаю одно и то же: я сохраняю данные в виде простого текста, пока не пойму, что проблемы со скоростью более раздражающие, чем работа с двоичным файлом, и затем я переключаюсь. Если вы не знаете заранее, пересекаете ли вы этот порог, начните с простого текста и запишите свой интерфейс на свой уровень персистентности таким образом, чтобы потом было легко переключаться. Это небольшая дополнительная работа, которую вы, вероятно, получите обратно благодаря простому тексту, который легче отлаживать.
Другие решения
Если вы планируете часто редактировать файл вручную (например, XML или JSON), используйте формат, понятный человеку.
В противном случае используйте двоичный код — гораздо проще создать для него парсер и он будет работать быстрее, чем любой грамматический парсер.
Также обратите внимание, что ничто не мешает вам позже создать конвертер между двоичной и читабельной формой.
Версирование файлов может звучать неплохо, но вы действительно собираетесь проверять различия в файлах, «содержащих большие массивы»?