it-swarm-pt.tech

Xml ou Sqlite, quando soltar Xml para um banco de dados?

Eu realmente gosto do Xml para salvar dados, mas quando o sqlite/database se torna a melhor opção? por exemplo, quando o xml tiver mais de x itens ou for maior que y MB?

Estou codificando um leitor de rss e acredito que fiz a escolha errada ao usar xml em um banco de dados sqlite para armazenar um cache de todos os itens dos feeds. Existem alguns feeds que têm um arquivo xml de ~ 1mb após um mês, outro tem mais de 700 itens, enquanto a maioria possui apenas ~ 30 itens e tem ~ 50kb de tamanho após um vários meses.

No momento, não tenho planos de implementar um limite, porque gosto de poder pesquisar tudo.

Então, minhas perguntas são:

  1. Quando a sobrecarga do sqlite/bancos de dados se justifica usando xml?
  2. Os poucos arquivos xml grandes são justificativas suficientes para o banco de dados quando existem muitos pequenos uns, embora até os pequenos cresçam com o tempo? (um longo longo tempo)

atualizado (mais informações)

Sempre que um feed é selecionado na GUI, recarrego todos os itens desse arquivo xml de feeds.

Também preciso modificar o status de leitura/não lida, que parece realmente hackeado quando percorro todos os nós no xml para encontrar o item e configurá-lo para leitura/não lida.

49
sieben

Eu basicamente concordo com Mitchel , que isso pode ser altamente específico, dependendo do que você fará com XML/sqlite. Para o seu caso (cache), parece-me que o uso do sqlite (ou outros dbs incorporados) faz mais sentido.

Primeiro, eu realmente não acho que o sqlite precisará de mais sobrecarga que o XML. E quero dizer a sobrecarga de tempo de desenvolvimento e de tempo de execução. O único problema é que você depende da biblioteca sqlite. Mas como você precisaria de alguma biblioteca para XML de qualquer maneira, isso não importa (presumo que o projeto esteja em C/C++).

Vantagens do sqlite sobre o xml:

  • tudo em um arquivo,
  • a perda de desempenho é menor que o XML à medida que o cache aumenta,
  • você pode manter os metadados do feed separados do próprio cache (outra tabela), mas acessíveis da mesma maneira,
  • É provavelmente mais fácil trabalhar com SQL do que XPath para a maioria das pessoas.

Desvantagens do sqlite:

  • pode ser problemático com vários processos acessando o mesmo banco de dados (provavelmente não é o seu caso),
  • você deve conhecer pelo menos o SQL básico. A menos que haja centenas de milhares de itens no cache, acho que você não precisará otimizar muito,
  • talvez de alguma forma possa ser mais perigoso do ponto de vista de segurança (injeção de SQL). Por outro lado, você não está codificando um aplicativo da Web, portanto isso não deve acontecer.

Provavelmente, outras coisas estão a par das duas soluções.

Para resumir, respostas para suas perguntas, respectivamente:

  1. Você não saberá, a menos que teste seu aplicativo específico com os dois back-ends. Caso contrário, é sempre apenas um palpite. O suporte básico para ambos os caches não deve ser um problema para codificar. Em seguida, faça benchmark e compare.

  2. Devido à maneira como os arquivos XML são organizados, as pesquisas do sqlite devem sempre ser mais rápidas (exceto alguns casos em que não importa, porque é incrivelmente rápido). Acelerar pesquisas em XML exigiria um banco de dados de índice de qualquer maneira, no seu caso, isso significaria ter cache para cache, não uma idéia particularmente boa. Mas com o sqlite você pode ter a indexação como parte do banco de dados.

21
Stan

Cara, eu tenho experiência com isso. Eu trabalho em um projeto em que originalmente armazenamos todos os nossos dados usando XML e depois fomos para o sqlite. Existem muitos prós e contras em cada tecnologia, mas foi o desempenho que causou a transição. Aqui está o que observamos.

Para bancos de dados pequenos (alguns meg ou menos), o XML era muito mais rápido e fácil de lidar. Nossos dados estavam naturalmente em um formato de árvore, o que tornava o XML muito mais atraente, e o XPATH nos permitiu fazer muitas consultas em uma linha simples, em vez de ter que descer por uma árvore ancestral.

Estávamos programando em um ambiente Win32 e usamos a biblioteca padrão do Microsoft DOM. Carregaríamos todos os dados na memória, analisá-los em uma árvore dom e pesquisar, adicionar, modificar na cópia na memória. Periodicamente, salvávamos os dados e precisávamos rotacionar cópias caso a máquina travasse no meio de uma gravação.

