Sobre Servidor de dados

[rossine]

Bom dia,

Estou tendo reclamaçoes de clientes dizendo que certas rotinas do meu sistema que fazem acesso ao SQL que está nas nuvens, estão lentas ou não conectam.

Como não tenho muito conhecimento sobre "Servidores virtuais", existe servidores que fornecem um acesso melhor aos dados com mais rapidez e acesso ilimitado ?

Vocês poderiam me indicar algum servidor que já usam e tenham experiencia para me indicar ?

Obrigado,

[gilbertosilverio]

Ola Amigos,

Aproveitando o gancho, fiz vários teste a partir de exemplo do Quintas, Simões e Itamar no SQL, e surgiu uma duvida baseado nos testes.

Dependendo da conexão da internet, as respostas as pesquisas em uma base SQL, as vezes é instantânea, outras vezes tem um delay, e tem vezes que nem conecta.

Minha duvida e: Se neste intervalo a conexão falha, corro o risco de perde/corromper dados no servidor, como ocorre em uma rede com DBF.

Grato.

[JoséQuintas]

Estou tendo reclamaçoes de clientes dizendo que certas rotinas do meu sistema que fazem acesso ao SQL que está nas nuvens, estão lentas ou não conectam.

Minha duvida e: Se neste intervalo a conexão falha, corro o risco de perde/corromper dados no servidor, como ocorre em uma rede com DBF.

Com internet é mais complicado, porque a internet em si pode falhar, o servidor pode ter limitações, o próprio Windows tem limitações.
Numa época tive 3 conexões simultâneas pra testar: Speedy Fixo Telefônica 2MB, NET 10MB e TIM 35MB, e meu servidor era aqui.
NET a pior de todas, justamente porque dava muito problema de conexão.
Speed fixo o melhor pra conectar
TIM não era o melhor, mas era aceitável

O Windows tem limite de conexões "pendentes", aquelas no meio do caminho entre abrir/fechar.
Se ficar abrindo/fechando conexões, chega a travar a conexão, então o mais comum é deixar conectado sempre, com o risco de cair.

Uma mania de quem usa MySQL no Harbour é usar o conector MySQL 3.51.... de dezenas de anos atrás... isso é pedir pra ter problema.

Já aconteceu comigo: XML salvo incompleto, provavelmente porque caiu a conexão durante a gravação

Mas de um modo geral não corrompe a base, já que o servidor vai validar tudo antes de salvar.

Lógico... muitos aqui fazem mais uso de MySQL do que eu. Aqui estou me baseando no que já aconteceu comigo.
Imagino que usando transação ficaria bem melhor, porque o terminal avisa quando o processo se completou, e qualquer coisa incompleta seria descartada.

Geralmente provedores oferecem o recurso de IP exclusivo, isso deve melhorar a conexão.
É sempre melhor conectar por IP do que pelo nome, e melhor do que usar um virtual como no-ip.org pra redirecionar, porque tudo isso requer mais caminhos até chegar ao servidor, portanto mais tempo e mais possibilidades de falha.

[Itamar M. Lins Jr.]

Ola!

Estou tendo reclamaçoes de clientes dizendo que certas rotinas do meu sistema que fazem acesso ao SQL que está nas nuvens, estão lentas ou não conectam.

Não adianta nada vc ter uma conexão 5G ou 200Mbfibra se seu cliente tem 10Mb ou se além dos 10Mb ele tem 10 pessoas pinduradas na rede usando midia(imagem/som). Vai colocar 100Mb fibra e ter picos(bons/ruins), pq a medida que surgem imagens de 4k, 8k etc... precisa de link mais rápido.

É uma dor de cabeça.
O melhor é está até o .EXE na nuvem, não somente o BD.
Por isso o sucesso das APP(android/IOS) pq está tudo lá, nada cá!
Sobre corromper o BD não é possível. Mas pode gravar dados incompletos. Ai precisa usar transações... Só gravar se chegar toda a informação, senão jogar tudo fora. Problema que isso gera para pessoas que trabalham como eu com milhares de pedidos com itens variados, orçamentos que podem se transformar em NFCe e NFe.
Por esses problemas e mais outros do tipo aumento dos custos de manutenção do sistema que não uso esse modelo.

Saudações,
Itamar M. Lins Jr.

[Itamar M. Lins Jr.]

Ola!

pesquisas em uma base SQL, as vezes é instantânea, outras vezes tem um delay, e tem vezes que nem conecta.

