Essa ideia sobre o servidor de banco de dados distribuído com armazenamento centralizado é viável?

Question

Costumo usar o SQLite para criar programas simples em empresas. O banco de dados é colocado em um servidor de arquivos. Isso funciona bem, desde que não haja mais de 50 usuários trabalhando para o banco de dados ao mesmo tempo (embora sejam leituras ou gravações). Quando houver mais do que isso, eles perceberão uma lentidão se houver muita escrita simultânea no servidor, já que muito tempo é gasto em bloqueios e não há nada como um cache, pois não há servidor de banco de dados.

A vantagem de não precisar de um servidor de banco de dados é que o tempo para configurar algo como um Wiki da empresa ou similar pode ser reduzido de vários meses para apenas alguns dias. Geralmente, leva vários meses porque algum departamento de TI precisa solicitar o servidor e ele precisa estar em conformidade com as políticas e regras de segurança da empresa e precisa ser colocado na instalação de hospedagem do servidor terceirizado, que estraga e o coloca na localidade incorreta. etc etc.

Portanto, pensei em uma ideia para criar um servidor de banco de dados distribuído. O processo seria o seguinte: Um usuário em um computador da empresa edita algo em uma página do Wiki (que usa esse banco de dados como seu back-end), para fazer isso ele lê um arquivo no disco rígido local indicando o endereço IP do último computador desktop para ser um servidor de banco de dados. Ele então tenta contatar este computador diretamente via TCP / IP. Se ele não responder, ele lerá um arquivo no servidor de arquivos informando que o endereço IP do último computador de mesa é um servidor de banco de dados. Se este servidor também não responder, seu próprio computador de mesa se tornará o servidor de banco de dados e registrará seu endereço IP no mesmo arquivo. A instrução SQL update pode então ser executada e outros computadores desktop podem se conectar diretamente a ele.

O ponto com esta arquitetura é que, quanto maior a carga, melhor ela funcionará, já que cada computador desktop sempre saberá o endereço IP do servidor de banco de dados. Além disso, usando essa configuração, acredito que um banco de dados colocado em um servidor de arquivos pode servir centenas de computadores desktop em vez dos atuais 50 ou mais. Eu também não acredito que a carga no único computador desktop, que se tornou servidor de banco de dados, seja notada, já que não haverá operações de disco rígido nesta área de trabalho, apenas no servidor de arquivos.

Esta ideia é viável? Já existe? Que tipo de banco de dados pode suportar essa arquitetura?

Edite: devo salientar que essa idéia não é bonita, estável, é a melhor prática ou algo de que eu realmente me orgulhe. A razão pela qual ainda estou interessado na viabilidade é que alguns dos meus clientes são bancos, e a burocracia envolvida no acesso a um banco de dados é enorme. Muitas vezes, o patrocinador do projeto em tais projetos precisa estar acima do nível de vice-presidente, devido às suas preocupações extremas de segurança com o acesso aos servidores. Escusado será dizer que isto significa que há muito trabalho para criar um Wiki. Posteriormente, se o Wiki for bem-sucedido, ele deverá, é claro, ser migrado para um servidor de banco de dados adequado.

Edit2: O motivo para essa idéia é reduzir o risco de gravação do Starvation ao usar o SQLite quando o banco de dados é colocado no servidor de arquivos. Esse problema é descrito na seção 5.1 aqui . Utilizar um computador de mesa para armazenar em cache as informações mais acessadas (ou seja, páginas do Wiki) significaria que a carga de trabalho no servidor de arquivos seria reduzida drasticamente. Isso novamente deve melhorar a experiência do usuário. Você realmente acha que eu ainda estou longe dessa idéia?

    

Answer 1

