Структура данных Python: файл SQL, XML или .py

Question

Каков наилучший способ хранения больших объемов данных в Python, если для поиска ненаправленного графа используется один (или два) 500 000 элементов + словарь?

Я рассматривал несколько вариантов, таких как хранение данных в формате XML:

<key name="a">
    <value data="1" />
    <value data="2" />
</key>
<key name="b">
...

или в файле python для прямого доступа:

db = {"a": [1, 2], "b": ...}

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

Answer 1

Техника исходного кода Python абсолютно правит.

XML анализируется медленно и относительно трудно читается людьми. Вот почему такие компании, как Altova, занимаются бизнесом - XML ​​не очень удобно редактировать.

Исходный код Python db = {"a": [1, 2], "b": ...} is

1. Быстрый разбор.

2. Легко читается людьми.

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

Если вы беспокоитесь о переносимости, рассмотрите YAML (или JSON) для сериализации объекта. Они также быстро разбираются и намного, намного легче читаются, чем XML.

Answer 2

Я хотел бы рассмотреть возможность использования одной из многих библиотек графов, доступных для python (например, python-graph )

Answer 3

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

Если скорость запуска приложения не критична, формат данных зависит от вас, если вы можете поместить его в память Python. Используйте простые типы данных (DICT, списки, строки) для хранения данных, а не график XML, если вы хотите получить к ним быстрый доступ. Возможно, вы захотите написать собственный легкий класс для выражения узлов и сохранения ссылок на другие узлы в формате dict или array.

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

Если, с другой стороны, ваши данные слишком велики для размещения в памяти или вы хотите иметь возможность их постоянного изменения, вы можете использовать SQL для хранения (внешний сервер или базу данных SQLite) или ZODB ( объектная база данных Python).

Answer 4

Подход к файлу Python, безусловно, будет самым быстрым, если у вас есть способ сохранить файл.

Answer 5

XML действительно ориентирован на древовидные структуры и очень многословен. Вы можете посмотреть в RDF способы описания графа в XML, но у него все еще есть другие недостатки, например, время для чтения, анализа и создания экземпляров объектов размером более 500 тыс. и объем используемого файлового пространства.

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

Я бы сначала попробовал засолку питона, чтобы посмотреть, отвечает ли он вашим потребностям Вероятно, он будет самым компактным и самым быстрым для чтения и создания экземпляров всех объектов.

Действительно, единственная причина для использования других форматов, если вам нужно что-то, что они предлагают, например транзакции в SQL или кросс-языковая обработка XML.

Answer 6

Если вы храните свои данные в XML-файле, их будет легче изменить (т. Е. С помощью блокнота ...), но вы должны принять во внимание, что чтение и анализ всего этого объема данных из XML-файла является тяжелой задачей. Использование базы данных SQL (возможно, PostGres) сделает выбор более производительным, DMBS более оптимизированы, чем прямое чтение / анализ файловой системы. Если вы храните все свои данные в некоторой структуре Python в отдельном файле, вы можете воспользоваться преимуществом компиляции байт-кода (.pyc), которая не дает прироста вычислительных терминов, но обеспечивает более быструю загрузку (что вам нужно ). Я бы выбрал последний.