Xml или Sqlite, когда отбрасывать Xml для базы данных?
Мне действительно нравится Xml для сохранения данных, но когда sqlite/database станет лучшим вариантом? Например, когда xml имеет более x элементов или больше, чем y MB?
Я пишу программу для чтения rss и считаю, что сделал неправильный выбор в использовании xml над базой данных sqlite для хранения кэша всех элементов каналов. Некоторые каналы имеют XML-файл размером ~1 МБ через месяц, другие содержат более 700 элементов, в то время как большинство из них содержат ~30 элементов и имеют размер ~50 КБ через несколько месяцев.
В настоящее время у меня нет планов по внедрению кепки, потому что мне нравится иметь возможность искать все.
Итак, мои вопросы:
- Когда накладные расходы на sqlite/database оправдываются использованием xml?
- Достаточно ли оправдания для нескольких больших XML-файлов для базы данных, когда есть много маленьких, хотя со временем даже маленькие будут расти? (очень долго)
обновлено (подробнее)
Каждый раз, когда канал выбирается в графическом интерфейсе, я перезагружаю все элементы из этого XML-файла каналов.
Мне также нужно изменить состояние чтения / непрочитанного, которое кажется действительно странным, когда я перебираю все узлы в xml, чтобы найти элемент, а затем устанавливаю его на чтение / непрочитанное.
18 ответов
Я в основном согласен с Митчелом, что это может быть очень специфично в зависимости от того, что вы собираетесь делать с XML/sqlite. Для вашего случая (кеша) мне кажется, что использование sqlite (или других встроенных БД) имеет больше смысла.
Во-первых, я не думаю, что sqlite потребует больше накладных расходов, чем XML. И я имею в виду как накладные расходы времени разработки, так и накладные расходы времени выполнения. Единственная проблема в том, что у вас есть зависимость от библиотеки sqlite. Но поскольку вам все равно понадобится некоторая библиотека для XML, это не имеет значения (я предполагаю, что проект находится на C/C++).
Преимущества sqlite перед xml:
- все в одном файле,
- потеря производительности ниже, чем XML, поскольку кэш увеличивается,
- вы можете хранить метаданные фида отдельно от самого кэша (другой таблицы), но доступным таким же образом,
- С SQL, вероятно, легче работать, чем с XPath для большинства людей.
Недостатки sqlite:
- может быть проблематично с несколькими процессами, обращающимися к одной и той же базе данных (вероятно, не ваш случай),
- Вы должны знать хотя бы базовый SQL. Если в кеше не будет сотен тысяч элементов, я не думаю, что вам нужно будет много оптимизировать,
- может быть, в некотором роде это может быть более опасным с точки зрения безопасности (инъекция SQL). С другой стороны, вы не кодируете веб-приложение, поэтому этого не должно происходить.
Вероятно, для обоих решений все в порядке.
Подводя итог, ответьте на ваши вопросы соответственно:
Вы не узнаете, если не протестируете свое конкретное приложение с обоими бэкэндами. В противном случае это всегда только предположение. Базовая поддержка обоих кешей не должна быть проблемой для кода. Затем сравните и сравните.
Из-за того, как организованы XML-файлы, поиск sqlite всегда должен быть быстрее (за исключением некоторых угловых случаев, когда это все равно не имеет значения, потому что это невероятно быстро). Ускорение поиска в XML в любом случае потребует индексной базы данных, в вашем случае это будет означать наличие кеша для кеша, что не очень хорошая идея. Но с sqlite вы можете иметь индексирование как часть базы данных.
Человек у меня есть опыт с этим. Я работаю над проектом, в котором мы изначально хранили все наши данные с использованием 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.
Для больших наборов данных (больше 10M-100M) время загрузки XML и использование памяти стали большой проблемой, в результате чего некоторые компьютеры стали непригодными для использования.
Мы не смогли получить какую-либо базу данных XML с открытым исходным кодом для решения проблем, связанных с большими наборами данных.
SQLITE не имеет проблем с памятью XML dom, но обычно он медленнее обрабатывает данные (он находится на жестком диске, а не в памяти). (примечание: таблицы sqlite могут храниться в памяти, возможно, это сделает это так быстро... Мы не пытались сделать это, потому что хотели извлечь данные из памяти.)
Хранить и запрашивать данные дерева в таблице не очень приятно. Однако управление транзакциями и индексация частично компенсируют это.
Не забывайте, что у вас есть отличная база данных: файловая система!
Многие программисты забывают, что приличная структура файлов каталогов имеет / имеет:
- Это быстро, как ад
- Это портативный
- Имеет крошечный след времени выполнения
Люди говорят о разделении XML-файлов на несколько XML-файлов... Я хотел бы разделить ваш XML-файл на несколько каталогов и несколько текстовых файлов.
Попробуй. Это очень быстро
- Используйте XML для данных, которые приложение должно знать - конфигурация, ведение журнала, а что нет.
- Используйте базы данных (оракул, сервер SQL и т. Д.) Для данных, с которыми пользователь взаимодействует прямо или косвенно - реальных данных
- Используйте SQLite, если пользовательские данные представляют собой скорее сериализованную коллекцию - например, огромный список файлов и их содержимое, либо коллекцию элементов электронной почты и т. Д. SQLite хорош в этом.
Зависит от вида и размера данных.
Я переключился на SQLite и чувствую себя намного лучше, зная, что он находится в базе данных.
Есть много других преимуществ от этого:
- Добавить новинки действительно просто
- Сортировка по нескольким столбцам
- Удаление дубликатов с уникальным индексом
Я создал 2 вида: один для непрочитанных и один для всех, но я не уверен, что это наилучший вид, но я действительно хотел попробовать их использовать.
Я также сравнил xml и sqlite с помощью класса StopWatch, и sqlite работает быстрее, хотя может случиться так, что мой способ синтаксического анализа xml-файлов был не самым быстрым.
- Мелкие # шт и размер (25 шт, 30кб)
- ~ 1,5 мс sqlite
- ~ 8,0 мс xml
- Большое количество элементов (700 элементов, 350 КБ)
- ~ 20 мс квлит
- ~25 мс xml
- Большой размер файла (850 элементов, 1024 КБ)
- ~ 45 мс квлит
- ~60 мс xml
XML лучше всего использовать в качестве формата обмена, когда вам нужно переместить данные из вашего приложения в другое место или обмениваться информацией между приложениями. База данных должна быть предпочтительным способом хранения для приложений практически любого размера.
Я бы не стал использовать XML для хранения элементов RSS. Читатель ленты новостей постоянно обновляется по мере получения данных.
При использовании XML вам необходимо сначала загрузить данные из файла, проанализировать их, а затем сохранить для облегчения поиска / поиска / обновления. Звучит как база данных...
Кроме того, что произойдет, если ваше приложение вылетает? если вы используете XML, в каком состоянии находятся данные в файле XML по сравнению с данными в памяти. По крайней мере, с SQLite вы получаете атомарность, поэтому вы уверены, что ваше приложение запустится с тем же состоянием, что и при последней записи в базу данных.
Когда следует использовать XML для сохранения данных вместо базы данных? Почти никогда. XML является языком передачи данных. Это медленный анализ и неловкий запрос. Разберите XML (не разбивайте его!) И преобразуйте полученные данные в объекты домена. Затем сохраните доменные объекты. Основным преимуществом базы данных для постоянства является SQL, что означает неструктурированные запросы и доступ к общим инструментам и методам оптимизации.
Для меня это действительно зависит от того, что вы делаете с ними, скольким пользователям / процессам необходим доступ к ним одновременно и т. Д.
Я все время работаю с большими XML-файлами, но они представляют собой отдельный процесс, элементы стиля импорта, которые многопользовательские или производительные не нужны.
ТАК действительно, это баланс.
Если вам когда-нибудь понадобится масштабировать, используйте базы данных.
XML хорош для хранения данных, которые не полностью структурированы, и вы обычно хотите обмениваться ими с другим приложением. Я предпочитаю использовать базу данных SQL для данных. XML подвержен ошибкам, так как вы можете вызвать незначительные ошибки из-за опечаток или пропусков в самих данных. Некоторые платформы приложений с открытым исходным кодом используют слишком много XML-файлов для конфигурации, данных и т. Д. Я предпочитаю иметь это в SQL.
Поскольку вы запрашиваете практическое правило, я бы сказал, что используйте данные приложения на основе XML, конфигурацию и т. Д., Если вы собираетесь настроить его один раз, а не осуществлять к нему доступ или искать его много. Для активных поисков и обновлений лучше всего использовать SQL.
Например, веб-сервер хранит данные приложения в файле XML, и вам не нужно выполнять сложный поиск, обновите файл. Веб-сервер запускается, читает XML-файл и все. Так что XML здесь идеален. Предположим, вы используете фреймворк, такой как Struts. Вам необходимо использовать XML, и конфигурации действий не сильно изменятся после разработки и развертывания приложения. Итак, еще раз, XML-файл является хорошим способом. Теперь, если ваше приложение, разработанное Struts, допускает расширенные поиски и обновления, удаления, тогда SQL является оптимальным способом.
Конечно, вы наверняка встретите одного или двух разработчиков в вашей организации, которые будут петь только XML или SQL и провозглашать XML или SQL единственным выходом. Остерегайтесь таких людей и делайте то, что чувствует себя правильным для вашего заявления. Не просто следуйте "технологической религии".
Подумайте о том, как часто вам нужно обновлять данные, как часто вам нужно искать данные. Тогда у вас будет свой ответ о том, что использовать - XML или SQL.
Я считаю, что вы должны использовать SQLite (или другую подходящую встроенную базу данных) всякий раз, когда вам не нужен чисто текстовый формат файла. Обратите внимание, это довольно большое исключение. Существует множество сценариев, которые требуют или получают пользу от чисто текстовых форматов файлов.
Что касается накладных расходов, SQLite компилирует что-то вроде 250 k с нормальными флагами. Многие библиотеки синтаксического анализа XML больше, чем SQLite. Вы не получаете выгоды от параллелизма, используя XML. Бинарный формат файла SQLite будет поддерживать гораздо более эффективные записи (в основном потому, что вы не можете добавить конец хорошо отформатированного файла XML). И даже чтение данных, большая часть которых, как я полагаю, представляет собой довольно произвольный доступ, будет быстрее с использованием SQLite.
И в довершение всего, вы получаете доступ к таким преимуществам SQL, как транзакции и индексы.
Изменить: забыл упомянуть. Одним из преимуществ SQLite (в отличие от многих баз данных) является то, что он допускает любой тип в любой строке в любом столбце. По сути, с SQLite вы получаете ту же свободу, что и с XML, с точки зрения типов данных. Это также означает, что вам не нужно беспокоиться о наложении ограничений на текстовые столбцы.
Я согласен с @Bradley.
XML очень медленный и не особенно полезен в качестве формата хранения. Зачем беспокоиться? Будете ли вы редактировать данные вручную с помощью текстового редактора? Если это так, XML все еще не очень удобный формат по сравнению с чем-то вроде YAML. С чем-то вроде SQlite, запросы легче писать, и есть четко определенный API для ввода и вывода ваших данных.
XML - это хорошо, если вам нужно передавать данные между программами. Но во имя эффективности вы, вероятно, должны создавать XML во время отправки и анализировать его в "реальные данные" во время приема.
Все вышеперечисленное означает, что ваш вопрос о "когда накладные расходы на базу данных оправданы" является своего рода спорным. У XML все время намного больше издержек, чем у SQlite. (Полноценные базы данных, такие как MSSQL, тяжелее, особенно из-за административных издержек, но это совершенно другой вопрос.)
XML может быть сохранен как текст и как двоичный формат файла.
Если ваша основная задача - дать компьютеру возможность эффективно читать / записывать формат файла, вам следует работать с двоичным форматом файла.
Базы данных - это простой в использовании способ хранения и поддержки данных. Это не самый быстрый способ хранения данных в двоичном формате.
Что может ускорить процесс, так это использование базы данных в памяти / типа базы данных. Sqlite имеет эту опцию.
И это звучит как лучший способ сделать это для вас.
Следует отметить, что многие большие реляционные БД (Oracle и SQLServer) имеют типы данных XML для хранения данных в базе данных и использования XPath в операторе SQL для получения доступа к этим данным.
Кроме того, существуют собственные базы данных XML, которые работают очень похоже на SQLite, в том смысле, что они представляют собой один двоичный файл, содержащий коллекцию документов (которая может быть приблизительно таблицей), тогда вы можете использовать XPath/XQuery для одного документа или всей коллекции. Таким образом, с базой данных XML вы можете делать такие вещи, как хранить данные о днях в виде отдельного XML-документа в коллекции... так что вам просто нужно использовать этот один документ, когда вы работаете с данными на сегодня. Но напишите XQuery, чтобы выяснить исторические данные о сборе документов для этого человека. Slick.
Я использовал Berkeley XMLDB (теперь поддерживается Oracle). Есть и другие, если вы ищете в Google "Native XML Database". Я не видел проблем с производительностью при сохранении / получении данных таким способом.
XQuery - это другой зверь (но его стоит изучить), однако вы можете просто использовать XPath, который вы используете в настоящее время, с небольшими изменениями.
База данных великолепна как часть вашей программы. Если запрос данных является частью вашей бизнес-логики. XML лучше всего подходит как формат файла, особенно если у вас формат данных:
1, Иерарх
2, вероятно, изменится в будущем таким образом, что вы не можете угадать
3, данные будут жить дольше, чем программа
Я говорю, что дело не в размере данных, а в типе данных. Если ваши данные структурированы, используйте реляционную базу данных. Если ваши данные частично структурированы, используйте XML или - если объем данных действительно становится слишком большим - базу данных XML.
Если ваш поиск идет с БД. Вы можете разбить XML-файлы на каталоги, чтобы упростить поиск, но административные издержки легко становятся довольно тяжелыми. Вы также получите гораздо больше, чем просто производительность с SQL DB...