Na verdade, você pode criar um bom ambiente de banco de dados distribuído se particionar (ou direcionar) suas leituras e gravações em bancos de dados diferentes. Nós fazemos esse trabalho, e o truque é muito simples. Você tem o banco de dados mestre em um servidor de arquivos e direciona todas as gravações para ele. Você tem uma cópia local do banco de dados no computador de cada usuário e direciona as leituras para ele. Agora você também precisa de um mecanismo de sincronização entre o banco de dados mestre e os bancos de dados locais. Isso pode ser feito de várias maneiras. Uma maneira é ter uma tabela "delta" no banco de dados mestre. Essa tabela delta conterá as transações que foram aplicadas no banco de dados mestre. Sempre que o aplicativo do usuário executa uma operação de leitura ou gravação, o delta no mestre é primeiro verificado e atualizado localmente. Apenas as transações no delta ainda não aplicadas (que podem ser verificadas com base no registro de data e hora) precisam ser aplicadas. Você pode até ter um processo em segundo plano fazendo isso continuamente. Esse delta pode ser um delta diário (ou um delta semanal) quando é liberado. Se um usuário não estiver logado por uma semana ou mais, você simplesmente copia todo o banco de dados para o computador do usuário. A vantagem de ter uma cópia local é que os usuários podem consultar coisas mesmo quando estão offline e - acredite ou não - isso é muito rápido mesmo quando você está atualizando coisas on-line.

    

Answer 2

Is this idea feasible?

Não.

Does it already exist?

Não que eu saiba.

What kind of database could support such an architecture?

Veja acima.

Honestamente, esta é uma ideia muito ruim em muitos níveis. Há uma razão pela qual as empresas mantêm dados críticos dentro do datacenter. Você não quer que os aplicativos de negócios dependam do número X de máquinas desktop que devem estar funcionando. Outro problema seriam os firewalls - em todos os ambientes, exceto os pequenos, não haveria garantias de que o Desktop X seria capaz de se comunicar com o Desktop Y, e boa sorte em fazer com que o firewall passasse por sua equipe de rede.

Existe algum motivo para a sua empresa não ter um servidor central de banco de dados bem mantido que esse aplicativo possa usar? Não há razão para que um wiki da empresa precise de seu próprio servidor de banco de dados.

    

Answer 3

Esta questão não está relacionada à administração do sistema, mas quando eu a li, muitos alarmes de advertência dispararam, e eu apenas tenho que responder.

Eu realmente tenho que te dizer que todo o seu conceito está tão longe da verdade que você não encontrará ninguém fazendo isso. Para começar, o SQLite é inadequado para esses trabalhos e o fato de você ter tido algum sucesso é mais devido à boa sorte que qualquer outra coisa.

Seu plano tem tantos buracos que eu realmente não sei por onde começar, mas vou lhe dizer que será um sistema excessivamente complexo, que se mostrará incrivelmente não confiável e com baixo desempenho.

Seu comentário

time to set up something like a company Wiki or similar can be reduced from several months to just days

me diz muito. Para configurar um wiki normalmente leva apenas alguns minutos e qualquer sistema wiki decente terá auxiliares para acelerar a importação de dados de outros sistemas.

Sugiro que você abandone suas ideias de design atuais e veja como essas coisas estão sendo feitas por outras pessoas. Use qualquer um dos sistemas wiki comuns (eu prefiro o MediaWiki) com um sistema de banco de dados regular (o MySQL é muito popular) e você não só economizará muito tempo como também acabará com um sistema que é mais utilizável e mais robusto, mais muito mais barato para implementar.

Em suma, pare de tentar reinventar a roda, porque o seu design atual vai acabar mais como um quadrado com um buraco mais ou menos no meio.

    

Answer 4

Como mencionado, esta questão está fora do escopo da administração de sistemas. Dito isso, bancos de dados distribuídos e armazenamentos de dados distribuídos estão sendo usados em alguns lugares muito reconhecíveis. Embora os pontos strongs do SQLite geralmente não se prestem a esse tipo de aplicativo, ele não é inédito. Veja, por exemplo, no projeto Fossil . Mesmo que este seja um sistema de controle de fonte distribuído baseado no SQLite, ele também fornece um wiki distribuído e um aplicativo de blog, e pode realmente fazer o truque para você. Embora você provavelmente deva olhar além do SQLite, isso não significa que você precisa abandonar o código-fonte aberto. Considere implementar seu projeto no Apache CouchDB ou em um armazenamento de dados baseado no Hadoop. Uma abordagem ainda mais inovadora é criar aplicativos em um espaço de usuário distribuído. ambiente virtual como o Inferno.

    

