Dentro de um sistema de gestão e otimização de dados, existem várias operações a serem executadas e preocupações associadas a cada ação. Neste artigo, vamos perceber como são feitas algumas das principais operações dentro do novo modelo de persistência de dados adotado pela Fabamaq.

Na Parte 1 deste conteúdo explicámos a importância de armazenar informação no setor dos casinos, bem como uma nova ferramenta desenvolvida na Fabamaq para ajudar na preservação e gestão de dados. Espreita já o artigo sobre A importância da Otimização na Gestão de Dados no setor de Gaming.

Qual o processo para uma operação de Salvamento de Dados?

Vamos usar a operação de salvamento de dados como exemplo, pois a operação de exclusão de dados pode ser extrapolada a partir desta, sendo o único ponto que difere o nome do método - de Commit para Drop.

Essa extrapolação é trivial porque, tanto para salvar quanto para excluir dados, a operação é tratada como um único commit atómico, com a mesma estrutura de dados, conforme mencionado no artigo anterior.

Tudo começa como uma solicitação ao backend, pedindo para salvar um par chave-valor de dados. Após algumas validações necessárias, o objeto DataStore encaminha a chamada do método Commit para a respetiva versão do Serializer do CommitEngine. Tudo isso acontece na core thread.

Ao mesmo tempo, há uma sync thread que espera por atualizações na CommitsQueue, que por sua vez aciona o processamento do commit, chamando o método de serialização do Serializer seguido pelo método de salvamento. Essa paralelização permite que os commits sejam realizados mesmo durante o processo computacionalmente mais intensivo de serialização de dados.

Após a serialização estar concluída, o salvamento é delegado a cada Dispositivo de Persistência, que por sua vez possui uma worker thread para realizar a operação.

Como implementar uma operação de Obtenção de Dados

Para obter dados salvos numa determinada key, é feita uma solicitação ao backend com a key correspondente e o identificador da DataStore onde o valor está armazenado, e o método CherryPick do Serializer do CommitEngine é chamado. Atenção: a implementação desse método depende da versão do Serializer.

Nas versões atualmente implementadas, existem duas abordagens distintas:

· Solução 1 - Aceder diretamente à representação local do banco de dados armazenada no objeto JSON detido pela DataStore. Esta abordagem é rápida, mas consome mais memória;

· Solução 2 - Aceder ao mapa de memória armazenado localmente para recuperar, do dispositivo de persistência padrão, o valor correspondente à key.

Estratégias Possíveis para Otimização de Memória

As diversas escolhas feitas dentro do sistema têm impactos diferentes no tempo de resposta às solicitações e na eficiência dos recursos utilizados. Vamos explorar algumas estratégias que podem ser usadas para a otimização de memória:

Serializers Diferentes

Conforme mencionado acima, existem duas versões do Serializer implementadas. Embora a primeira dependa de armazenar localmente uma representação completa do banco de dados inteiro, o que é muito conveniente para recuperar dados, ela consome mais espaço.

Para lidar com este problema, foi criada uma segunda versão de Serializer. Nesta edição, apenas um mapa de memória é mantido para cada chave, armazenando o endereço de memória dos respetivos dados e o tamanho do bloco de dados.

Squash de Commits

Como cada operação de dados é tratada como um único commit atómico, quando atualizas ou excluis dados para uma determinada key, vão existir commits antigos que se vão tornar descartáveis, uma vez que apenas o mais recente contém os dados atuais daquela key.

Neste aspeto, definimos um limite de memória que aciona um mecanismo de squash para manter apenas os dados mais recentes para uma determinada key.

No caso da segunda versão do Serializer, o mecanismo é ligeiramente diferente, devido à sua natureza, sendo um mecanismo de desfragmentação de memória, mas o princípio é o mesmo.

Compactação de Dados

Após todas estas etapas, oferecemos apoio à compactação de dados através da biblioteca ZSTD.

Não te esqueças...

Não há como negar a importância dos dados no mundo dos negócios em Casino Gaming. Como Tim Berners-Lee disse uma vez: "Os dados são valiosos e vão durar mais do que os próprios sistemas". Desta forma, devemos considerar cuidadosamente a forma como gerimos cada pedaço de informação.

Espero que com estes conteúdos te tenha proporcionado uma visão clara sobre a importância da informação no mundo dos jogos de casino, bem como o nosso constante desejo de encontrar formas de aumentar a produtividade dos Game Developers através da otimização das nossas operações de dados.

Artigo escrito por Diogo Pereira, Game Developer na Fabamaq.