O que é sharding e por que é importante?

Acho que entendo que o sharding está colocando de volta seus dados fatiados (os shards) em um agregado fácil de lidar que faz sentido no contexto. Isso está correto?

Atualização : Acho que estou lutando aqui. Na minha opinião, a camada do aplicativo não deve ter como determinar onde os dados devem ser armazenados. Na melhor das hipóteses, deveria ser algum tipo de cliente fragmentado. Ambas as respostas responderam o que, mas não o por que, é um aspecto importante. Que implicações isso tem fora dos óbvios ganhos de desempenho? Esses ganhos são suficientes para compensar a violação do MVC? O sharding é principalmente importante em aplicações de escala muito grande ou se aplica a aplicações de escala menor?

Sharding é apenas outro nome para "particionamento horizontal" de um banco de dados. Você pode procurar esse termo para torná-lo mais claro.

Da Wikipedia :

O particionamento horizontal é um princípio de design no qual as linhas de uma tabela de banco de dados são mantidas separadamente, em vez de serem divididas por colunas (como na normalização). Cada partição faz parte de um shard, que por sua vez pode estar localizado em um servidor de banco de dados separado ou em um local físico. A vantagem é que o número de linhas em cada tabela é reduzido (isso reduz o tamanho do índice e melhora o desempenho da pesquisa). Se o sharding se basear em algum aspecto do mundo real dos dados (por exemplo, clientes europeus versus clientes americanos), poderá ser possível inferir a associação apropriada do shard de maneira fácil e automática, e consultar apenas o shard relevante.

Mais algumas informações sobre sharding:

Primeiramente, cada servidor de banco de dados é idêntico, tendo a mesma estrutura de tabela. Em segundo lugar, os registros de dados são logicamente divididos em um banco de dados fragmentado. Diferentemente do banco de dados particionado, cada registro de dados completo existe em apenas um shard (a menos que haja espelhamento para backup / redundância) com todas as operações CRUD executadas apenas nesse banco de dados. Você pode não gostar da terminologia usada, mas isso representa uma maneira diferente de organizar um banco de dados lógico em partes menores.

Atualização: Você não quebrará o MVC. O trabalho de determinar o shard correto onde armazenar os dados seria realizado de forma transparente pela sua camada de acesso a dados. Lá, você teria que determinar o shard correto com base nos critérios usados ​​para fragmentar seu banco de dados. (Como você precisa fragmentar manualmente o banco de dados em alguns shards diferentes, com base em alguns aspectos concretos do seu aplicativo.) Em seguida, você deve tomar cuidado ao carregar e armazenar os dados do / no banco de dados para usar o shard correto.

Talvez este exemplo com código Java torne mais claro (é sobre o projeto Hibernate Shards ) como isso funcionaria em um cenário do mundo real.

Para resolver o " why sharding": é principalmente apenas para aplicativos de escala muito grande, com muitos dados. Primeiro, ajuda a minimizar os tempos de resposta para consultas ao banco de dados. Segundo, você pode usar máquinas mais baratas e "low-end" para hospedar seus dados, em vez de um servidor grande, que pode não ser mais o suficiente.

Se você tiver consultas a um DBMS para o qual a localidade é bastante restrita (por exemplo, um usuário aciona apenas seleções com um 'where username = $ my_username'), faz sentido colocar todos os nomes de usuário começando com AM em um servidor e todos da NZ no outro. Com isso, você chega ao dimensionamento linear para algumas consultas.

Resumindo : o sharding é basicamente o processo de distribuição de tabelas em diferentes servidores para equilibrar a carga em ambos igualmente.

Claro, é muito mais complicado na realidade. :)

O sharding é o particionamento horizontal (em linha ) do banco de dados, em oposição ao particionamento vertical (em coluna ), que é Normalização . Ele separa bancos de dados muito grandes em partes menores, mais rápidas e mais fáceis de gerenciar, chamadas shards de dados. É um mecanismo para alcançar sistemas distribuídos.

Por que precisamos de sistemas distribuídos?

• Maior disponibilidade.
• Expansão mais fácil.
• Economia: custa menos criar uma rede de computadores menores com o poder de um único computador grande.

