Precisa de ajuda! Não consigo resolver o problema, estou atingindo limitações de hardware - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Pensei sobre isso. Pediu uma opinião:
Qual seria a velocidade em relação à leitura de um arquivo e qual seria a lentidão em relação ao trabalho em memória?
O SGBD coloca suas tabelas na memória sempre que possível.
mas não no seu caso, a menos que, é claro, você tenha 32 GB de RAM
Portanto, como colocar 20 GB em 4 GB é um verdadeiro desafio de otimização.
Se você quiser simplificar sua tarefa, faça um drive de RAM convencional na memória.
Se você não puder, então vá para um disco rígido.
Qual é a velocidade em relação à leitura de um arquivo e qual é a lentidão em relação ao trabalho na memória?
Bem, você não precisa apenas ler o arquivo, você também precisa pesquisar, calcular, converter texto em números, realizar a classificação, etc.
Em primeiro lugar, se os dados não forem atualizados com freqüência, você pode criar quantos índices quiser para os atributos envolvidos na pesquisa de dados (incluindo atributos agregados). Assim, a busca será mais rápida (usando índices), daí o cálculo também.
Em segundo lugar, digamos MySQL, MS SQL, Oracle e outros bancos de dados utilizam a tecnologia de cache de dados para consultas repetitivas, o que também dá alguma vantagem em termos de velocidade de processamento.
Em terceiro lugar, você pode dividir uma tabela em partes (divisórias), digamos, por anos. Assim, consultas selecionando dados por um ano não serão lidas/esquisitadas por dados localizados em outras partições.
Em quarto lugar, como seus dados de origem estão em forma de texto, quando você os carrega no banco de dados, eles devem ser menores em tamanho devido à conversão do tipo natural. Por exemplo, o número 124.223456221 em forma de texto levará 13 bytes, no banco de dados dependendo do tipo 4-8; data e hora "2014-08-17 10:23:35" levará 19 bytes, e no banco de dados 8 bytes.
Em quinto lugar, se você utiliza informações agregadas freqüentemente por determinados períodos, você pode agregar esses dados uma vez e armazená-los em outra tabela.
Claro, se estamos apenas falando de ler dados na memória, WinApi fará isso mais rápido, mas o que fazer com os dados depois? Imagine, mesmo para procurar a parte correta dos dados, você tem que ler todos os dados a partir do disco. Ou você tem que escrever a funcionalidade de indexação, classificar os dados no arquivo, criar arquivos de indexação para todas as operações de busca e reescrever metade da funcionalidade do SGBD. Para processar tal quantidade de dados e querer um desempenho razoável, é necessário.
Minha opinião é inequívoca - um SGBD de servidor (SGBD de arquivo como MS Access, SQLite não funcionará aqui) em uma máquina dedicada. Será razoável o desempenho e fácil de processar dados (consultas SQL). Caso contrário, você perderá muito tempo escrevendo "internos" de baixo nível para processar o arquivo.
Pensei sobre isso. Pediu uma opinião:
Qual seria a velocidade em relação à leitura de um arquivo e qual seria a lentidão em relação ao trabalho em memória?
( tenho experiência com bancos de dados acima de 3TB e bancos de dados relativamente anões de 10-100gigs )
mas com certo hardware ... digamos 64gb de RAM e superior com um bom subsistema de disco
Nesta situação, em comparação com trabalhar com um arquivo enorme
SQL irá acelerar consideravelmente, mas a velocidade dependerá das implementações de SQL, é claro
- projeto correto do banco de dados - índices corretos - configuração correta do banco de dados
isto significa divisão de arquivos (a maneira como elugovoy escreve sobre é verdade)
Uma implementação completa exigiria um servidor separado e um servidor de banco de dados OS - SQL
se o MS SQL não deve ser inferior a 2008 (em termos de software também é desejável não ser inferior a 64)
Mas, na minha opinião, será bastante trabalhoso e difícil de implementar... ( 64 bit é ideal)
--
Se você tiver apenas 16 gigs em sua máquina e ela for usada como estação
Basta colocar o servidor SQL nele não será ótimo - mas é melhor do que se preocupar com um arquivo de texto
Mas se você não tiver nenhuma experiência com SQL, será necessário algum esforço na implementação.
E se este arquivo for comprimido com um arquivador, qual será seu tamanho (porque o texto deve ser muito bem comprimido)?
O tempo necessário para descomprimir cada passe matará o desempenho
o tempo necessário para desarquivar cada passe matará o desempenho
Não me refiro ao desarquivamento. Se o arquivamento pode reduzir muito o volume, então faz sentido comprimir a informação em um arquivo índice.
originalmente era
E se este arquivo for comprimido com um arquivador, qual é o volume (afinal de contas, o texto deve comprimir muito bem) ?
daí a reação ao seu posto!
arquivo índice - criar... ?! esse é outro tópico
É ainda mais legal escrever seu próprio servidor (semelhante ao SQL) - mas por quê?
desde o início foi
daí a reação ao seu posto!
arquivo de índice - para criar... ?! esse é outro tópico
É ainda mais legal escrever seu próprio servidor (como SQL) - mas por quê?
A pergunta original para o autor foi o quanto o arquivo está comprimido. ....
Posso perguntar por quê?
Será comprimido em 70-80% e o que fará o autor para resolver o problema que descreveu?