Xml или Sqlite, Когда бросать Xml для базы данных?

Ответ 1

Я в основном согласен с Mitchel, что это может быть очень специфичным в зависимости от того, что вы собираетесь делать с XML/sqlite. Для вашего случая (кэша) мне кажется, что использование sqlite (или других встроенных dbs) имеет больше смысла.

Сначала я действительно не думаю, что для sqlite потребуется больше накладных расходов, чем XML. И я имею в виду как накладные расходы на время разработки, так и накладные расходы времени исполнения. Проблема только в том, что вы зависите от библиотеки sqlite. Но так как вам понадобится библиотека для XML в любом случае, это не имеет значения (я предполагаю, что проект находится в C/С++).

Преимущества sqlite над xml:

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

Недостатки sqlite:

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

Другие вещи, возможно, подходят для обоих решений.

Подводя итог, ответьте на ваши вопросы соответственно:

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

• Из-за того, как организованы XML файлы, запросы sqlite всегда должны быть быстрее (запрет некоторых угловых случаев, когда это не имеет значения, так как это невероятно быстро). Для ускорения поиска в XML потребуется база данных индексов в любом случае, в вашем случае это будет означать наличие кеша для кеша, а не особенно хорошая идея. Но с sqlite вы можете индексировать как часть базы данных.

Ответ 2

У меня есть опыт с этим. Я работаю над проектом, в котором мы первоначально хранили все наши данные с помощью XML, а затем перешли на sqlite. Для каждой технологии существует множество плюсов и минусов, но именно это привело к переходу. Вот что мы наблюдали.

Для небольших баз данных (несколько мегабайт или меньше) XML был намного быстрее и с ним было легче справиться. Наши данные были, естественно, в древовидном формате, что сделало XML гораздо более привлекательным, и XPATH позволил нам делать много запросов в одной простой строке, а не ходить по дереву предков.

Мы программировали в среде Win32 и использовали стандартную библиотеку Microsoft DOM. Мы будем загружать все данные в память, анализировать их в дереве dom и искать, добавлять, изменять в копии памяти. Мы периодически сохраняем данные и должны поворачивать копии, если машина разбилась в середине записи.

Нам также необходимо было создать некоторые "индексы" вручную, используя карты дерева C++. Это, конечно, было бы тривиально делать с sql.

Обратите внимание, что размер данных в файловой системе был в 2-4 раза меньше, чем дерево dom в памяти.

К тому времени, когда данные достигли размера 10M-100M, у нас начались реальные проблемы. Интересно, что при всех размерах данных обработка XML была намного быстрее, чем оказалось sqlite (потому что это было в памяти, а не на жестком диске)! Проблема была на самом деле двоякой: во-первых, время загрузки действительно начало длиться. Нам нужно подождать минуту или около того, прежде чем данные будут в памяти, а карты будут построены. Конечно, после загрузки программа была очень быстрой. Вторая проблема заключалась в том, что вся эта память была привязана все время. Системы с несколькими сотнями мегабайт будут невосприимчивы к другим приложениям, хотя мы бежали очень быстро.

Мы фактически изучаем базу данных xml на базе файловой системы. Есть пара открытых исходных версий xml баз данных, мы попробовали их. Я никогда не пытался использовать коммерческую базу данных xml, поэтому я не могу комментировать их. К сожалению, мы никогда не смогли бы заставить базы данных xml работать вообще. Даже действие заселения базы данных сотнями мегабайтов xml занимало несколько часов... Возможно, мы использовали это неправильно. Другая проблема заключалась в том, что эти базы данных были довольно тяжеловесными. Они требовали Java и имели полную архитектуру клиентского сервера. Мы отказались от этой идеи.

Тогда мы нашли sqlite. Он решил наши проблемы, но по цене. Когда мы сначала подключили sqlite, проблемы с памятью и временем загрузки пропали. К сожалению, поскольку вся обработка теперь выполнялась на жестком диске, загрузка фоновой обработки шла вверх. Раньше мы даже не замечали загрузку процессора, теперь использование процессора было выше. Нам нужно было оптимизировать код и по-прежнему нужно хранить некоторые данные в памяти. Нам также потребовалось переписать многие простые запросы XPATH в виде сложных алгоритмов с несколькими алгоритмами.