Essa é a vida real.
Pq o caminho é esse mesmo, testar tudo antes. Como eu já sei desses problemas e não ganho para ficar otimizando rede de clientes uso o LetoDbf.
Imagine ai o sistema ficar off line por 1 hora tipo 8h da manhã até 9h. Sabe quantos pedidos terão que ser digitados no final do dia ? E quem vai fazer isso ?
Ficar off line por conta de fatores externos, quebra de fio queima de um HUB do provedor, possíveis problemas no provedor.
A nossa mobilidade está comprometida, hoje acredito que 95% das intervenções que faço são via teamviwer.

O meu interesse no MySQL/MariaDb é remover todo o sistema do cliente e colocar na nuvem, não apenas o BD.
Pq não são todos os clientes que estão prontos para essa realidade ou irão aceitar ou pagar essas melhorias.

Mesmo que os problemas externos não tenham nada a ver com nosso sistema! O comerciante que é o afetado, não quer saber., pq antes o sistema funcionava LOCAL, só não sai a NFe/NFCe. Fica esperando o retorno da internet só para validar e imprimir as vendas o resto funciona, pré-venda,pag/rec, contabil...

E digo mais, afeta até os relatórios que são feitos no fastreport, etc ou em disco, pq precisa mudar para serem impressos na impressora do cliente e como vamos fazer isso ? Dai o uso do PDF e HTML nos relatórios.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Essa é a vida real.

E digo mais... funcionar nas nuvens é lindo, mas ainda não é para o Brasil.

Aqui é normal roubarem fios pra vender e comprar droga.
Imagine bairros inteiros sem telefone, porque alguém roubou fios pra vender por talvez 10 reais, e usar droga naquele dia.
Depois tem mais 29 dias no mês pra eles conseguirem dinheiro pra mais droga, mais fios pra roubar....

Já pensou na situação?
Não poder trabalhar durante uma semana, porque alguém quis fumar um cigarrinho algum dia?

O melhor negócio ainda é ter servidor MySQL no cliente.
E pensar direito nas exceções.

[rossine]

Boa tarde,

Vou rever meus processos de conexão no BD nas nuvens e tentar diminuir os acessos diversos e concentrar em poucos acessos levando mais dados de uma só vez. Com certeza isso irá poupar os servidores.

Obrigado por suas opiniões e dicas,

[marcosgambeta]

Rossine,

Outro fator para se levar em consideração: a diferença entre usar o banco de dados de um serviço de hospedagem de sites [1] e um banco de dados num servidor VPS [2].

Na situação [1], o SGBD costuma ser compartilhado com outros clientes. Cada cliente tem seu BD e suas tabelas, mas o SGBD costuma ser um só. Então, a capacidade do servidor fica dividida entre vários clientes.

Na situação [2], o cliente fica responsável por instalar e manter o SGBD. Mas o SGBD é exclusivo do cliente, não tendo que dividir com mais ninguém. Se o desempenho da VM for boa, o desempenho do SGBD também será.

É claro que não salva de algumas situações mencionadas nas outras mensagens (como a Internet ruim, por exemplo), mas um servidor VPS pode te dar mais recursos e liberdade.

Pode-se optar por um servidor Linux ou Windows (costuma sair mais caro), mas precisa dimensionar bem (capacidade do disco, memória, consumo de banda, etc...). Os discos hoje, costumam ser SSD, garantindo mais rapidez no processamento.

Como são muitas as empresas que fornecem este tipo de serviço, talvez você possa pedir sugestões aqui no fórum. Atualmente, uso um servidor na Locaweb e está funcionando bem (mas não uso SGBD nele). Já usei UOL HOST, mas deixou a desejar com a perda de VM's sem possibilidade de recuperação.

[rossine]

Boa tarde Marcos,

Na situação [1], o SGBD costuma ser compartilhado com outros clientes. Cada cliente tem seu BD e suas tabelas, mas o SGBD costuma ser um só. Então, a capacidade do servidor fica dividida entre vários clientes.

Hoje meus clientes estão usando essa modalidade de servidor.

Na situação [2], o cliente fica responsável por instalar e manter o SGBD. Mas o SGBD é exclusivo do cliente, não tendo que dividir com mais ninguém. Se o desempenho da VM for boa, o desempenho do SGBD também será.

Vou procurar saber mais sobre este estilo de Servidor e ver se uso as bases em comum usando o metodo [1] e quando se tratar de BD individual, cada cliente ter o seu Servidor. [2]

Obrigado pela dicas,

[marcosgambeta]

Rossine,

Para não haver dúvidas, alguns esclarecimentos:

