Qual é um bom equilíbrio entre reutilizar campos e criar novos no contexto da escalabilidade de campos?

Eu li a seguinte frase em um site:

Em vez de adicionar novos campos a um tipo de conteúdo, adicionar campos existentes é uma opção melhor para reduzir a complexidade do sistema e melhorar a escalabilidade.

E algumas dúvidas surgem.

No sistema que estamos desenvolvendo, temos a possibilidade de reutilizar um campo em 3 ou 4 tipos de conteúdo, mas em vez de melhorar a escalabilidade, como diz a frase citada, receio que a diminua, porque a tabela do campo se tornaria um gargalo mais rapidamente (pelo menos esse é o meu raciocínio nesse caso, pois todos os valores desse campo juntos seriam alguns milhões por ano e isso tornaria a tabela muito grande). Você concorda?

Quantas linhas seria um máximo sensato para apontar ao arquitetar? Dessa forma, poderíamos decidir quando reutilizar campos e quando criar novos (mesmo que a chance de reutilização esteja lá).

A quantidade de dados em um campo geralmente não é um problema. Se você estiver preocupado com isso, procure plugins de armazenamento de campo alternativos ou escreva seus próprios. Por exemplo , o MongoDB , que pode lidar com praticamente qualquer coisa que você colocar nele. É, por exemplo, usado em http://examiner.com .

Um problema real, porém, é o número de campos que você possui. Como atualmente no Drupal 7, a configuração completa de todos os campos, independentemente de estarem carregados ou não, é buscada no cache em cada solicitação.

Já vi sites com mais de 250 campos, onde carregar e desserializar a configuração do campo leva 13 MB + de memória.