Também precisamos criar alguns "índices" manualmente, usando mapas em árvore do C++. Isso, é claro, seria trivial a ver com o sql.

Observe que o tamanho dos dados no sistema de arquivos era um fator 2-4 menor que a árvore de dom "in memory".

Quando os dados chegaram ao tamanho de 10M a 100M, começamos a ter problemas reais. Curiosamente, em todos os tamanhos de dados, o processamento XML era muito mais rápido do que o sqlite era (porque estava na memória, não no disco rígido)! Na verdade, o problema era duplo - o tempo de carregamento realmente começou a demorar muito. Precisávamos esperar um minuto ou mais para que os dados estivessem na memória e os mapas fossem construídos. Obviamente, uma vez carregado, o programa foi muito rápido. O segundo problema era que toda essa memória estava ligada o tempo todo. Os sistemas com apenas algumas centenas de meg não responderiam em outros aplicativos, apesar de termos corrido muito rápido.

Na verdade, estamos pensando em usar um banco de dados xml baseado em sistema de arquivos. Existem algumas versões de código aberto de bancos de dados xml, que foram testadas. Eu nunca tentei usar um banco de dados xml comercial, por isso não posso comentar sobre eles. Infelizmente, nunca conseguimos que os bancos de dados xml funcionassem bem. Até o ato de preencher o banco de dados com centenas de meg xml levou horas ... Talvez o estivéssemos usando incorretamente. Outro problema foi que esses bancos de dados eram bastante pesados. Eles exigiram Java e tinham arquitetura de servidor cliente completa. Desistimos dessa idéia.

Encontramos sqlite então. Resolveu nossos problemas, mas a um preço. Quando conectamos o sqlite inicialmente, os problemas de memória e tempo de carregamento desapareceram. Infelizmente, como todo o processamento foi feito no disco rígido, a carga de processamento em segundo plano aumentou bastante. Enquanto antes nem percebíamos a carga da CPU, agora o uso do processador estava muito alto. Precisávamos otimizar o código e ainda manter alguns dados na memória. Também é necessário reescrever muitas consultas XPATH simples como algoritmos de múltiplas consultas complicadas.

Então, aqui está um resumo do que aprendemos.

  1. Para dados em árvore, o XML é muito mais fácil de consultar e modificar usando XPATH.

  2. Para conjuntos de dados pequenos (menos de 10 milhões), o XML eliminou o sqlite no desempenho.

  3. Para conjuntos de dados grandes (maiores que 10M-100M), o tempo de carregamento de XML e o uso de memória se tornaram um grande problema, a ponto de alguns computadores se tornarem inutilizáveis.

  4. Não foi possível obter nenhum banco de dados xml de código-fonte aberto para corrigir os problemas associados a grandes conjuntos de dados.

  5. O SQLITE não tem os problemas de memória do XML dom, mas geralmente é mais lento no processamento dos dados (está no disco rígido, não na memória). (as tabelas note- sqlite podem ser armazenadas na memória, talvez isso o tornasse o mais rápido possível ... Não tentamos isso porque queríamos obter os dados da memória.)

  6. Armazenar e consultar dados de árvore em uma tabela não é agradável. No entanto, o gerenciamento de transações e a indexação compensam parcialmente.

38
Jim

Não esqueça que você tem um ótimo banco de dados ao seu alcance: o sistema de arquivos!

Muitos programadores esquecem que uma estrutura decente de arquivos de diretório é/possui:

  1. É rápido como o inferno
  2. É portátil
  3. Tem uma pequena pegada de tempo de execução

As pessoas estão falando em dividir arquivos XML em vários arquivos XML ... Eu consideraria dividir seu XML em vários diretórios e vários arquivos de texto sem formatação.

Dê uma chance. É incrivelmente rápido.

12
Oli
  1. Use XML para dados que o aplicativo deve conhecer - configuração, registro e quais não.
  2. Use bancos de dados (Oracle, SQL server etc.) para dados com os quais o usuário interage direta ou indiretamente - dados reais
  3. Use o SQLite se os dados do usuário forem mais de uma coleção serializada - como uma lista enorme de arquivos e seu conteúdo ou coleção de itens de email etc. O SQLite é bom nisso.

Depende do tipo e do tamanho dos dados.

6
Vin

Eu não usaria XML para armazenar itens de RSS. Um leitor de feeds faz atualizações constantes à medida que recebe dados.

Com o XML, você precisa carregar os dados do arquivo primeiro, analisá-los e armazená-los para facilitar a pesquisa/recuperação/atualização. Parece um banco de dados ...

