Nosql autoscaling de computação

3

A maioria dos problemas de escalonamento automático nosql é causada pelo fato de os dados precisarem ser migrados durante o pico de carga. E se os dados forem armazenados em um armazenamento compartilhado, como o CLVM, que tem menos sobrecarga (comparado ao NFS ou ao sistema de arquivos compartilhado). Agora, se cada bucket / shard for um LVM separado e um cálculo puder montar um ou mais LVMs com base na quantidade de shards pelos quais ele é responsável. Em alta carga, o cálculo irá desistir de poucos fragmentos (umount LVM) e o novo cálculo que surgiu irá montar os fragmentos. Isso desacopla os problemas de armazenamento e computação do banco de dados e pode tornar a computação horizontalmente escalonável. Eu sei que serverfault não aceita discussões abertas. Sugerir um fórum para postar isso também me ajudará. Se alguém puder me ajudar a entender as armadilhas dessa idéia, também sejam bem-vindos

    
por kalyan 25.11.2018 / 14:36

2 respostas

2

What if data is stored in a shared storage like CLVM which has less overhead ... This decouples the storage and compute problems of DB and can make compute horizontally scalable. ... Suggesting a forum to post this will also help me. If anybody could help me understand pitfalls on this idea are also welcome.

Se o cálculo somente for dimensionado, essencialmente tudo é reduzido em comparação, exceto latência. Você pode acabar trocando escalonamento de computação para redução de E / S de disco (gargalo), mas você pode estar bem com a compensação e pode adicionar discos mais rápidos para evitar isso; o chassi adicional fornece muito espaço.

Consulte: " Site do DB-Engine ", "DataStax - Replicação de dados em bancos de dados NoSQL explicados ", "Linux Journal - Armazenamento de alta disponibilidade com HA-LVM "e" Páginas da Web da Horizontal / Vertical / Escala do Banco de dados para obter informações adicionais.

Existem soluções como o MemCached (DB) , que são mais fáceis de adicionar do que trocar do NoSQL para outro software, mas o software que promete melhor o escalonamento é a melhor solução.

Nesta comparação de Casandra vs. MongoDB , o veredicto é: "Se escrever escalabilidade e 100% de disponibilidade é sua coisa, Cassandra é um ajuste melhor para você ". Sempre haverá algumas compensações, você precisa de uma análise completa de custo / benefício que considere dinheiro e tempo - a pior situação é ir para um lado e acabar com um beco sem saída, forçado a reaproximar o problema quando o mesmo ou um muro diferente é atingido.

Cabe a você decidir se a solução desejada deve ser barata a curto ou longo prazo, e que conjunto de recursos (complexidade) atende às suas necessidades e vale o seu tempo. O primeiro site vinculado acima fornece um meio de comparar diferentes conjuntos de recursos e custos, além de fornecer links para muitos sites.

Deixe-me sugerir outro caminho a seguir, memória compartilhada distribuída ou memória reflexiva.

"A distributed-memory system, often called a multicomputer, consists of multiple independent processing nodes with local memory modules which is connected by a general interconnection network. Software DSM systems can be implemented in an operating system, or as a programming library and can be thought of as extensions of the underlying virtual memory architecture. When implemented in the operating system, such systems are transparent to the developer; which means that the underlying distributed memory is completely hidden from the users. In contrast, software DSM systems implemented at the library or language level are not transparent and developers usually have to program them differently. However, these systems offer a more portable approach to DSM system implementations. A distributed shared memory system implements the shared-memory model on a physically distributed memory system".

Junto com uma solução de software para memória compartilhada, há também uma solução de hardware. Veja alguns fornecedores de painéis de interface de computação distribuída :

  • Dolphin - PXH812 Host / Target Adapter - Conecta o barramento PCIe de um computador a outro em 64 Gb / s com 138 nanossegundos de latência em cobre até 5 metros (200 com fibra). Esta é a versão transparente (não é necessário software, qualquer sistema operacional e pode misturar arcos de CPU), há também o PXH810 NTB Host Adapter (ponte não transferível) com um Shared- API do Memory Cluster Interconnect (SISCI), mas o sistema operacional é limitado para: Windows, Linux, VxWorks ou RTX. Veja a página da Web " Memória Reflexiva PCI Express .

  • Curtiss-Wright - SCRAMNet GT200 - memória de porta dupla aparece no barramento do host como memória adicional do host. O host lê e grava dados por meio de uma porta enquanto a rede grava dados na memória por meio de uma segunda porta. Os dados gravados na memória pelo host são transmitidos automaticamente pelo hardware para todos os nós na rede.

  • Abaco - Cartão de interface PCIE-5565RC - compartilha 128 ou 256 MB de SDRAM no Linux, VxWorks ou Windows. As placas de interface estão disponíveis para PCI Express, PMC, PCI e VME.

Junto com a placa a placa, você pode adicionar um hub à maioria dos produtos acima e adicionar entre vários e 256 nós. Pode valer a pena esperar até o próximo ano e PCIe 4.0.

    
por 26.11.2018 / 05:50
1

O MongoDB, por exemplo, tem o conceito de conjunto de réplicas para essa situação . Nesse caso, várias instâncias do MongoDB servem os mesmos dados. Se um falhar, os outros continuarão servindo os dados. O armazenamento compartilhado não é necessário ou desejável para um conjunto de réplicas; cada instância do MongoDB mantém uma cópia separada dos dados.

Isso é inteiramente ortogonal ao particionamento, no qual os dados são divididos entre diferentes instâncias do MongoDB ou conjuntos de réplicas.

    
por 25.11.2018 / 15:23