Editar: o cache de informações do campo foi aprimorado (consulte http://drupal.org/node/1040790 para obter detalhes) com o Drupal 7.22, apenas os campos dos pacotes configuráveis ​​exibidos em uma determinada página são carregados do cache e eles são carregados. entradas de cache separadas. Isso funciona apenas se não houver chamadas de API incorretas que solicitem instâncias em vários pacotes configuráveis.

Eu concordo totalmente com berdir. Aqui estão minhas experiências com um projeto com milhões de linhas e campos de 30 a 40 em alguns tipos de nós.

1. O número de linhas em uma tabela de campos não é um grande problema para o desempenho da leitura, pois todos os campos são buscados pela chave primária.
2. O número de campos por tipo de nó pode se transformar rapidamente em grandes problemas de desempenho ao gravar novos nós. Ter mais de 30 campos para um tipo de nó resulta em mais de 60 instruções INSERT quando você cria um novo nó. Isso leva alguns segundos para concluir. Se você é um usuário que cria muitos dados, isso afetará seu desempenho. Inserções em massa de 1000 nós levarão quase uma hora. Se você precisar atualizar 100.000 nós, esse é um grande problema.
3. Se você acha que o problema do número de campos vai atingir você, pense seriamente em escrever seu próprio armazenamento de campo ou simplesmente não use campos. (Você ainda pode fazer seu nó trabalhar com visualizações com algum esforço extra.)
4. Uma palavra sobre o MongoDB. É um projeto muito interessante e espero que esteja no olymp dos grandes DBs. Infelizmente, comparado à maturidade do MySql ou PgSql, é um bebê. Esteja preparado para lidar com um produto muito jovem.

Se você está realmente preocupado com o que acontecerá, acho que uma simulação está em ordem.

Obtenha uma conta no Rackspace Cloud, Amazon, Linode ou em qualquer outro lugar onde você possa facilmente criar um VPS. Faça duas instâncias idênticas. Instale o Drupal em cada um. Crie alguns tipos de conteúdo fictícios e configure os campos de uma maneira em um sistema e outra maneira no outro. Use o módulo devel para criar uma grande quantidade de conteúdo. Ajuste as configurações de desempenho para garantir que o Drupal esteja armazenando em cache, conforme necessário. Execute o mysqltuner e ajuste o MySQL em cada uma por recomendações. Verifique as configurações de PHP e APC para que você não esteja trocando swap e que não esteja agitando o cache da APC.

Depois de obter uma boa configuração de linha de base para cada um, comece a simular o tráfego (visitantes normais e atualizações de administrador) com wget e drush e, em seguida, crie um perfil.

As simulações nunca são perfeitas, mas podem levá-lo na direção certa.

Um problema com a escalabilidade dos campos no uso de índices em cada campo da tabela criada em cada campo. O índice clusterizado de chave primária é um composto da maioria dos campos e, em seguida, criou índices separados em cada indivíduo do campo. Os índices criam uma tonelada de sobrecargas de gravação para o banco de dados e, na maioria dos casos, nunca são usados.

outra dica: ter muitos campos também causará problemas em muitos módulos diferentes. A GUI do token, por exemplo, fará o seu navegador ficar lento por alguns minutos, se você tentar editar os aliases de URL, por exemplo. Esse comportamento pode ser visto em todas as páginas em que o token será carregado e exibido (incluindo devel - dpm () etc.)

Não há benefício de desempenho na divisão desses dados em várias tabelas ao usar o InnoDB (o MyISAM é diferente por causa do bloqueio de tabela). Portanto - se você souber que terá muitos tipos de conteúdo semelhantes com campos semelhantes (cujas configurações também serão as mesmas, talvez sejam diferentes apenas nas etiquetas), reutilize seus campos!

Também pode facilitar a criação de modelos devido a atributos de nó semelhantes.

Apenas compartilhando minha história, estamos usando o Drupal Commerce e temos cerca de 40 campos em nossas variações de produtos (Sku) e outros 460 (sim, loucos) em nossa Exposição de produtos. Tivemos algumas visualizações de comparação de produtos que analisariam todos esses campos. Sem o armazenamento em cache, algumas cargas de página podem levar até um minuto!

No entanto, funcionou. Se você usou cache e verniz, o tempo de espera do usuário não foi tão ruim.

O principal problema que encontramos com tantos campos é com o Display Suite, pois isso ficaria muito lento (às vezes sem resposta) se tentássemos reorganizar ou mover um campo.

Felizmente, decidimos redimensionar nossos produtos um pouco, para que possamos, com sorte, obter nosso número máximo de campos na faixa 200-250 para nossos produtos mais complexos (estamos em instrumentação científica, são necessárias medições e especificações complexas) .

É uma pergunta interessante. Já pensei sobre isso antes, às vezes reutilizar um campo pode ser conveniente para não ter muitos campos semelhantes 'espalhados', mas parece bobo ter um determinado tipo de conteúdo que precisa selecionar a partir de uma grande quantidade de dados que O conhecimento não deve ser retornado no resultado.

Eu precisaria de um pouco mais de informações sobre o projeto para aconselhar sobre as melhores práticas de dimensionamento. Qual é o tráfego esperado, quantos desses usuários devem estar conectados etc.? Por exemplo, se todo o tráfego, exceto o dos usuários administrativos, não for autenticado e armazenado em cache anonimamente

Até agora, sempre reutilizei os campos, mas agora estou pensando em usar campos exclusivos por tipo de nó para um novo projeto. Na verdade, quero manter tudo bem separado (campos, visualizações, regras, contextos etc.) para cada pacote de entidades. Por isso, levantou a questão da escalabilidade que me levou até aqui. Estou satisfeito com a edição de Berdir (o cache de informações do campo foi aprimorado (consulte http://drupal.org/node/1040790 para obter detalhes) com o Drupal 7.22, apenas os campos dos pacotes configurados exibidos em uma determinada página são carregados a partir de o cache e são entradas de cache separadas. Isso funciona apenas se não houver chamadas de API incorretas que solicitem instâncias em vários pacotes configuráveis).

Quero apenas ressaltar que há um módulo muito interessante que venho usando há meses em vários sites complexos: https://www.drupal.org/project/render_cache . É uma daquelas jóias escondidas na minha opinião.

Como diz a página do projeto, a parte dos comentários está realmente sendo usada no próprio DO.

Então, com tudo isso em mente, isso tornaria o consenso em favor de campos separados? A ressalva mencionada sobre o DS ainda é uma chatice, no entanto. É super irritante a maneira como ela salva via ajax, em vez de, por exemplo, como a interface de administração do bloco principal lida com o pedido novamente. Eu sinto que é um problema ds, no entanto ...

De acordo com minha sugestão, é recomendável usar os mesmos campos em um tipo de conteúdo separado. Porque melhorará o desempenho do seu site. No Drupal 7, quando você estiver usando a operação de seleção dessa vez, o uso dos mesmos campos no tipo de conteúdo é realmente útil para o site do Drupal7.