Доброго времени суток!
В результате работы программы генерируется определенный объем информации. К каждому объекту привязан список различных значения (чисел, строковых данных, символов)

object1 (XXX1, YYY1…ZZZ1)
object2 (XXX2, YYY2…ZZZ2)
….
objectn (XXXn, YYYn…ZZZn)

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

Подскажите в каком направлении двигаться и к каким мануалам обратиться? На какие модули следует обратить внимание?

kukuruku11
возникает необходимость ее сохранения и последующей обработки.

Ну это зависит от того как и чем вы хотите эти данные обрабатывать.

Начнем с того что текстовый файл это непонятно что. Поэтому гораздо сложнее читать и писать.

Если не надо чтобы читалось глазами
0. Если читать питоном то Pickle, cPickle самое быстрое. Если универсальный формат то см. msgpack

Если нужен универсальный формат который смогут читать другие приложения и человек то:
1. Наиболее человекочитаемый формат на мой взгляд yaml http://pyyaml.org/ со временем оказалось что практически во всех приложениях для небольшого объема данных пользуюсь только им.
2. json встроенный - немного менее компактный, но более простой и гораздо более распространенный.
3. Судя по вашим данным, возможно подойдет (если количество элементов в строке у вас одинаково для всех строк) csv/tsv. Получите максимальную переносимость между приложениями. Минус встроенного пакета - не понимает тип переменных, все грузит как строки.
4. Если это действительно таблица, то можно сохранять данные в sqlite или другой субд - плюс что проще заменять данные если потребуется. Будет выше скорость чтения /записи по сравнению с csv.
5. Для получения пиковых скоростей чтения записи или записи очень больших объемов данных рекомендую бинарный формат hdf5. записать разнородные данные в него можно, только надо разобраться тогда с тем как в numpy структуры создаются.

По поводу xml. Он для хранения данных непригоден. т.е. стандарт предусматривает хранение только строк, другие данные там хранить нельзя. Кроме того читать его сложно и процедура чтения медленная. При наличии перечисленных выше форматов я не могу придумать когда надо предпочесть xml другим форматам.

ps
классический пакет для анализа данных pandas.

Спасибо за ответ.
Нет, человек полученные логи читать не будет.
Данные предназначены для вывода и для обработки другими модулями программы, в перспективе.

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

doza_and
По поводу xml. Он для хранения данных непригоден. т.е. стандарт предусматривает хранение только строк, другие данные там хранить нельзя.

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

xml не пригоден для редактирования руками, так как там надо применять экранирование некоторых символов, а для этого надо знать спецификацию языка.

kukuruku11
Данные предназначены для вывода и для обработки другими модулями программы

Это сериализация.

kukuruku11
Поэтому БД скорее всего подойдут

Тогда как раз базы данных не подойдут. Если только строки с разным количеством полей писать в разные таблицы и добавить поле номер записи.
Если это другие модули вашей программы на питоне то тогда думаю cPickle самое то. Если модули не на питоне напишите что еще будете использовать.

doza_and
Если модули не на питоне напишите что еще будете использовать.

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

Если данные, то БД, ибо она так и называется, потому что так задумана (а еще SQL рулит)

py.user.next
Это сериализация.

Не, сериализация это когда сохраняешь объект класса, чтоб потом его загрузить и юзать.

Тут ИМХО данные, раз отложены “на потом”, это просто данные, статистика некоторая. Для нее однозначно БД и учить SQL.

Iskatel
а еще SQL рулит

Не подвергая сомнению ценность изучения SQL добавлю ложечку дегтя.
1. Не все базы данных работают с SQL
2. Сам SQL понятие расплывчатое в силу наличия кучи диалектов.
3. Одни люди на этом форуме пропагандируют изучение sql, а другие призывают в коде не использовать sql вообще, применять алхимию и т.п. Микрософт вложил кучу времени и денег в linq https://msdn.microsoft.com/ru-ru/library/Bb397926.aspx. Походу SQL их чемто не устраивает…
4 По моему опыту данные или, по крайней мере индекс, влезают в оперативную память в 99% случаев. При этом часто удобнее использовать аналоги sql запросов в виде конструкций языка python. Ну может это конечно дело привычки.

Iskatel
Не, сериализация это когда сохраняешь объект класса, чтоб потом его загрузить и юзать.

Тут ИМХО данные, раз отложены “на потом”, это просто данные, статистика некоторая.

kukuruku11
Данные предназначены для вывода и для обработки другими модулями программы

Это, конечно, расплывчатое определение, но если он заморочился xml-ом, то это явно не просто так.
Поэтому ему и предлагают pickle - средство сериализации в питоне.

doza_and
1. Наиболее человекочитаемый формат на мой взгляд yaml http://pyyaml.org/ со временем оказалось что практически во всех приложениях для небольшого объема данных пользуюсь только им.
2. json встроенный - немного менее компактный, но более простой и гораздо более распространенный.

В Emacs'е используют elisp для хранения данных. На yaml перешёл недавно, а когда выбирал ещё, оказалось, что json - подмножество yaml'а.

py.user.next
На yaml перешёл недавно

Для справки. Чисто питоновская реализация довольно медленная чтение в 10 раз медленнее чем json. Есть C реализация, она проигрывает json. незначительно, требует чтения мануала для установки. Однако самое неприятное что на больших файлах pyyaml нещадно жрет память. На чтение смешного документа порядка 100Mb утекает 2ГБ оперативки. Думаю это баг библиотеки, поскольку не вижу в формате причин для такого поведения. Ситуацию несколько спасает то что такие документы можно трактовать как поток документов yaml. Тогда память естественно не течет. Однако два этих фактора вместе делают библиотеку pyyaml не очень удачным выбором для оперирования с большими объемами данных.
По размеру файла с данными yaml и xml что в распакованном виде примерно одинаковы. В зипованном yaml чуток выигрывает, поскольку в нем много повторяющихся пробелов.