Answer 5

Sua descrição se parece muito com o que os sistemas POS (Point of Sale) usam. Um terminal mestre é declarado na inicialização que faz o processamento do banco de dados. Uma cópia do banco de dados é sincronizada entre o mestre e todos os terminais escravos para backup.

Se o mestre falhar, todos os outros terminais exibem uma mensagem dizendo "Torne-me o novo mestre?". Você aperta sim e tudo continua. Isso poderia continuar até que houvesse um terminal em pé.

Funciona, e é uma espécie de prova idiota, mas ter um banco de dados corrompido no final do dia é comum. Felizmente, os terminais armazenam apenas os dias de vendas, portanto, seus totais diários podem estar um pouco perdidos, já que alguns pedidos não foram salvos corretamente. É preferível que o sistema fique inativo por algumas horas e perca as vendas.

Em uma grande rede / queda de energia, a limpeza no final do dia é o que o excesso de tempo significa, pois as vendas dos dias atuais podem se espalhar por vários terminais diferentes e você precisa resolver tudo. Fico feliz por não fazer mais esse trabalho.

Escolha um grande servidor de banco de dados com bons backups.

    

Answer 6

Não está totalmente claro na sua pergunta onde os dados residem em última instância? Vive no servidor de arquivos centralizado? Em caso afirmativo, mover o mecanismo de banco de dados em torno de uma grande quantidade de áreas de trabalho ao usar o servidor de arquivos centralizado como um armazenamento de disco provavelmente não lhe renderá muito desempenho. Se alguma coisa, o afastamento do disco do motor provavelmente fará com que ele seja pior, se for o caso.

Se os dados não estiverem centralizados, a consistência dos dados será um problema se você tiver vários desktops contendo todos os bits de dados diferentes.

Problemas semelhantes existem em torno da configuração e segurança do banco de dados, nenhum dos quais é trivial. E, finalmente, a execução de um servidor de banco de dados em uma máquina de desktop que atenda a mais de 100 usuários remotos ativos terá um efeito perceptível no desempenho dessa área de trabalho.

    

Answer 7

Você viu o link ? Eles possuem um driver sqlite3 para o nodejs e parece razoavelmente bem arquitetado.

    

Answer 8

Concluí recentemente o desenvolvimento de uma camada de banco de dados distribuída para uma estrutura de middleware SOA / ESB / RESTful que precisava ser proprietária sem a dependência da infraestrutura de banco de dados, criada em c # com um wrapper para SQLite.

Minha camada de banco de dados opera como um cluster de nós, composto por nós testemunha (mestre e failover), nós de gravação / confirmação de dados (novamente mestre e failover) e nós de replicação que basicamente armazenam dados replicados.

Em operações de gravação, o nó de gravação selecionado gera identificações únicas e chaves estrangeiras que a localização de gravações de dados bem-sucedidas em nós é indexada. isso garante que os dados replicados mantenham os mesmos IDs e chaves estrangeiras. Existem processos paralelos / paralelos que mantêm a replicação. Chaves estrangeiras não são aplicadas com rigor, mas funcionam.

Eu também escrevi um wrapper de cliente para essa camada de dados que fornecia failover de string de conexão do cliente entre testemunhas.

Até agora testes e benchmarking parecem provar conceito. Eu testei com tamanhos diferentes de dados e parece funcionar bem. Obviamente, como minha camada de banco de dados é projetada para ser middleware Restful, sua velocidade é menos importante do que a alta disponibilidade. Além disso, os requisitos para a estrutura de seus dados são o fator principal para saber se essa abordagem funcionará ou não.

Minha próxima revisão será verificar se posso distribuir a recuperação de grandes conjuntos de dados entre nós replicados à medida que o conjunto de dados é transmitido para a estrutura do cliente, como uma grade de dados com a ideia do json.