XML-монстр или какой он - самый большой файл? [Решено]

[leo_bsv]

Здравы будьте!
В настоящее время работаю в области xml, хочу спросить, может быть кто-нибудь имел опыт создания подобия БД на xml?
Как оптимально хранить xml-документы? В одном здоровом файле или в куче разных?
Есть ли вообще у файла xml разумный предел размера? Можно ли работать с файлом в несколько Гб? Как такой большой файл xml открывается в программе - весь грузится в память? Можно ли грузить частями?
Как это всё изобразить в FP?
P.S.: возможно тема не для этой ветки... не уверен.

[Odyssey]

Есть ли вообще у файла xml разумный предел размера?

Зависит от объёма памяти, производительности процессора и ограничения на размер файла в файловой системе.

Можно ли работать с файлом в несколько Гб?

Можно (но не так удобно как с файлом в несколько Мб).

Как такой большой файл xml открывается в программе - весь грузится в память? Можно ли грузить частями?

Можно и целиком и частями. Для этого есть два вида XML API -- DOM и SAX. При работе через DOM API файл грузится в память весь, в виде объектной модели документа. В такой модели можно в любой момент обратиться к любому элементу или свойству. При работе через SAX API обработка элементов выполняется строго в порядке их следования, все элементы грузить в память не требуется.
http://ru.wikipedia.org/wiki/SAX
http://ru.wikipedia.org/wiki/Document_Object_Model

Как это всё изобразить в FP?

Для DOM -- так: http://wiki.freepascal.org/XML_Tutorial/ru
Для SAX -- есть модуль sax, уроков по нему не припомню, придётся читать исходники.

[leo_bsv]

Для DOM -- так: http://wiki.freepascal.org/XML_Tutorial/ru
Для SAX -- есть модуль sax, уроков по нему не припомню, придётся читать исходники.

Спасибо за SAX
Видимо это то что надо!

P.S. Ссылки по теме
Введение в XML
Введение в SAX

Разведка боем!
Для теста DOM был сгенерирован xml размером ~527 Мб состоящий примерно из 1800000 нод с атрибутами.
На моей машине с объёмом памяти 3,1 Гб вывалилось исключение EOutOfMemory
Файл грузится достаточно продолжительное время, окно работающей программы затемняется и становится недоступным. )) Короче конец света
Мои выводы:
1. Валить всё в один файл xml не нужно - это же DOM - объектная модель документа! (для базы данных она не предназначена).
2. SAX конечно позволяет пробежаться по файлу и получить нужную информацию, но опять-таки смысл использовать голый xml для создания здорового файла, ведь DOM-то всё-равно будет тормозить )) ни записать с помощью DOM, ни внести изменения нормально не выйдет.
3. Вероятнее всего оптимальным решением в моём случае будет регистрация приходящих документов в реляционной БД - для быстрого поиска, а сами данные хранить в файлах или в этой же БД в виде xml? Может быть у кого-то есть опыт эксплуатации таких баз?

[Sergei I. Gorelkin]

527Мб... xe-xe.
На 32-битной системе c помощью fcl-xml можно загрузить DOM размером около 40 мБайт, потом у процесса кончается адресное пространство.

[Timid]

3. Вероятнее всего оптимальным решением в моём случае будет регистрация приходящих документов в реляционной БД - для быстрого поиска, а сами данные хранить в файлах или в этой же БД в виде xml? Может быть у кого-то есть опыт эксплуатации таких баз?

Да, я поступаю именно так. Строю дерево "внешних" элементов в виде "обычных" индексов "лес-дерево" (родитель-потомок) в БД, а в каждой записи делаю поле Memo, в котором храню "упакованный" в base64 XML документ. Всю информацию для поиска (индексации), выношу в отдельные поля БД.

Это позволяет не задумываться о копировании (клонировании) документов, что в случае полного "развертывания" XML будет представлять проблему.

[v-t-l]

http://sphinxsearch.com/
http://www.mongodb.org/

[leo_bsv]

На 32-битной системе c помощью fcl-xml можно загрузить DOM размером около 40 мБайт, потом у процесса кончается адресное пространство.

ы... любопытно... я клонировал рекурсивно по 600 000 нод за раз... три раза получилось, после третьего начало выпадать собщение ничего не понимаю
в примере 100 000 но клонируемая нода имеет ещё шесть дочерних с атрибутами.

Код: Выделить всё

// эксперименты с xml
procedure TMainForm.MenuItem56Click(Sender: TObject);
var i: integer;
    Node,NN: TDOMNode;
begin
  // получим ноду
  Node:=TDOMNode(TreeView.Selected.Data);
  // ещё раз выполним проверку
  for i:=1 to 100000 do begin
    NN:=Node.CloneNode(true);
    try
      TDOMElement(Node.ParentNode).InsertBefore(NN,Node);
    finally
      ProgressBar1.Position:=i;
    end;
  end;
  SaveChangedDoc;
end;  

p.s. вероятнее всего я опять где-то накосячил поэтому на достоверность не претендую - исследования проводил для себя - выводы сделал

[скалогрыз]

527Мб... xe-xe.
На 32-битной системе c помощью fcl-xml можно загрузить DOM размером около 40 мБайт, потом у процесса кончается адресное пространство.

почему вдруг?

[Sergei I. Gorelkin]

Элемент (TDOMElement) занимает 64 байта, пустой текстовый узел - 40 (могу ошибаться, но что-то около того). В среднем будет 52. 2 гига адресного пространства делим на 52, получаем чуть поменьше 40 миллионов. Понятно, что не каждый байт файла образует узел, но и в адресном пространстве не все 2 гига можно занять под узлы. Экспериментально у меня получалось загрузить около 40 мБ. Можно и побольше, если мало элементов и длинные текстовые узлы, но не на порядок.

[скалогрыз]

узел в файле занимает минимум 4 байта:

Код: Выделить всё

<a/>

т.е. итоговый файл (тестовая болванка) должен быть около 40Mb*4 = 160 Mb.

2 Sergei I. Gorelkin, лень в документации читать, но можно ли получить offset для TDOMElement-а в xml-потоке исходных данных? (естественно, если элемент не был добавлен динамически). В глаза так и лезет - TNodeData, но как его получить?

[Sergei I. Gorelkin]

лень в документации читать, но можно ли получить offset для TDOMElement-а в xml-потоке исходных данных? (естественно, если элемент не был добавлен динамически). В глаза так и лезет - TNodeData, но как его получить?

Пока нельзя никак. Планируется реализовать класс а-ля дотнетовский XmlReader, в котором позиция текущего узла будет доступна.