Você pode ler mais aqui: Vantagens do banco de dados distribuído

Como o sharding ajuda a obter um sistema distribuído?

Você pode particionar um índice de pesquisa em N partições e carregar cada índice em um servidor separado. Se você consultar um servidor, obterá 1/3 dos resultados. Portanto, para obter um conjunto completo de resultados, um sistema típico de pesquisa distribuída usa um agregador que acumula resultados de cada servidor e os combina. Um agregador também distribui a consulta em cada servidor. Esse programa agregador é chamado MapReduce na terminologia de big data. Em outras palavras, Sistemas Distribuídos = Sharding + MapReduce (Embora existam outras coisas também).

Uma representação visual abaixo.

O sharding é principalmente importante em aplicações de larga escala ou se aplica a outras de menor escala?

O sharding é uma preocupação se, e somente se, as suas necessidades ultrapassarem o que pode ser atendido por um único servidor de banco de dados. É uma ferramenta dinâmica, se você tiver dados fragmentáveis ​​e requisitos de escalabilidade e desempenho incrivelmente altos. Eu acho que, nos meus 12 anos inteiros, sou profissional de software, encontrei uma situação que poderia ter se beneficiado do sharding. É uma técnica avançada com aplicabilidade muito limitada.

Além disso, o futuro provavelmente será algo divertido e emocionante, como uma enorme "nuvem" de objetos que apaga todas as limitações potenciais de desempenho, certo? :)

O sharding foi originalmente cunhado pelos engenheiros do google e você pode vê-lo muito usado ao escrever aplicativos no Google App Engine. Como existem limitações rígidas na quantidade de recursos que suas consultas podem usar e como as próprias consultas têm limitações estritas, o sharding não é apenas incentivado, mas quase imposto pela arquitetura.

Outro local de compartilhamento pode ser usado para reduzir a contenção nas entidades de dados. É especialmente importante ao criar sistemas escalonáveis ​​para observar os dados que são gravados com frequência, porque sempre são o gargalo. Uma boa solução é compartilhar essa entidade específica e gravar em cópias múltiplas, e depois ler o total. Um exemplo deste "sharded counter wrt GAE: http://code.google.com/appengine/articles/sharding_counters.html

O sharding faz mais do que apenas o particionamento horizontal. De acordo com o artigo da Wikipedia ,

O particionamento horizontal divide uma ou mais tabelas por linha, geralmente em uma única instância de um esquema e um servidor de banco de dados. Isso pode oferecer uma vantagem, reduzindo o tamanho do índice (e, portanto, o esforço de pesquisa), desde que exista uma maneira óbvia, robusta e implícita de identificar em qual partição uma linha específica será encontrada, sem a necessidade de pesquisar o índice, por exemplo, o clássico exemplo das tabelas 'CustomersEast' e 'CustomersWest', onde o código postal já indica onde serão encontrados.

O sharding vai além disso: ele divide as tabelas problemáticas da mesma maneira, mas faz isso entre potencialmente várias instâncias do esquema. A vantagem óbvia seria que a carga de pesquisa para a tabela particionada grande agora pode ser dividida em vários servidores (lógicos ou físicos), não apenas em vários índices no mesmo servidor lógico.

Além disso,

A divisão de shards por várias instâncias isoladas requer mais do que simples particionamento horizontal. Os ganhos esperados em eficiência seriam perdidos, se a consulta ao banco de dados exigisse que ambas as instâncias fossem consultadas, apenas para recuperar uma tabela de dimensão simples. Além do particionamento, o sharding divide grandes tabelas particionáveis ​​entre os servidores, enquanto tabelas menores são replicadas como unidades completas

Na minha opinião, a camada do aplicativo não deve ter como determinar onde os dados devem ser armazenados

Essa é uma boa regra, mas como a maioria das coisas nem sempre está correta.

Quando você faz sua arquitetura, começa com responsabilidades e colaborações. Depois de determinar sua arquitetura funcional, é necessário equilibrar as forças não funcionais.

Se uma dessas forças não funcionais for uma escalabilidade massiva, você precisará adaptar sua arquitetura para atender a essa força, mesmo que isso signifique que a abstração do armazenamento de dados agora vaze para a camada de aplicativos.