Na situação [1], você é o cliente do serviço de hospedagem de sites. Seu banco de dados fica num SGBD que é compartilhado com outros clientes da hospedagem. Se outros clientes utilizarem o SGBD de forma intensa, é provável que isto reflita no seu uso.

Na situação [2], você é o cliente de um serviço de VPS. Então, não precisa dividir seu servidor com nenhum outro cliente do serviço de VPS. O servidor é seu e você tem liberdade para configurá-lo e instalar o que você precisar (incluindo o SGBD de sua escolha).

O seu VPS seria um só e os seus clientes utilizariam o SGBD instalado nele, através do IP público do servidor. Cada cliente teria seu BD e suas tabelas.

Não seria preciso criar um VPS para cada cliente, pois isto encareceria o custo além de dar mais trabalho.

Mas se o cliente quiser ter seu VPS exclusivo, também pode. Todo os recursos da VM seriam só para ele (talvez uma boa opção para clientes com muita movimentação).

Espero ter sido claro na ideia que estou tentando passar. Mas se algum ponto ficou duvidoso, basta perguntar.

[MSDN]

Trabalha 3 camadas, cria um servidor de aplicação no VPS e transporta JSON, serve para BD, NF-e, NFC-e, CT-e, etc (empresas com muitos emissores ou filiais, deixa só 1 certificado para todos), agilidade com menos tráfego utilizando REST, facilita integrações com PiPay, iFood, etc, para manter a mesma base com acesso de vários dispositivos (Desktop, Mobile, WEB), replicador, ficou OFF starta LOCAL e por ai vai !

[rossine]

Olá Marcos,

Para não haver dúvidas, alguns esclarecimentos:

Na situação [1], você é o cliente do serviço de hospedagem de sites. Seu banco de dados fica num SGBD que é compartilhado com outros clientes da hospedagem. Se outros clientes utilizarem o SGBD de forma intensa, é provável que isto reflita no seu uso.

Sim, hoje uso desta maneira.

Na situação [2], você é o cliente de um serviço de VPS. Então, não precisa dividir seu servidor com nenhum outro cliente do serviço de VPS. O servidor é seu e você tem liberdade para configurá-lo e instalar o que você precisar (incluindo o SGBD de sua escolha).

OK

O seu VPS seria um só e os seus clientes utilizariam o SGBD instalado nele, através do IP público do servidor. Cada cliente teria seu BD e suas tabelas.

Esse IP publico, é IP Fixo ?

Não seria preciso criar um VPS para cada cliente, pois isto encareceria o custo além de dar mais trabalho.

OK, entendi.

Mas se o cliente quiser ter seu VPS exclusivo, também pode. Todo os recursos da VM seriam só para ele (talvez uma boa opção para clientes com muita movimentação).

Hoje tenho basicamente clientes acessando tabelas mais simples tipo, liberação de sistema, envio de erros, e 1 ou 2 clientes que etão testando tabelas maiores , clientes, produtos, em um aplicativo que tenho de força de vendas. Usando isto em uma VPS que eu contratar para minha empresa mas separando os bancos de dados e tabelas isolados por cliente, talvez melhore essa questão de trafego de dados e acessos simultaneos sem queda de performance. Vou pensar nesta possibilidade.

Espero ter sido claro na ideia que estou tentando passar. Mas se algum ponto ficou duvidoso, basta perguntar.

Ok obrigado pelas dicas,

[rossine]

Olá Marcelo,

Trabalha 3 camadas, cria um servidor de aplicação no VPS e transporta JSON, serve para BD, NF-e, NFC-e, CT-e, etc (empresas com muitos emissores ou filiais, deixa só 1 certificado para todos), agilidade com menos tráfego utilizando REST, facilita integrações com PiPay, iFood, etc, para manter a mesma base com acesso de vários dispositivos (Desktop, Mobile, WEB), replicador, ficou OFF starta LOCAL e por ai vai !

Esta ideia parece ser uma boa, mas teria um exemplo de como poderia fazer isto ?

Obrigado,

[marcosgambeta]

Esse IP publico, é IP Fixo ?

Sim. É um IP fixo. Enquanto o VPS existir, terá este IP para acesso.

Dependendo da empresa fornecedora do serviço, pode ser que seja possível solicitar/contratar mais de um IP.

[rossine]

Olá Marcos,

Sim. É um IP fixo. Enquanto o VPS existir, terá este IP para acesso.

Dependendo da empresa fornecedora do serviço, pode ser que seja possível solicitar/contratar mais de um IP.

Ok, entendi.

Obrigado,