IntroducaoO ZODB (banco de dados orientado a objetos para aplicalcoes Python), originalmente criado como um componente do servidor de Aplicacao Zope2 (Z Object Publishing Environment), foi desenvolvido com o conceito de "Storage Layer", o qual abstrai o tipo de backend responsavel pela persistencia dos objetos.Historicamente, o primeiro Storage Layer desenvolvido para o ZODB foi FileStorage, que tem como objetivo ser simples e robusto, e por isso armazena todos os objetos e transacoes um unico arquivo de forma sequencial. Para acessar os objetos atraves do seu caminho na hieraquia de objetos do ZODB (ex: obj2 = root['obj1']['obj2'] ), o FileStorage cria um arquivo auxiliar de indice e que deve estar completamente na memoria para que o desempenho seja adequado.Compartilhando o ZODBMais tarde, devido a necessidade de compartilhar um mesmo banco de dados por diversas instancias de uma aplicacao (ou diversas aplicacoes), foi desenvolvido o ZEO (Zope Enterprise Objetcts), que e composto por um servidor RPC que fornece acesso via rede a um ou mais bancos de dados ZODB em FileStorage.Segue abaixo um de acesso ao ZODB com ZEO e ClientStorage retirado do ZODB Guide:from ZEO import ClientStoragefrom ZODB import DBimport transaction# modificar essa linha de acordo com a configuracao do servidor ZEOaddr = 'zeoserver.example.com', 1975storage = ClientStorage.ClientStorage(addr)db = DB(storage)conn = db.open()root = conn.root()# vamos armazenar uma lista e um dicionario no objeto raizroot['lista'] = ['a', 'b', 1.0, 3]root['dicionario'] = {'a':1, 'b':4}# o ZODB e um banco ACID e transacional, e preciso fazer o commit# no caso do ZOPE, esse commit e automatico caso exista uma excecao nao tratadatransaction.commit()Dessa forma, cada instancia da aplicacao cliente acessa o ZEO usando o Storage Layer ClientStorage para se concectar ao banco de dados compartilhado pelo servidor ZEO. Para o tratamento de concorrencia, o ZEO / ZODB utiliza um mecanismo "otimista" de controle de conflitos entre transacoes que acessam os mesmo objetos, se um conflito ocorrer, uma excecao do tipo "ConflictError" e levantada para avisar o problema a aplicacao cliente.O conjunto de ZEO + FileStorage e aplicacao cliente (Zope por exemplo) + ClientStorage permite que os mesmos arquivos de dados ZODB no formato FileStorage sejam acessados simultanemente para criacao de Clusters, muito usados para aumentar o desempenho de sites de alto trafego que usam Zope/Plone, por exemplo.Essa combinacao, apesar de ser a unica alternativa para "compartilhar" o ZODB por varias instancias de uma aplicacao, possui algumas limitacoes de escalabilidade e redundancia:O ZEO e uma aplicacao Python e devido ao GIL (Global Lock Interpreter) ele somente consegue ser escalonado em uma CPU por vez e, por isso, nao aproveita melhor os sistemas com varios processadores/nucleos. Essa limitacao prejudica a escalabilidade do backend e pode ser percebida quando muitas instancias da aplicacao precisam acessar ou gravar dados ao mesmo tempo.A Zope Corp possui um componente proprietario, o Zope Replication Services, que e vendido separadamente para replicacao de bases de dados ZODB + FileStorage, possibilitando replicar em tempo real o servidor ZEO, conseguindo entao uma solucao de alta disponibilidade, porem o custo e alto e proibitivo para a maioria das organizacoes e situacoes de uso do ZODB.Quanto mais objetos no ZODB,