Итак, вот краткое изложение того, что мы узнали.

• Для данных дерева XML гораздо проще запрашивать и изменять с помощью XPATH.

• Для небольших наборов данных (менее 10 МБ) XML сдул sqlite в производительности.

• Для больших наборов данных (более 10 М-100 М) время загрузки XML и использование памяти стали большой проблемой до такой степени, что некоторые компьютеры стали непригодными.

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

• SQLITE не имеет проблем с памятью XML dom, но, как правило, он медленнее обрабатывает данные (он находится на жестком диске, а не в памяти). (таблицы note-sqlite могут храниться в памяти, возможно, это сделало бы это как можно быстрее.... Мы не пробовали это, потому что хотели получить данные из памяти.)

• Сохранение и запрос данных дерева в таблице не являются приятными. Тем не менее, управление транзакциями и индексация частично компенсирует это.

Ответ 3

Не забывайте, что у вас есть отличная база данных под рукой: файловая система!

Многие программисты забывают, что у достойной структуры каталога файла есть /:

• Быстро как ад
• Он переносится
• У этого крошечного рабочего времени

Люди говорят о разделении XML файлов на несколько XML файлов... Я бы рассмотрел разделение вашего XML на несколько каталогов и несколько файлов с открытым текстом.

Отправляйся. Он освежает быстро.

Ответ 4

Я бы не использовал XML для хранения элементов RSS. Устройство чтения каналов постоянно обновляет данные, получая данные.

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

Также, что произойдет, если ваше приложение выйдет из строя? если вы используете XML, какое состояние - данные в файле XML в сравнении с данными в памяти. По крайней мере, с SQLite вы получаете атомарность, поэтому вы уверены, что ваше приложение начнется с того же состояния, что и при создании последней записи базы данных.

Ответ 5

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

Ответ 6

• Используйте XML для данных, которые приложение должно знать - конфигурации, регистрации и что нет.
• Использовать базы данных (oracle, SQL-сервер и т.д.) для данных, которые пользователь взаимодействует напрямую или косвенно - реальные данные
• Используйте SQLite, если пользовательские данные больше сериализованной коллекции - вроде огромный список файлов и их содержание или сбор элементов электронной почты и т.д. SQLite хорош в этом.

Зависит от вида и размера данных.

Ответ 7

Когда XML следует использовать для сохранения данных вместо базы данных? Больше никогда. XML - это язык передачи данных. Он медленно разбирается и неловко запрашивает. Разберите XML (не отбрасывайте его!) И конвертируйте полученные данные в объекты домена. Затем сохраняйте объекты домена. Основным преимуществом базы данных для сохранения является SQL, что означает неструктурированные запросы и доступ к общим инструментам и методам оптимизации.

Ответ 8

Для меня это действительно зависит от того, что вы делаете с ними, сколько пользователей/процессов нужно иметь к ним доступ одновременно и т.д.

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

SO действительно это баланс.

Ответ 9

Если вам понадобится масштабировать, используйте базы данных.

Ответ 10

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

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

Например, веб-сервер хранит данные приложения в файле XML, и вам действительно не нужно выполнять сложный поиск, обновлять файл. Веб-сервер запускается, читает xml файл и это. Итак, XML здесь совершенен. Предположим, вы используете фреймворк вроде Struts. Вам нужно использовать XML, а настройки действий не изменяются, как только приложение будет разработано и развернуто. Таким образом, XML файл является хорошим способом. Теперь, если ваше приложение Struts разработало приложение для расширенного поиска и обновления, удаления, то SQL является оптимальным способом.

В любом случае, вы обязательно встретите одного или двух разработчиков в вашей организации, которые будут повторять только XML или SQL и объявлять XML или SQL как единственный способ. Остерегайтесь таких людей и делайте то, что "чувствует" право на ваше приложение. Не просто следуйте "технологической религии".

Подумайте о том, как часто вам нужно обновлять данные, как часто вам приходится искать данные. Затем вы получите ответ на использование - XML ​​или SQL.

Ответ 11

Я перешел на SQLite, и я чувствую себя намного лучше, зная его в базе данных.

В этом есть много других преимуществ:

• Добавление новых элементов очень просто.
• Сортировка по нескольким столбцам
• Удаление дубликатов с уникальным индексом

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

Я также сравнивал xml vs sqlite с помощью класса StopWatch, а sqlite быстрее, , хотя может быть просто, что мой способ разбора XML файлов был не самым быстрым методом.

• Маленькие # элементы и размер (25 элементов, 30kb)
  • ~ 1,5 мс sqlite
  • ~ 8.0 ms xml
• Большое количество элементов (700 элементов, 350kb)
  • ~ 20 мс sqlite
  • ~ 25 ms xml
• Большой размер файла (850 элементов, 1024kb)
  • ~ 45 мс sqlite
  • ~ 60 мс xml

Ответ 12

Я согласен с @Bradley.

XML очень медленный и не особенно полезный в качестве формата хранения. Зачем беспокоиться? Будете ли вы редактировать данные вручную с помощью текстового редактора? Если это так, XML по-прежнему не очень удобный формат по сравнению с чем-то вроде YAML. С чем-то вроде SQlite, запросы легче писать, и там есть четко определенный API для ввода и вывода ваших данных.

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

Все вышеизложенное означает, что ваш вопрос о том, "когда накладные расходы базы данных оправданы", является довольно спорным. XML имеет все более высокие издержки, все время, чем SQlite. (Полные базы данных, такие как MSSQL, более тяжелые, особенно в административных издержках, но это совершенно другой вопрос.)

Ответ 13

XML может храниться как текст и формат двоичного файла.

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

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

Что можно ускорить, это использовать базу данных/тип базы данных. Sqlite имеет этот вариант.

И это звучит как лучший способ сделать это за вас.

Ответ 14

Мое мнение заключается в том, что вы должны использовать SQLite (или другую подходящую встроенную базу данных) в любое время, когда вам не нужен формат текстового файла. Заметьте, это довольно большое исключение. Существует много сценариев, которые требуют форматов файлов с чистым текстом или могут быть использованы.

Что касается накладных расходов, SQLite компилируется примерно в 250 к с нормальными флагами. Многие библиотеки разбора XML больше, чем SQLite. Вы не получаете выигрышей concurrency, используя XML. Формат бинарного файла SQLite будет поддерживать гораздо более эффективную запись (в основном потому, что вы не можете добавить к концу хорошо отформатированный XML файл). И даже чтение данных, большинство из которых я предполагаю, является довольно случайным доступом, будет быстрее использовать SQLite.

И, прежде всего, вы получаете доступ к преимуществам SQL, как транзакции и индексы.

Изменить: Забыл упомянуть. Одним из преимуществ SQLite (в отличие от многих баз данных) является то, что он позволяет любому типу в любой строке в любом столбце. В принципе, с SQLite вы получаете ту же свободу, что и у вас с XML с точки зрения типов данных. Это также означает, что вам не нужно беспокоиться о том, чтобы ограничить текстовые столбцы.

Ответ 15

Следует отметить, что многие крупные реляционные базы данных (Oracle и SQLServer) имеют типы данных XML для хранения данных в базе данных и используют XPath в инструкции SQL для получения доступа к этим данным.

Кроме того, существуют встроенные базы данных XML, которые очень похожи на SQLite в том смысле, что они представляют собой один двоичный файл, содержащий коллекцию документов (это может быть примерно таблица), тогда вы можете либо XPath/XQuery на одном документе, либо цельный коллекция. Таким образом, с помощью базы данных XML вы можете делать такие вещи, как хранение данных дней в виде отдельного XML-документа в коллекции... поэтому вам просто нужно использовать этот документ, когда вы работаете с данными на сегодняшний день. Но напишите XQuery, чтобы выяснить исторические данные о сборе документов для этого человека. Slick.

Я использовал Berkeley XMLDB (теперь поддерживается Oracle). Есть и другие, если вы ищете google для "Native XML Database". Я не видел проблемы с сохранением/извлечением данных таким образом.

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

Если ваш поиск идет с db. Вы могли бы разбить файлы xml на каталоги, чтобы облегчить поиск, но управленческие накладные расходы легко становятся довольно тяжелыми. Вы также получаете намного больше, чем просто производительность с sql db...