Além disso, o que acontece se o seu aplicativo falhar? se você usa XML, qual estado são os dados no arquivo XML versus os dados na memória. Pelo menos com o SQLite, você obtém atomicidade, portanto, você tem certeza de que seu aplicativo iniciará com o mesmo estado de quando foi feita a última gravação no banco de dados.

5
typicalrunt

O XML é melhor usado como um formato de intercâmbio quando você precisa mover dados do seu aplicativo para outro lugar ou compartilhar informações entre aplicativos. Um banco de dados deve ser o método preferido de armazenamento para praticamente qualquer tamanho de aplicativo.

5
Bradley Harris

Quando o XML deve ser usado para persistência de dados em vez de um banco de dados? Quase nunca. XML é uma linguagem de transporte de dados. É lento para analisar e estranho para consultar. Analise o XML (não o destrua!) E converta os dados resultantes em objetos de domínio. Em seguida, persista os objetos do domínio. Uma grande vantagem de um banco de dados para persistência é o SQL, o que significa consultas não estruturadas e acesso a ferramentas e técnicas de otimização comuns.

4
David Medinets

Eu mudei para o SQLite e me sinto muito melhor sabendo que está em um banco de dados.

Existem muitos outros benefícios disso:

  • Adicionar novos itens é realmente simples
  • Classificando por várias colunas
  • Removendo Duplicatas com um Índice Único

Criei duas visualizações, uma para itens não lidos e uma para todos os itens, sem saber se esse é o melhor uso das visualizações, mas eu realmente queria tentar usá-las.

Também comparei o xml vs o sqlite usando a classe StopWatch, e o sqlite é mais rápido, embora possa ser que minha maneira de analisar arquivos xml não seja o método mais rápido .

  1. Pequenos # itens e tamanho (25 itens, 30kb)
    • ~ 1.5 ms sqlite
    • ~ 8,0 ms xml
  2. Grande número de itens (700 itens, 350kb)
    • ~ 20 ms sqlite
    • ~ 25 ms xml
  3. Tamanho de arquivo grande (850 itens, 1024kb)
    • ~ 45 ms sqlite
    • ~ 60 ms xml
2
sieben

Se você precisar escalar a qualquer momento, use bancos de dados.

2
Mostlyharmless

Para mim, realmente depende do que você está fazendo com eles, quantos usuários/processos precisam acessar a eles ao mesmo tempo etc.

Trabalho com arquivos XML grandes o tempo todo, mas eles são processos únicos, itens de estilo de importação, que o multiusuário ou o desempenho não são realmente necessários.

Então, realmente é um equilíbrio.

2
Mitchel Sellers

XML é bom para armazenar dados que não estão completamente estruturados e você normalmente deseja trocá-los com outro aplicativo. Eu prefiro usar um banco de dados SQL para dados. XML é propenso a erros, pois você pode causar erros sutis devido a erros de digitação ou omissões nos próprios dados. Algumas estruturas de aplicativos de código aberto usam muitos arquivos xml para configuração, dados etc. Eu prefiro tê-lo no SQL.

Como você solicita uma regra de ouro, eu diria que use dados de aplicativos baseados em XML, configuração, etc., se você for configurá-lo uma vez e não acessar/pesquisar muito. Para pesquisas e atualizações ativas, é melhor usar o SQL.

Por exemplo, um servidor da Web armazena dados de aplicativos em um arquivo XML e você realmente não precisa realizar pesquisas complexas, atualize o arquivo. O servidor da web inicia, lê o arquivo xml e é isso. Portanto, XML é perfeito aqui. Suponha que você use uma estrutura como o Struts. Você precisa usar XML e as configurações de ação não mudam muito quando o aplicativo é desenvolvido e implementado. Então, novamente, o arquivo XML é uma boa maneira. Agora, se o aplicativo desenvolvido do Struts permitir pesquisas e atualizações extensas, exclusões, o SQL é a maneira ideal.

É claro que você certamente encontrará um ou dois desenvolvedores em sua organização que cantarão apenas XML ou SQL e proclamarão XML ou SQL como o único caminho a percorrer. Cuidado com essas pessoas e faça o que 'parece' adequado para a sua aplicação. Não basta seguir uma 'religião da tecnologia'.

Pense em coisas como a frequência com que você precisa atualizar os dados, a frequência com que precisa pesquisar os dados. Então você terá sua resposta sobre o que usar - XML ​​ou SQL.

2
echarcha

Eu concordo com @Bradley.

XML é muito lento e não é particularmente útil como formato de armazenamento. Porque se importar? Você editará os dados manualmente usando um editor de texto? Nesse caso, XML ainda não é um formato muito conveniente comparado a algo como YAML. Com algo como o SQlite, as consultas são mais fáceis de escrever, e há uma API bem definida para a entrada e saída de dados.

