Você também pode dar uma olhada no OpenTSDB , um sistema baseado no Hadoop para armazenar e recuperar dados em série. Eu nunca usei, mas parece útil e, pelo menos, perto dos seus propósitos.
Eu preciso criar um sistema para armazenar & manter uma quantidade enorme (20 [TB]) de dados de séries temporais (para muitos instrumentos diferentes), de modo a suportar os seguintes requisitos:
(1) fast appends of new data, as new data comes in e (2) fast retrievals of existing (already stored) data
Existem 10.000 instrumentos e 1000 campos de dados (atualizados a cada 1 minuto) para salvar para cada instrumento. Uma vez que os dados são gravados no disco, eles permanecem inalterados (sem problemas de escrita / leitura simultâneas).
Como não haveria necessidade de nenhuma junção (a consulta típica é: give me all instruments for field 'X' on interval 'Y' ), tenho a tendência de armazenar os dados usando arquivos binários planos que serão nomeados assim: fieldName.timeStamp.bin ; Dessa forma, eu seria capaz de armazenar todos os dados em arquivos binários planos (sem necessidade de uma despesa enorme para um servidor gigante / banco de dados comercial) e ainda assim, as consultas serão rápidas.
Como são muitos dados (cerca de 20 [TB]), achei que precisaria de alguma lógica para distribuir os arquivos ( fieldName.timeStamp.bin ) entre todas as minhas máquinas. Aqui está o que eu tinha em mente: haverá uma máquina central para a qual todas as consultas serão enviadas. essa máquina central (com base no campo & timestamp solicitado) encaminharia a consulta para a máquina de interesse, que por sua vez retornaria os dados solicitados.
Minhas perguntas são:
(1) is this design scalable as I think it is? any drawbacks?
(2) is there anything I am missing here that might hurt performance?
(3) is it really the best way to send all queries to a central machine, that would in turn route the query to the right machine? or would it be best to directly access the máquina correta (suponha que eu saiba qual deles é) using NFS ?
(4) is there a faster way than NFS to access the máquina correta to read data from it? are there other methods for sharing all the data that on the data machines with client machines?
Todas as minhas máquinas usam o Ubuntu Linux. Como pode ser entendido, haverá muitas máquinas client que acessariam os vários dados data machines e lidos (somente leitura, não gravação) a partir deles. meu objetivo é que os dados sejam lidos o mais rápido possível.
Você também pode dar uma olhada no OpenTSDB , um sistema baseado no Hadoop para armazenar e recuperar dados em série. Eu nunca usei, mas parece útil e, pelo menos, perto dos seus propósitos.
Sistema de Arquivos de Autoridade Menos Tahoe pode resolver muitos desses problemas automaticamente, especialmente se você puder trabalhar com suas ferramentas para recuperar os dados. Pelo menos, eu daria uma olhada antes de fazer meu próprio sistema. Sem dados sobre quais são os requisitos reais de largura de banda e latência, não posso dizer muito mais.
Algumas notas:
1) Usar um servidor centralizado parece desnecessário aqui. Por que não criar um hash do nome do arquivo e usar uma classificação simples para decidir qual servidor armazenar / obter os arquivos? Dessa forma, você não precisa de um servidor central para armazenar / gravar os arquivos.
2) Dada a escala do sistema sobre o qual você está falando, eu procuraria usar o Lustre ou o GLuster para fazer o material do sistema de arquivos para você em vez de usar o NFS. Deixe-os fazer o trabalho duro para você. Ambos são usados para sistemas muito maiores do que isso e têm um histórico sólido.
3) Se você decidir desempenhar sua própria configuração, eu daria uma boa olhada no OpenSolaris / Nexenta com o ZFS. Para sistemas de arquivos grandes, alguns pontos strongs do ZFS se tornam realmente úteis:
a) O ZFS faz reconstruções do raid intelegent. Posso reconstruir 16 TB de dados em uma configuração de unidade RAID 50 de 10x2 TB em 30 horas. O que é muito mais rápido do que se eu estivesse fazendo o mesmo tipo de reconstrução com um cartão RAID de hardware. b) O ZFS não precisa fsck, mesmo com o ext3 / 4 o fsck em partições grandes que será muito doloroso. c) O agendador de E / S do ZFS para gravações é muito strong. Você pode adicionar um único SSD para armazenar os logs do ZIL / cache do LARC2 e obter a maioria dos ganhos de um sistema de armazenamento baseado em SSD com a grande retenção de dados dos discos rígidos. d) O ZFS possui um servidor NFSv4 muito robusto integrado. O compartilhamento é fácil de configurar. e) O ZFS incorporou a desduplicação no nível do sistema de arquivos, o que pode ser uma grande vitória se as leituras dos instrumentos retornarem resultados semelhantes.
Tags networking linux ubuntu