Durante a refatoração de nossa troca de criptografia, foi decidido revisar o conceito de trabalhar com uma data de mercado. No caso clássico, a data do mercado é distribuída de duas maneiras:
1. interface REST;
2. Assinatura de transmissão WEBSocket.
O método REST é frequentemente usado para obter dados históricos, enquanto o WEBSocket envia informações on-line ao vivo. Em alguns casos, o WEBSocket não é utilizado e as atualizações são realizadas por solicitações regulares via REST.
E parece que todo mundo está feliz. Mas, após uma inspeção mais minuciosa, a enorme sobrecarga de tal conceito se torna aparente. O volume deles repousa sobre o REST. Para garantir o funcionamento da interface REST, precisamos criar um back-end que atenda aos requisitos de sistemas altamente carregados. Naturalmente, aqui você pode escolher várias opções de solução, do PHP ao Golang, agora na moda.
Também é necessário criar uma infraestrutura altamente acessível, implementar ninharias como CI / CD para serviços, fornecer tudo isso aos especialistas certos para desenvolvimento, manutenção, etc., etc.
Ao mesmo tempo, é a data histórica do mercado que ocupa a maior parte do espaço em disco. Geralmente é armazenado no banco de dados. Por um lado, isso nos permite resolver o problema do clustering, mas em tamanhos críticos, torna-se um fardo insuportável e apresenta tarefas não triviais para a equipe e os desenvolvedores do DevOps.
Em geral ... a aparente simplicidade e consistência desse conceito é destruída em uma vida dura.
Separadamente, é necessário observar a peculiaridade da data do mercado. Sempre acumula (cresce). I.e. no idioma do programador de banco de dados, sempre inserimos e selecionamos. Mas não divisível. I.e. maravilhosa funcionalidade de banco de dados para sistematização, otimização etc. Os dados armazenados tornam-se não reclamados.
Outra propriedade importante de uma data de mercado é sua estrutura claramente definida. Por exemplo, uma vela em um gráfico possui apenas oito parâmetros:
1. O momento do tempo;
2. Exposição;
3. O preço máximo;
4. O preço mínimo;
5. preço de abertura;
6. preço de fechamento;
7. volume;
8. preço médio
O mesmo pode ser dito sobre negócios.
Com base nesses pré-requisitos e também com experiência, cheguei rapidamente à conclusão de que é mais correto considerar a data do mercado como um fluxo estruturado.
Por exemplo, um fluxo com velas pode ser considerado como uma matriz de estruturas binárias:
moment: int32
exposition: int32
min: float64
max: float64
open: float64
close: float64
volume: float64
average: float64Total: 56 bytes.
Por exemplo, uma vela no JSON será descrita da seguinte maneira:
{ "date":1501004700, "high":0.08053391, "low":0.08020004, "open":0.08030001, "close":0.0803542, "volume":48.62169347, "weightedAverage":0.08038445 }
Total: 167 bytes.
Lucro em tamanho é óbvio. E isso é menos tráfego, maior velocidade de entrega para o cliente.
E aqui, é claro, o BSON vem à mente. Mas isso não resolve o problema da necessidade de um back-end e, em geral, não resolve o problema fundamentalmente. Além disso, ele não é suportado nativamente pelos navegadores.
Eu olhei para o outro lado. A rede possui muitos recursos trabalhando com threads. Estes são recursos de áudio e vídeo. Eles demonstram todos os sinais necessários:
- trabalhe com grandes quantidades de dados;
- perfeitamente lidar com altas cargas;
- eles são capazes de fornecer conteúdo online, mas, ao mesmo tempo, possibilitam o acesso a dados históricos.
Eu fui um pouco mais fundo no vídeo streaming, o que me permitiu resolver radicalmente todos os problemas acima até a data do mercado. Toda a mágica, como se viu, está oculta na tecnologia
Content-Range , que é suportada imediatamente, por exemplo, Nginx. Permite acessar qualquer área de um recurso estático (arquivo no servidor) sem usar um back-end. Em geral, isso acontece da seguinte maneira: você se refere ao URL que indica a exposição que deseja retornar no cabeçalho. Por exemplo: range: 100-200. Não vou me debruçar sobre os meandros, você pode encontrar todas as nuances da tecnologia em artigos especializados. Eu acho que a essência é clara.
De fato, agora, na parte da frente, você pode organizar um apelo à parte necessária do arquivo, por exemplo, contendo velas. E como se sabe exatamente quantos bytes uma vela leva (56 bytes), podemos determinar facilmente o deslocamento necessário. É verdade que ainda precisamos saber em que ponto o cronograma começa. E isso é muito facilmente resolvido adicionando um cabeçalho ao arquivo, cujo tamanho também é uma constante.
I.e. Em primeiro lugar, a frente acessa o arquivo da posição zero e recebe
posição. Ao mesmo tempo, o nginx retornará o tamanho do arquivo. Isso determinará o número total de velas no arquivo e a hora de início.
Agora, sabendo o ponto de partida, tendo uma idéia clara do número de velas, podemos obtê-las por qualquer período de tempo, sem usar um back-end.
Ah, sim ... outro momento ... temos um parâmetro como a exposição da vela. Aqui a solução também é simples - mantemos vários arquivos de uma só vez para diferentes exposições. Como um pequeno bônus adicional, o tamanho da estrutura da vela é reduzido em mais 4 bytes.
Em geral, a solução já era interessante o suficiente para a implementação, mas, no entanto, não tenho vergonha de dizer - lucros muito legais. O fato é que os navegadores podem armazenar em cache os dados recebidos pelo método range. I.e. na próxima solicitação frontal ao servidor, se essa seção do arquivo tiver sido recebida pelo navegador anteriormente, ela não chegará ao servidor, mas será retirada do cache.
Mas mesmo isso não é tudo. Usando CDN, o cache também pode ser configurado por seus meios. I.e. em resumo, você pode obter um sistema capaz de fornecer grandes volumes da data de mercado enquanto carrega minimamente a infraestrutura e os servidores.
Desnecessário dizer que não havia mais dúvida da fidelidade da ideia? Agora, existem pequenas coisas reais ... você precisa gerar esses mesmos arquivos.
Como mencionado acima, geralmente, a bolsa opera dois meios de entrega na data de mercado: REST e WEBSocket. Este último transmite online a data atual do mercado. Geralmente, este é um serviço separado. Como a prática demonstrou, a finalização deste serviço para anexar dados aos arquivos necessários não é difícil e é resolvida literalmente com algumas horas de trabalho do desenvolvedor. Podemos dizer que ele registra ao mesmo tempo que o boletim.
A questão da entrega de arquivos para os nós é um problema clássico de sincronização do sistema de arquivos. A equipe do DevOps resolve isso de maneira fácil e natural. Por exemplo, usando rsync.
Agora, podemos dizer com segurança - BINGO!
Talvez a questão surja - por que todas as trocas de criptomoedas são diferentes? Não tenho uma resposta confiável para esta pergunta. Mas há pensamentos:
- trocas foram criadas por desenvolvedores de criptografia simpáticos. Talvez eles não tivessem idéia do trabalho das trocas clássicas, não levaram em conta sua experiência e usaram soluções prontamente disponíveis para obter resultados rápidos. E estas são soluções de modelo: o mesmo REST e o JSON que o acompanha;
- como dizem nas pessoas - isso funciona? Não toque. - porque as tendências tecnológicas já foram criadas pelas principais bolsas, e as novas bolsas emergentes as emprestaram.
Se o tópico for interessante para a comunidade, continuarei com artigos sobre outras soluções não padronizadas implementadas em nosso projeto. Como isso funciona na prática, você pode ver no site do intercâmbio (veja meu perfil). Proponho especialmente prestar atenção ao trabalho do gráfico, que demonstra claramente todos os lucros dessa tecnologia.