XML é bom se você precisar enviar dados entre os programas. Mas, em nome da eficiência, você provavelmente deve produzir o XML no momento do envio e analisá-lo em "dados reais" no momento do recebimento.

Tudo acima significa que sua pergunta sobre "quando a sobrecarga de um banco de dados é justificada" é meio que discutível. O XML tem uma sobrecarga muito maior, o tempo todo, do que o SQlite. (Bancos de dados completos, como o MSSQL, são mais pesados, principalmente em sobrecarga administrativa, mas essa é uma pergunta totalmente diferente.)

1
apenwarr

XML pode ser armazenado como texto e como um formato de arquivo binário.

Se seu objetivo principal é permitir que um computador leia/grave um formato de arquivo com eficiência, você deve trabalhar com um formato de arquivo binário.

Os bancos de dados são uma maneira fácil de usar de armazenar e manter dados. Eles não são a maneira mais rápida de armazenar dados em um formato de arquivo binário.

O que pode acelerar as coisas é usar um banco de dados na memória/tipo de banco de dados. Sqlite tem essa opção.

E isso soa como a melhor maneira de fazer isso por você.

1
Mischa Kroon

Minha opinião é que você deve usar o SQLite (ou outro banco de dados incorporado apropriado) sempre que não precisar de um formato de arquivo de texto puro. Observe que essa é uma grande exceção. Existem muitos cenários que exigem ou são beneficiados por formatos de arquivo de texto puro.

Quanto à sobrecarga, o SQLite compila para algo como 250 k com sinalizadores normais. Muitas bibliotecas de análise XML são maiores que o SQLite. Você não obtém ganhos de simultaneidade usando XML. O formato de arquivo binário SQLite suportará gravações muito mais eficientes (principalmente porque você não pode anexar ao final de um arquivo XML bem formatado). E até mesmo a leitura de dados, a maioria dos quais suponho que seja um acesso bastante aleatório, será mais rápida usando o SQLite.

Além disso, você obtém acesso aos benefícios do SQL, como transações e índices.

Edit: Esqueci de mencionar. Um benefício do SQLite (ao contrário de muitos bancos de dados) é que ele permite qualquer tipo em qualquer linha em qualquer coluna. Basicamente, com o SQLite, você obtém a mesma liberdade que possui com XML em termos de tipos de dados. Isso também significa que você não precisa se preocupar em colocar limites nas colunas de texto.

1
Jay Stramel

Um banco de dados é excelente como parte do seu programa. Se a consulta dos dados fizer parte da sua lógica de negócios. O XML é melhor como formato de arquivo, especialmente se o formato dos dados for:

1, hierárquico
2, É provável que mude no futuro de maneiras que você não consegue adivinhar
3, Os dados permanecerão mais tempo do que o programa

1
Martin Beckett

Você deve observar que muitos bancos de dados relacionais grandes (Oracle e SQLServer) possuem tipos de dados XML para armazenar dados em um banco de dados e usar XPath na instrução SQL para obter acesso a esses dados.

Além disso, existem bancos de dados XML nativos que funcionam muito como o SQLite no sentido de que são um arquivo binário que contém uma coleção de documentos (que pode ser uma tabela), então você pode XPath/XQuery em um único documento ou em toda a coleção. Portanto, com um banco de dados XML, você pode fazer coisas como armazenar os dados do dia como um documento XML separado na coleção ... portanto, você só precisa usar esse documento ao lidar com os dados de hoje. Mas escreva um XQuery para descobrir dados históricos sobre a coleção de documentos para essa pessoa. Liso.

Eu usei o Berkeley XMLDB (agora suportado pela Oracle). Existem outros se você pesquisar no Google por "Banco de Dados XML Nativo". Não vi um problema de desempenho ao armazenar/recuperar dados dessa maneira.

O XQuery é um animal diferente (mas vale a pena aprender), no entanto, você pode usar os XPaths usados ​​atualmente com pequenas modificações.

1
Nika

Eu digo que não é uma questão de tamanho dos dados, mas de tipo de dados. Se seus dados forem estruturados, use um banco de dados relacional. Se seus dados forem semiestruturados, use XML ou - se a quantidade de dados realmente aumentar demais - um banco de dados XML.

0
Sebastian Redl

Se a sua pesquisa for com um db. Você pode dividir os arquivos xml em diretórios para facilitar a busca, mas a sobrecarga administrativa facilmente fica bastante pesada. Você também obtém muito mais do que apenas desempenho com um db sql ...

0
Andrew Taylor