Actionbase – um banco de dados para curtidas, itens vistos recentemente e follows
(github.com/kakao)Abrimos como código aberto o Actionbase, um banco de dados para recursos como curtidas, itens vistos recentemente e follow.
Olá, sou um desenvolvedor da Kakao que está trabalhando no Actionbase.
Ontem às 20h (dia 27), publicamos o Actionbase no Hacker News (Show HN) e, cerca de 1 hora e 30 minutos após a publicação, ele chegou ao 1º lugar da primeira página. Na verdade, nosso objetivo era apenas conseguir permanecer na primeira página, mas a reação foi melhor do que esperávamos.
Por que criamos isso?
Recursos como curtidas, itens vistos recentemente e follows variam um pouco de serviço para serviço, mas acabam repetindo estruturas de dados e formas de processamento muito parecidas.
O problema é que cada equipe implementa listas diretas/inversas, contagens e índices de formas um pouco diferentes. Como as estratégias de retry e de tratamento da ordem dos eventos também variam, em alguns casos os dados acabam ficando sutilmente inconsistentes, e até a forma de gerar dados agregados, como a quantidade de curtidas, era diferente entre equipes, o que tornava a operação difícil.
Como funciona?
O Actionbase define isso como um modelo relacional de quem (actor) fez o quê (action) em quê (target) e pré-calcula tudo no momento da escrita. Como a leitura é apenas consulta simples, ela é rápida e previsível.
Aplicação em produção
A primeira aplicação em produção foi a lista de desejos do KakaoTalk Presentes. Na época ainda havia muitas limitações, mas para corresponder às expectativas fomos corrigindo muita coisa, e essa experiência acabou sendo o ponto de crescimento do projeto.
Atualmente, ele processa há vários anos mais de 1 milhão de requisições por minuto em vários serviços da Kakao. O armazenamento é baseado em HBase, e também estamos preparando um armazenamento leve (baseado em SlateDB) para atender a diferentes escalas.
Como começar
Você pode executá-lo imediatamente com Docker:
docker run -it ghcr.io/kakao/actionbase:standalone
- 📦 GitHub: https://github.com/kakao/actionbase
- 🚀 Início rápido: https://actionbase.io/quick-start/
Agradecemos perguntas, feedback e estrelas.
Perguntas e respostas
P: Isso também não daria para fazer com Redis?
Dá. Nós também usamos Redis como cache para dados quentes. No entanto, conforme a escala aumentou, enfrentamos problemas de implementações duplicadas entre equipes e dados incorretos quando a ordem dos eventos se embaralhava.
P: Não bastaria fazer sharding com PostgreSQL/MySQL?
Muitas equipes fazem isso. Os problemas que enfrentamos foram entidades quentes, consultas cross-shard e estratégias de cache diferentes para cada serviço. Precisávamos de um modelo que escalasse horizontalmente sem exigir o desenho de uma estratégia de sharding toda vez.
P: Como funciona o write-time precompute?
No momento da escrita: registro no WAL → lock → transição de estado → cálculo de contagens/índices → armazenamento → publicação de CDC. Para leitura, basta fazer um único GET ou SCAN.
P: E se a ordem dos eventos se embaralhar?
Cada mutation recebe uma version (normalmente um timestamp). Mesmo que os eventos cheguem na ordem like(t=100) → like(t=300) → unlike(t=200), o estado final converge corretamente com base na version. O objetivo é que, mesmo ao reproduzir o mesmo evento novamente, ele converja para o mesmo estado.
P: E o desempenho real?
Na produção do KakaoTalk Presentes, ele processa continuamente mais de 1 milhão de operações por minuto, com pico de cerca de 2 milhões. A latência de leitura é de p50 em torno de 2~3ms, p99 em torno de 10ms. O ponto principal, mais do que os números absolutos, é que a latência é bounded. Como a leitura é um lookup pré-calculado, não uma agregação, o desempenho não piora mesmo quando os dados crescem.
P: Para quais casos de uso ele é adequado?
Curtidas/reações, follow/seguidores e itens vistos recentemente são os casos de uso principais. Para recursos de recomendação/ML, ele pode fornecer dados de treinamento via CDC, mas não serve diretamente recomendações. Mensagens de chat provavelmente não são a melhor escolha, porque exigem outros padrões de acesso, como paginação, busca e threads. Carrinhos de e-commerce também exigem transações, e o Actionbase não oferece suporte a transações cross-edge.
P: Isso não é overengineering? / Não é algo necessário só para empresas grandes?
Pode ser. Honestamente, em pequena escala a resposta certa é PostgreSQL + Redis bem ajustados. Os problemas que o Actionbase resolve — complexidade de sharding, invalidação de cache e duplicação entre equipes — aparecem quando a escala cresce bastante ou quando várias equipes constroem recursos parecidos. Nós batemos nessa parede várias vezes, por isso o criamos. Por isso também estamos preparando um backend leve (SlateDB) para que ele possa ser usado em implantações menores.
24 comentários
Ooh... também vou ficar na expectativa de uma versão backend mais leve!!
Obrigado! Já defini a direção do backend leve com base no SlateDB, em que basta ter o S3, mas ainda não consegui começar de fato.
Queria saber em que tipo de ambiente você pretende usar. Projeto paralelo? Produção de pequeno porte? Quero usar isso como referência para definir prioridades.
Se tiver um tempo, peço também que vote em HBase/SlateDB. Acho que a opinião da comunidade pode ajudar a definir o rumo: https://github.com/kakao/actionbase/discussions/144
Acho que é um projeto extremamente prático.
Muito legal!
Obrigado! Estou compensando aqui a atenção que não consegui receber no Show HN.
Fico curioso para saber que parte pareceu prática para você. Já passou por um problema parecido? Ou está em uma situação em que precisa implementar esse tipo de funcionalidade?
E, já que surgiu a chance de comentar, queria dizer uma coisa. Na documentação está escrito que não fazemos
unbounded traversal, masbounded multi-hopestá nos planos para este ano. Consultas de 2 hops como "produtos de que os amigos gostaram". https://actionbase.io/ko/stories/unified-graph/O que achei prático foi o seguinte:
Eu mesmo já passei por uma preocupação parecida e cheguei a implementar, no nível de código, uma camada de abstração baseada em um KV store como o Redis, então achei muito práticos tanto o objetivo e a direção que o documento quer transmitir quanto a configuração geral como um todo.
Além disso, acho muito legal que tenham reunido e refletido as necessidades e preocupações de várias equipes para criar um produto interno da empresa e depois disponibilizá-lo como open source. haha
Por fim, se eu fosse acrescentar mais uma coisinha, para quem for usar já é totalmente suficiente com a documentação atual, mas acho que ficaria ainda mais atraente se incluíssem exemplos de deploy que dessem para seguir praticamente no esquema copiar e colar, além de exemplos com casos de uso recomendados ou referências de infraestrutura.
Força!
Fico sinceramente feliz em saber que você também teve essa mesma preocupação. E agradeço de verdade por dizer que achou isso incrível.
Concordo com o ponto que você mencionou. Eu também quero configurar com tranquilidade as partes que serão usadas como ferramenta e focar nos problemas que eu preciso resolver.
No entanto, neste momento ainda estamos no estágio inicial do open source e, com tempo limitado, o foco foi em como transmitir esse valor central. Se isso não for bem comunicado, até quem poderia resolver problemas reais pode acabar não conseguindo fazê-lo. Agora pretendo seguir na direção que você sugeriu. Mas gostaria de receber feedback sobre se devemos seguir com a stack interna, HBase + Kafka, ou ir para SlateDB + S2, mesmo que isso exija esforço adicional de desenvolvimento. Nós conseguimos usar HBase com tranquilidade porque engenheiros de HBase cuidam da operação para nós, mas sei que em muitos lugares não é assim. Agradeço se puderem deixar suas opiniões (nem que seja só votando):
https://github.com/kakao/actionbase/discussions/144
Embora eu também ache muito atraente o roadmap que você mencionou, com consultas de 2 hops,
acho que, se vocês conseguirem incorporar melhor a mensagem que os documentos atuais querem transmitir em exemplos mais parecidos com código, a reação será muito mais explosiva.
Concordo. “Conseguir incorporar bem em exemplos.” Mas isso acabou não sendo tão fácil quanto parece, aff. Vou pensar nisso por vários ângulos. Obrigado!
Queria saber se você chegou a ver o guia interativo que nosso colega preparou com muito empenho: https://actionbase.io/guides/build-your-social-media-app/. Essa foi uma tentativa nesse sentido. Isso me faz refletir se está alinhado com a direção que você mencionou. Vamos continuar nos esforçando.
Ah, e uma parte que deixei passar ao comentar anteriormente: dá para perceber o cuidado com a estrutura da documentação como um todo, não apenas com o guia.
Ainda assim, acho que ficaria ainda melhor se a configuração preparada como exemplo pudesse ser seguida facilmente via
git clone, como mencionei antes.Vou responder junto no comentário abaixo.
Achei que já tinha deixado um comentário sobre isso, mas como ele não apareceu, estou escrevendo tudo de novo desde o começo... (snif)
Obrigado por responder com tanto cuidado a um comentário que eu fiz de forma tão casual.. haha;;
Enfim, o que eu queria dizer é que imagino que o contexto de uma equipe pequena ou de uma equipe grande que queira adotar isso seja bem diferente, e acho que a forma mais fácil de convencer alguém quando surge a ideia de “vamos tentar adotar isso?” é um projeto de exemplo escrito na linguagem usada pela equipe.
Se primeiro fossem criados projetos de exemplo em linguagens mais populares e, com base neles, um guia de início rápido, seria muito mais fácil ler tudo sem peso, e acho que o atrativo está justamente em poder testar rapidinho com um
git clone.E também acho que essa é a melhor forma de explicar as melhores práticas.
Claro, sei que, pelas características do projeto, isso não deve ser algo simples de fazer, mas ainda assim acho que é o mais atraente.
Além disso, se possível, acho que seria ainda melhor montar os exemplos junto com ferramentas como pulumi ou terraform.
É uma perspectiva em que eu realmente não tinha pensado. Muito obrigado por uma sugestão como essa. É o tipo de boa experiência que se pode obter na comunidade.
Vou pensar em como colocar em prática a direção que você mencionou. Também nos exemplos com pulumi ou terraform. Talvez eu possa organizar essa direção e pedir apoio à comunidade. Nessa hora, eu ficaria ainda mais grato se você pudesse contribuir.
Além disso, estou pensando em como isso pode se tornar a base na era do vibe coding. Quando você diz "crie uma aplicação", ela é escrita em React, Svelte etc. É ocupar essa mesma posição. Quero dizer, uma situação em que, ao pedir "adicione uma funcionalidade de curtidas", o Actionbase cumpra esse papel.
Essa parte também continua rondando a minha cabeça. Por isso, tenho dado bastante atenção à documentação para que as ferramentas de IA consigam lê-la, e recentemente também tenho visto esse potencial.
Referência:
llms.txt - https://actionbase.io/llms-txt/
Tentativa de receita do vencedor do hackathon da Anthropic - https://github.com/kakao/actionbase/discussions/90
Parece que daria para usar bem em lugares com casos de uso parecidos. Obrigado por disponibilizarem isso publicamente!
Mas fiquei curioso para saber se não houve problemas na parte de usar Lock na ingestão. No caso de escrita de dados, o tráfego era de mais ou menos quanto? Não houve casos em que isso se tornasse um problema por causa de contenção de Lock, por exemplo?
Muito obrigado pela ótima pergunta!
O lock é aplicado por par de edge (
source,target) (ex.: Alice→Phone). Só há contenção quando há escritas simultâneas no mesmo edge, mas, na prática, é muito raro um usuário clicar em curtir no mesmo alvo ao mesmo tempo, então a contenção é baixa. Essa é uma característica do caso de uso do nosso banco de dados.O tráfego de escrita, no pico, fica na casa de algumas centenas de milhares de eventos por minuto. As leituras passam de 1 milhão+, e as escritas ficam abaixo disso.
Referência de benchmark (85% leitura, 15% escrita) - https://actionbase.io/ko/operations/benchmarks/
Entidades quentes (como produtos populares) podem gerar contenção de lock, e isso acontece por causa da atualização de contagem (
HBase Increment). Estamos tratando essa parte com otimizações separadas. Sobre escritas de alta frequência: https://actionbase.io/ko/stories/kakaotalk-gift-recent-views/Uau.....
Obrigado! Se tiver interesse, deixe também sua opinião sobre os próximos rumos: https://github.com/kakao/actionbase/discussions/144
Nossa, isso parece muito útil.
Obrigado! Fico curioso para saber se vocês tiveram algum problema ao implementar funcionalidades parecidas. Estamos coletando opiniões da comunidade sobre o que devemos fazer primeiro a seguir: https://github.com/kakao/actionbase/discussions/144
A documentação para desenvolvedores está realmente muito bem escrita. Os casos de uso mostrados em stories, o início rápido e o FAQ eram tão ricos em conteúdo que pareciam até um blog técnico.
Uau, muito obrigado. Desde a abertura do código-fonte em 5 de janeiro até a divulgação para a comunidade no dia 27, colocamos bastante esforço na documentação, então fico feliz que isso tenha sido reconhecido.
Como ainda estamos no início do open source, acho que esse resultado veio do foco em "o que é isso e por que é necessário". Se, ao ler a documentação, você notar algum ponto que poderia ser melhor, fique à vontade para comentar!
Como referência, se você usar https://actionbase.io/llms-txt/, pode acabar obtendo resultados que não esperava. Recentemente, vi uma pessoa que não conhecia bem o Actionbase chegar à melhor conclusão para uma necessidade complexa com este prompt, e isso me fez perceber mais uma vez como o mundo mudou.
Experimente usar o seguinte no ChatGPT, Claude, Gemini etc.
É compreensível desconfiar. Mas não foi manipulação.
Coloquei 4 links no primeiro comentário e levei shadowban por 30 minutos. Nesse meio-tempo, como a explicação do contexto não aparecia, as pessoas simplesmente passaram batido. Naquela hora eu fiquei realmente ansioso. Com medo de ser enterrado. Tirei os links e postei de novo, e só aí subiu para o 1º lugar, e os comentários também começaram a aparecer.
Esse comentarista que você mencionou, eu também conferi. Vi que a conta tinha sido criada há pouco tempo. Mesmo assim, fiquei grato. Pelo menos houve alguma reação. Então respondi com todo cuidado. "why not redis?" Eu já tinha preparado isso antes. É a pergunta que sempre aparece quando o assunto é banco de dados. Pensei: será que, depois de eu me preparar tão seriamente, vão mesmo fazer essa pergunta? Mas no dia anterior, com o s2-streamstore, eu já tinha percebido. Apareceu uma resposta do tipo "faz com TCP". Então me preparei.
Só para constar, pedi aos membros da equipe que jamais dessem upvote nem comentassem. Para evitar qualquer deslize, também pedi que saíssem da conta. Eu já sabia de antemão que o HN é sensível a esse tipo de coisa.
De qualquer forma, mesmo explicando, talvez você ainda não acredite... então, por favor, dê uma olhada no nosso repositório. É código que sobreviveu em produção. Escrevo isso em detalhes porque tenho receio de que os colegas que trabalharam comigo fiquem magoados ao ver este post. Por favor, veja uma vez: https://github.com/kakao/actionbase/discussions/32 Obrigado.
E também,
https://actionbase.io/ko/stories/kakaotalk-gift-wish/ . Se você já teve que pensar em sistemas de grande escala, acho que pode ser útil. Escrevi com toda sinceridade e dedicação.
Ah, e como vocês podem ver no meu X abaixo, o 1º lugar foi antes daquele comentário ser postado. Aquele comentário provavelmente foi feito quando já tinha caído para 2º ou 3º. No momento em que tirei do estojo do
dujjonkuno espaço de lanches, o comentário apareceu, então corri para responder. Depois disso, em 12 horas caiu até a 30ª posição e agora está na segunda página T_TTambém postei no X: https://x.com/enmskim/status/2016412136482996689
x: https://x.com/enmskim/status/2016941043628097965