Há uma infinidade de lojas de valores-chave disponíveis. Atualmente, você precisa escolher um e continuar com ele. Acredito que uma API aberta independente, não feita por um fornecedor de valor-chave da loja, facilitaria muito a alternância de lojas.

Portanto, estou criando uma camada de abstração do armazenamento de dados (como ODBC, mas focada em armazenamentos de valores-chave mais simples), para que alguém crie um aplicativo uma vez e altere os armazenamentos de valores-chave, se necessário. Essa API é muito simples?

get(Key)
set(Key, Value)
exists(Key)
delete(Key)

Como todas as APIs que eu vi até agora parecem adicionar tanto, fiquei imaginando quantos métodos adicionais seriam necessários?

Recebi algumas respostas dizendo que set (null) poderia ser usado para excluir um item e, se get retornar null, isso significa que um item não existe. Isso é ruim por duas razões. Primeiro, não é bom misturar tipos e status de retorno e, segundo, nem todos os idiomas têm o conceito de nulo. Vejo:

Todas as linguagens de programação têm um conceito claro de NIL, nulo ou indefinido?

Quero poder executar muitos tipos de operação nos dados, mas, pelo que entendi, tudo pode ser construído sobre um armazenamento de valores-chave. Isso está correto? E devo fornecer também essas funções de valor agregado? por exemplo: como mapreduce ou índices

Internamente, já temos uma versão básica disso em Erlang e Ruby, economizando muito tempo e também nos permitindo testar o desempenho para casos de uso específicos de diferentes armazenamentos de valores-chave