Onde nasceu ?

Dados do Linkedln e anlise da equipe pesquisa, anlise e hadoop e dados gasoduto pesquisar grfico social Caltrain chefe muito branda

dois vivas para o modelo de dados relacional A viso relacional um triunfo da cincia da computao, mas ... colar juntos cordas para chegar a seus dados bobagem duro para construir estruturas de dados reutilizveis no escondem a hierarquia de memria! bom: arquivos de sistemas API ruim: SQL, alguns RPCs por que to difcil?

Falhas em um sistema distribudo muito mais complicada Um pode falar com B no implica B pode conversar com um

Voldemort um repositrio de dados distribudo que concebido como umarmazenamento de chave-valor utilizado pelo LinkedIn para armazenamento de alta escalabilidade. nomeado aps o fictcio Harry Potter vilo Lord Voldemort . Voldemort ainda est em desenvolvimento. No nem banco de dados de um objeto, nem um banco de dados relacional. Ele no tentar satisfazer relaes arbitrrias e asACID propriedades, mas sim um grande, distribudo, tolerante a falhas, tabela persistente hash.

Vantagens
Voldemort oferece uma srie de vantagens em relao a outras bases de dados: Combina na memria cache com o sistema de armazenamento de modo que uma camada de armazenamento em cache separado no necessrio (em vez do sistema de armazenamento em si apenas rpido) possvel emular a camada de armazenagem, uma vez que completamente mockable. Isso faz com que o desenvolvimento e o teste de unidade simples, em que pode ser feito contra um sistema de armazenamento de usar e deitar fora de memria sem a necessidade de um cluster real ou sistema de armazenamento real L e escreve escala horizontal Simple API: A API decide replicao de dados e colocao e acomoda uma ampla gama de aplicaes especficas estratgias Dados transparentes porcionamento: Este permite a expanso cluster sem reequilbrio todos os dados

Propriedades
O Voldemort armazenamento de dados distribudos tem as seguintes propriedades:
[1]

Colocao de dados: Suporte para conectveis estratgias de posicionamento de dados existe para apoiar coisas como distribuio em centros de dados que esto distantes. A replicao de dados: Os dados so automaticamente replicadas ao longo de um grande nmero de servidores. Dados particionamento: Os dados so automaticamente dividida de modo que o servidor contm apenas um subconjunto dos dados totais Desempenho do n nico bem: 10-20k de operaes por segundo pode ocorrer dependendo das mquinas, a rede, o sistema de disco, eo fator de replicao de dados Independncia n: Cada n independente de outros ns sem ponto central de falha ou coordenao Serializao Pluggable: Este permite que as chaves ricos e valores, incluindo listas e tuplas com campos nomeados, bem como a integrao com frameworks de serializao comuns. Exemplos dessas estruturas so Avro, serializao de Java, Protocol Buffers, e Thrift Falhas transparentes: falhas do servidor so manipuladas de forma transparente, de modo que o usurio no ver tais problemas Controle de verso: Os itens de dados so verses para maximizar a integridade dos dados em caso de falha, sem comprometer a disponibilidade do sistema

Valor-chave de armazenamento
Para habilitar alto desempenho e disponibilidade que permitem apenas muito simples de valor-chave de acesso de dados. Ambas as chaves e os valores podem ser objetos compostos complexos, incluindo listas ou mapas, mas nada-a-menos as consultas apenas suportados so efetivamente o seguinte: valor = store.get (chave) store.put (valor, chave) store.delete (chave) Este no de forma suficientemente boa para todos os problemas de armazenamento, h uma variedade de trade-offs: Contras

sem complexos filtros de consulta tudo se junta deve ser feita no cdigo sem restries de chave estrangeira no desencadeia

Prs

apenas consultas eficientes so o desempenho possvel, muito previsvel fcil de distribuir atravs de um cluster de orientao a servios muitas vezes no permite restries de chaves estrangeiras e foras de junta a ser feito em cdigo de qualquer maneira (porque chave se refere a dados mantidos por outro servio) utilizando um banco de dados relacional que voc precisa de uma camada de cache para escalar l, a camada de cache normalmente obriga em valores-chave de armazenamento de qualquer maneira muitas vezes acabam com XML ou outros blobs desnormalizada para o desempenho de qualquer maneira separao limpa de armazenamento e lgica (SQL incentiva lgica buisiness mistura com as operaes de armazenamento para maior eficincia) nenhum objeto-relacional perder-jogo

Mais discusso dos detalhes do modelo de dados, ser dada a seguir.

Arquitetura do Sistema

Cada camada no cdigo implementa uma interface de armazenamento simples que no colocar, obter e excluir. Cada uma dessas camadas responsvel por executar uma funo, como a comunicao TCP / IP, serializao, reconciliao verso, entre os ns de roteamento, etc Por exemplo, a camada de roteamento responsvel por tomar uma operao, digamos, um PUT, e delegando-a todos os N rplicas de armazenamento em paralelo, ao manusear quaisquer falhas.

Mantendo cada uma destas camadas separadas significa que eles podem ser misturados e combinados no tempo de execuo para atender diferentes necessidades. Por exemplo, podemos adicionar uma camada de compresso que comprime valores de byte em qualquer nvel abaixo do nvel de serializao.Da mesma forma que temos a flexibilidade de onde o roteamento inteligente de dados para parties feito. Isso pode ser feito no lado do cliente para "inteligentes" clientes, ou pode ser feito no lado do servidor para permitir mudos, hardware clientes com balanceamento de carga (http dizer escrita em Ruby). O que fazemos simplesmente uma questo de se a camada de rede fica acima ou abaixo da camada de roteamento.

No diagrama acima, "Carregar Bal". indica um balanceador de carga de hardware ou round-robin balanceador de carga de software e "Partition roteamentoconsciente" o armazenamento de sistemas de roteamento interno. Obviamente menos lpulo bom do ponto de vista de latncia (desde, bem, h menos saltos), agradvel do ponto de vista de transferncia (j que h menos potenciais gargalos), mas requer a inteligncia de roteamento para subir na pilha (por exemplo, o cliente deve ser Java e usar a nossa biblioteca). Na final, a imagem mais direita os pedidos http-RPC para o servio esto a ser encaminhados para as mquinas que contm os dados corretos (quando possvel), para que, no caso simples de um nico replicado ler a necessidade mquina pode buscar diretamente do local, bdb-processo. Essa flexibilidade torna configuraes de alto desempenho possvel. O acesso ao disco o nico grande desempenho atingido no armazenamento, o segundo o lpulo de rede. O acesso ao disco pode ser evitado atravs do particionamento do conjunto de dados e armazenamento em cache, tanto quanto possvel. Lpulo rede exigem flexibilidade de arquitetura para eliminar. Note que, no diagrama acima, podemos implementar 3-hop, 2-hop, e 1-hop servios remotos usando

configuraes diferentes. Esta permite um desempenho muito elevado para ser alcanado quando possvel encaminhar chamadas directamente servio para o servidor apropriado. Dados particionamento e replicao Dados precisa ser particionado em um cluster de servidores de modo que nenhum nico servidor precisa manter o conjunto de dados completo. Mesmo quando os dados podem caber em um nico disco, o acesso ao disco para valores pequenos dominado por tempo de busca para particionamento tem o efeito de melhorar a eficincia do cache, dividindo o conjunto "quente" de dados em pequenos pedaos que podem (espero) ser totalmente em memria no servidor que armazena essa partio. Isto significa que os servidores no cluster no so intercambiveis, e os pedidos devem ser encaminhados para um servidor que contm os dados solicitados, e no apenas a qualquer servidor disponvel de forma aleatria. Da mesma forma os servidores regularmente no, tornar-se sobrecarregado, ou so levadas em manuteno. Se existirem S servidores e cada servidor assumido falhar independentemente com probabilidade p em um determinado dia, ento a probabilidade de perda de pelo menos um servidor de um dia, ser de 1 (1 - p ) s . bvio que este fato, no se pode armazenar dados em um nico servidor ou a probabilidade de perda de dados ser inversamente proporcional ao tamanho do cluster. A maneira mais simples possvel para alcanar este objetivo seria cortar os dados em S parties (um por servidor) e armazene cpias de uma determinada chave K em R servidores. Uma maneira de associar osR servidores com chave K seria tomar um = K mod S e armazenar o valor em servidores um , um , um ...,um + r . Assim, para qualquer probabilidade p voc pode escolher um fator apropriado replicao R para alcanar uma probabilidade aceitavelmente baixo de perda de dados. Este sistema tem a propriedade interessante que qualquer pessoa pode calcular a localizao de um valor apenas por saber de sua chave, o que nos permite fazer look-ups de uma forma peer-to-peer sem contato com um servidor central de metadados que tem um mapeamento de todas as chaves aos servidores. A desvantagem da abordagem acima ocorre quando um servidor adicionado ou retirado do cluster (dizer, porque ns compramos um novo hardware ou um servidor est temporariamente fora do ar). Neste caso dpodem mudar e todos os dados iro deslocar entre os servidores. Evento se d no muda carga no vai distribuir uniformemente a partir de um nico servidor removido / falha para o resto do agrupamento.

Hashing consistente uma tcnica que evita esses problemas, e podemos us-lo para calcular a localizao de cada tecla no cluster. Usando esta tcnica voldemort tem a propriedade de que, quando um servidor falhar carga ir distribuir igualmente sobre todos os servidores restantes no cluster. Da mesma forma, quando um novo servidor adicionado a um conjunto de S servidores, apenas 1 / ( S +1) valores devem ser movidos para a nova mquina. Para visualizar o mtodo de hash consistente, podemos ver as possveis inteiros valores de hash como um anel comeando com 0 e circulando em torno de 2 ^ 311. Este anel dividido em Q parties de tamanho igual, com Q >> S , e cada um dos S servidores atribudo Q / S destes. Uma chave mapeada para o anel usando uma funo arbitrria hash, e ento calcular uma lista de R servidores responsveis por esta chave, tendo os primeiros R ns nicos quando se mover sobre as parties no sentido horrio. O diagrama abaixo fotos um anel de hash para servidores A , B , C , D . As setas indicam as teclas mapeadas no anel de hash ea lista resultante de servidores que ir armazenar o valor para essa chave seR = 3.

Formato de dados e consultas

Em um banco de dados relacional de dados dividido em mesas 2D. O equivalente aqui uma "loja", no usamos a palavra tabela, pois os dados no necessariamente tabular (um valor pode conter listas e mapeamentos que no so consideradas em um mapeamento rigoroso relacional). Cada chave nica para uma loja, e cada chave pode ter, no mximo, um valor.

Consultas

Voldemort suporta semntica hashtable, para um nico valor pode ser modificado em um tempo e de recuperao de chave primria. Isso faz com que a distribuio atravs de mquinas particularmente fcil, j que tudo pode ser dividido pela chave primria. Note-se que, apesar de no apoiar um-muitos relaes, fazemos listas de apoio como valores que realiza a mesma coisa - por isso, possvel armazenar um nmero razovel de valores associados a uma nica tecla. Isto corresponde a um java.util.Map onde o valor um java.util.List. Na maioria dos casos desnormalizao uma melhoria de desempenho enorme uma vez que existe apenas um nico conjunto de pesquisas em disco, mas para grandes relacionamentos um-para-muitos (digamos que uns mapas chave para dezenas de milhes de valores), que deve ser mantido no servidor e transmitido atravs de um cursor preguiosamente esta abordagem no prtico. Este caso (raro) deve ser dividido em sub-consultas ou no tratadas a nvel de aplicao. A simplicidade dos procedimentos podem ser uma vantagem, uma vez que cada uma tem um desempenho muito previsvel, fcil de quebrar o desempenho de um servio para o nmero de operaes de armazenagem executa rapidamente e estimar a carga. Em contraste consultas SQL so muitas vezes opaco, e os planos de execuo pode ser dependente dos dados, por isso pode ser muito difcil de estimar se uma determinada consulta ter um bom desempenho com dados realistas sob carga (especialmente para um novo recurso que no tem nem dados, nem de carga). Alm disso, ter uma interface de operao de trs permite transparentemente zombar fora da camada de armazenamento de todo e teste de unidade usando uma implementao de simulao-de armazenamento que um pouco mais do que um HashMap. Isso faz com que o teste de unidade exterior de um recipiente ou ambiente muito mais prtica.

Modelo de Dados e serializao

Serializao em Voldemort conectvel assim voc pode usar um dos cozido em serializers ou facilmente escrever a sua prpria. No nvel mais baixo do formato de dados para Voldemort apenas matrizes de bytes para ambas as chaves e valores. Formatos de nvel mais alto de dados so uma opo de configurao que so definidos para cada loja - qualquer formato pode ser apoiado atravs da implementao de uma classe Serializer que lida com a traduo entre bytes e objetos. Isso garante que o cliente serializa os bytes corretamente. Os seguintes tipos so suportados fora da caixa, inserindo o tipo apropriado na configurao da loja:

json - Um binrio, digitado JSON modelo de dados que suporta listas, mapas, datas, valores booleanos e nmeros de preciso diferentes. Este o tipo de serializao s que tem um mapeamento completo de bytes <-> objetos e de cordas <-> objetos. Isto significa que pode ser interagido com como SQL (por exemplo, atravs do cliente de linha de comando). Nossa utilizao da produo atual utiliza uma digitado, compacto, esquema check formato JSON-like, mas isso no tem nenhum estatuto especial, e para outras aplicaes de outros mecanismos de serializao pode ser melhor. corda - Apenas armazena cordas primas. til para blobs XML. java-serializao - Nosso velho amigo de serializao Java. Certifique-se de entender a compatibilidade garante serializao java fornece antes de armazenar muitos objetos java. protobuf - buffers Protocolo um formato de serializao de gerao de cdigo do Google. Esta pode ser a melhor maneira de ir, se voc no precisa de acesso linha de comando. thrift - Thrift outro formato de serializao gerao de cdigo. avro-generic / avro especfica / avro-reflexivo - Avro outro sistema de serializao de dados rich. identidade - Isso efetivamente desativa serialialization, apenas dando-lhe de volta o byte exata [].

String e serializao de identidade so bastante auto-explicativo. Documentao / Tutorial para os formatos de serializao outros podem ser facilmente encontrados na internet. Assim, o restante desta seo descreve a motivao por trs do tipo json. Tipo de serializao JSON Detalhes Existem trs estados que os dados podem residir, e ns queremos ser capazes de traduzir entre todos eles:

Em estruturas de dados de memria: por exemplo, um objeto Usurio Bytes para transmisso de persistncia e de rede Representao de texto: essencial ser capaz de ter um DBA verificar certos valores e fazer atualizaes on-line sem escrever novo cdigo

SQL, basicamente, em torno de padroniza o formato de consulta de texto e programas de lidar com o mapeamento entre essas cordas e as estruturas de dados internos do programa usa. Este o problema de mapeamento objetorelacional clssico. JSON um excelente modelo de dados para armazenamento, pois suporta os tipos comuns que so usados em todas as linguagens de programao (strings,

nmeros, listas / matrizes e objetos / tabelas de hash), o problema que ele inerentemente sem esquema. O uso mais comum para todo o problema fazer com que o armazenamento de N linhas, todos com o mesmo formato exacto (ou seja, contendo as mesmas colunas), neste caso JSON um desperdcio, uma vez que armazena o formato de dados em cada linha. Da mesma forma que queremos ser capazes de verificar afirmaes sobre a forma de os dados para evitar que erros de digitao uma coluna para armazenar dados corrompidos. Para evitar isso, devemos ser capazes de atribuir um esquema para a chave eo valor de cada loja que descreve o que permitido para armazenar l e como traduzi-lo para e de bytes. O esquema pode-se ser especificado em JSON, bem como, utilizando os seguintes tipos: int8, int16, int32, int64, float32, float64, objeto de data, string, objeto, bytes, boolean, array, Por exemplo, se eu esperar uma loja para conter cadeias ento eu posso especificar o tipo de tabela j que "String" Note que esta definio de tipo , em si JSON vlido O cdigo java que busca dados ir retornar uma String Se eu esperar a loja para conter uma lista de nmeros inteiros, digamos, ids membros, posso especificar o tipo ["Int32"] O cdigo java ir retornar uma List <Integer>. Se eu esperar a loja para conter um objeto de usurio simples que eu poderia definir o tipo {"Fname": "string", "sobrenome": "string", "id": "int32", "e-mails": ["string"]} Aqui, o cdigo Java retornar uma <String,Object> mapa contendo cada uma das teclas de dados, e o valor associado. Aqui est uma lista completa de tipos permitidos: definio do tipo de exemplo

tipo

subestilos bytes usados armazenveis

Tipo Java

exemplo JSON

int8, int16, int32, Byte, Short, 8, 16, 32, 64, nmero int64, float32, Integer, Long 1 32, 64, 32 float64 data, Float, duplo, data 2+ comprimento String, Byte [] de corda ou bytes 1 Boolean

"Int32"

corda

cordas, bytes

"Ol"

"String"

boolean boolean

verdadeiro {"Key1": 1, "Key2": "2", "key3": false} [1, 2, 3]

"Boolean" {"Nome": "string", "height": "int16"} ["Int32"]

objeto

objeto

1 tamanho + Mapa de contedos <String,Object> tamanho * sizeof (tipo)

ordem ordem

List <>

Neste sentido, a definio de tipo um conjunto de restries de padro json que fazem serializao eficiente (por meio da distribuio de fora campos repetidos e armazenar nmeros compacta) e permitir a checagem de dados bsicos de correo. Note-se que mesmo que um valor pode ter todos esses campos diferentes que s suportam consultas por chave definida da loja. Para ajudar com a evoluo do esquema esta implementao JSON inclui a capacidade de verso do esquema para permitir a migrao gradual dos dados. Os dados sero sempre gravados usando o esquema mais recente, mas ser sempre ler usando qualquer esquema foi usado para escrever. Isso permite que a migrao de esquema para ter lugar sem derrubar o servio que recebe os dados.

Consistncia e Versioning
Ao tomar simultnea mltipla escreve distribudos em vrios servidores (e talvez vrios centros de dados) de consistncia de dados torna-se um problema difcil. A soluo tradicional para este problema distribudo transaes, mas estes so ambos. Lenta (devido a muitas idas) e frgil como eles exigem que todos os servidores de estar disponvel para processar uma transaco Em particular, qualquer algoritmo que deve falar com> 50% de servidores para garantir a consistncia torna-se bastante problemtica se o aplicativo executado em vrios centros de dados e, portanto, a latncia para o cruzamento de dados do centro de operaes ser extremamente alto.

Uma soluo alternativa a tolerar a possibilidade de inconsistncia, e resolver inconsistncias em tempo de ler. Esse o mtodo utilizado aqui. Aplicaes costumam fazer uma leitura-modificao-atualizar seqncia ao modificar dados. Por exemplo, se um usurio adiciona um endereo de e-mail sua conta, pode carregar o objeto de usurio, adicionar o e-mail, e em seguida, escrever os novos valores de volta para o banco de dados. As transaes em bancos de dados so uma soluo para este problema, mas no so uma opo real quando a transao deve abranger cargas de vrias pginas (que pode ou no pode ser concluda, e que pode terminar em qualquer perodo de tempo especfico) O valor para uma determinada chave consistente se, na ausncia de alteraes, todas as leituras de retorno que o mesmo valor de chave. No mundo s de leitura de dados criado de uma forma consistente e no mudou. Quando acrescentamos tanto escreve, e replicao, encontramos problemas: agora precisamos atualizar vrios valores em vrias mquinas e deixar as coisas em um estado consistente. Na presena de falhas no servidor isso muito difcil, na presena de parties de rede comprovadamente impossvel (a partio quando, por exemplo, A e B podem alcanar um ao outro e C e D podem alcanar um ao outro, mas A e B pode 't alcance C e D). Existem vrios mtodos para alcanar a consistncia com diferentes garantias e compensaes de desempenho.

Duas fases - Este um protocolo de bloqueio que envolve duas rodadas de coordenao entre as mquinas. perfeitamente consistente falha, mas no tolerantes, e muito lenta. Paxos estilo de consenso - Este um protocolo para chegar a um acordo sobre um valor que mais tolerante fracasso. Leia-reparao - As duas primeiras abordagens evitar inconsistncia permanente. Esta abordagem envolve a escrita de todas as verses inconsistentes, e depois para ler o tempo de deteco do conflito, e resolver os problemas. Isso envolve pouca coordenao e completamente falha tolerante, mas pode exigir a lgica de aplicao adicional para resolver conflitos.

Ns usamos verses e leitura de reparao. Isto tem uma das melhores garantias de disponibilidade e maior eficincia (apenas W escreve ida e volta de rede so necessrios para rplicas N onde W pode ser configurado para ser inferior a N). 2PC normalmente requer 2N roundtrips bloqueio. Variaes Paxos variar um pouco, mas so comparveis aos 2PC.

Outra abordagem para atingir a consistncia usando Handoff sugeriu . Neste mtodo durante as gravaes, se acharmos que os ns de destino so para baixo ns armazenamos uma "dica" do valor atualizado em um dos ns vivos. Ento, quando esses ns para baixo voltar as "dicas" so empurrados para eles, tornando os dados consistente. Muitos dos detalhes so emprestados do papel da Amaznia abaixo Aqui esto alguns bons textos sobre este assunto:

Consistncia na Dynamo da Amazon Paxos Made Simple Duas fases O significado de consistncia eventual (por CTO da Amazon, Werner Vogels)

Controle de verso em um sistema distribudo

Um sistema de controle de verso simples otimista bloqueio armazenamos um balco nico ou "relgio" valor com cada pedao de dados e s permitir atualizaes quando a atualizao especifica o valor do relgio correta. Isso funciona bem em um banco de dados centralizado, mas cai em um sistema distribudo onde os servidores aparecem e desaparecem e replicao pode levar tempo. Para isso o uso de um nico valor no ir conter o suficiente da histria escrita para nos permitir jogar fora verses antigas. Considere a seguinte seqncia de aes: # Dois servidores ao mesmo tempo buscar o mesmo valor [Cliente 1] chegar (1234) => {"nome": "Jay", "email": "jay.kreps @ linkedin.com"} [Cliente 2] se (1234) => {"nome": "Jay", "email": "jay.kreps @ linkedin.com"} # Cliente uma modifica o nome e faz um put [Cliente 1] colocar (1234, {"nome": "jay Kreps", "e-mail": "jay.kreps @ linkedin.com"}) # 2 modifica o cliente de e-mail e faz um put [Cliente 2] colocado (1234, {"nome": "Jay", "email": "jay.kreps @ yahoo.com"}) # Agora temos as seguintes verses conflitantes: {"Nome": "Jay", "email": "jay.kreps @ linkedin.com"} {"Nome": "jay Kreps", "e-mail": "jay.kreps @ linkedin.com"} {"Nome": "Jay", "email": "jay.kreps @ yahoo.com"}

Neste modelo os dois ltimos escreve tornar irrelevante o valor original (desde que acontecer depois da original). No entanto no h nenhuma regra que ir dizer ao servidor que ele pode jogar fora ou se muda para o e-mail ou a mudana de nome. Ento, ns queremos um sistema de controle de verso que permite detectar substitui e jogar fora a verso antiga, mas tambm nos permite detectar conflitos e deixar o cliente conciliar estes. Uma resposta a isso uma assim chamada verso vetor de relgio. Um relgio vetor mantm um contador para cada servidor escrito, e nos permite calcular quando duas verses esto em conflito, e quando uma verso bem-sucedida ou precede outro. Um relgio vetor uma lista de servidor: pares de verso: [1:45,2:3,5:55] A verso indica que o servidor era o "mestre" para que o nmero de gravaes. Uma verso v1 consegue uma verso v2 se para todo i , v1 i > v2 i . Se nem v1 > v2 nem v1 < v2 , entov1 e v2 co-ocorrer, e esto em conflito. Aqui est um exemplo simples de duas verses conflitantes: [1:2,2:1] [1:1,2:2] Assim, nosso esquema de verses define uma ordem parcial sobre os valores que simples esquemas de bloqueio otimista definem uma ordem total .

Parmetros de roteamento
Qualquer sistema persistente precisa responder pergunta "onde est o meu material?". Esta uma pergunta muito fcil se tivermos um banco de dados centralizado, pois a resposta sempre "em algum lugar no servidor de banco de dados". Num sistema de chave dividida existem vrias mquinas que podem ter os dados. Quando fazemos uma leitura precisamos ler a partir de pelo menos um servidor para obter a resposta, quando fazemos uma gravao que precisamos (finalmente) escrever a todos N das rplicas. Existem, portanto, trs parmetros que importam:

N - O nmero de rplicas R - O nmero de mquinas de ler a partir de W - O nmero escreve bloquear para

Note que se R + W > N ento temos a garantia de "ler nosso escreve". Se W = 0, em seguida, as gravaes so no-bloqueio e no h garantia de que quer o sucesso. Puts e excluses no so consistentes nem seja imediatamente isolado. A semntica esta: se uma operao de colocar / apagar sucede, sem exceo, ento garantido que pelo menos W ns realizou a operao, no entanto, se a gravao falhar (digamos, porque ns muito poucos conseguem realizar a operao), ento o Estado indeterminado. Se pelo menos um posto / apagar consegue, ento o valor ser eventualmente o novo valor, no entanto, se nenhum conseguiu ento o valor perdido. Se o cliente quer garantir o estado depois de uma operao de escrita no devem emitir outra gravao.

Camada de persistncia
Apoiamos uma API simples para persistncia e uso BDB edio Java como padro. Outros mecanismos de armazenamento suportados so MySQL, o armazenamento em memria (utilizado para o teste de unidade) e nosso mecanismo de armazenamento prprio costume de somente leitura (gerados offline como um processo de lote em Hadoop). Para adicionar uma nova implementao de persistncia voc precisa implementa colocar, obter, excluir e, alm de fornecer um iterador sobre os valores na loja local.

Suporte para lote computadorizada de dados read-only lojas

Uma das necessidades mais intensivas de dados de armazenamento armazenar os dados do lote calculados sobre os membros e contedo do nosso sistema. Estes postos de trabalho, muitas vezes lidar com as relaes entre as entidades (por exemplo, os usurios relacionados, ou artigos de notcias relacionadas) e assim por N entidades podem produzir at N 2 relacionamentos. Um exmaple no LinkedIn so as redes membros, que esto na faixa 12TB se armazenado explicitamente para todos os membros.Processamento em lote de dados geralmente muito mais eficiente do que o acesso aleatrio, o que significa que se pode facilmente produzir mais dados em lote computadorizada que podem ser facilmente acessados pelo sistema vivo. Hadoop expande essa capacidade. Estamos no processo de open-sourcing um. Voldemort persistncia backend que suporta muito eficiente acesso somente leitura que ajuda a ter um monte de dor de nossos criao, implantao e gesto de grandes, somente leitura lote conjuntos de dados computadorizada Grande parte da dor de lidar com computao lote vem do processo de "push", que transfere dados de um data warehouse ou instncia hadoop ao sistema vivo. Em um db tradicional este, muitas vezes, significa a reconstruo do ndice

no sistema ao vivo com os novos dados. Fazendo milhes de instrues SQL INSERT ou UPDATE, geralmente no de todo eficiente, e, normalmente, em um db SQL os dados sero implantados como uma nova tabela e, em seguida, trocou para substituir os dados atuais quando a nova tabela completamente construdo. Isso melhor do que fazer milhes de atualizaes individuais, mas isso ainda significa que o sistema vivo est agora construindo um ndice GB de muitos, para o novo conjunto de dados (ou Performa), ao mesmo tempo servindo de trfego ao vivo. Isso por si s pode levar horas ou dias, e pode destruir o desempenho em consultas ao vivo. Algumas pessoas tm fixado este trocando no nvel de banco de dados (por exemplo, ter uma db online e offline, e depois troca), mas isso requer esforo e significa apenas metade hardware do seu est sendo utilizada. Voldemort corrige esse processo, tornando possvel a Prebuild o prprio ndice offline (em Hadoop ou onde), e simplesmente empurr-lo para fora aos servidores ao vivo e transparente trocar. Para mais detalhes sobre estas lojas lote computadorizada (chamado somente leitura lojas) ler esta .

Referncias

Dynamo: altamente disponvel Amaznia loja Key-Value - Este o original! Tempo, Clocks, ea Ordenao de Eventos em um Sistema Distribudo Este o modelo para o sistema de controle de verses Consistncia eventual Revisited discusso muito interessante no Blog Werner Vogels 'na interao com os desenvolvedores do sistema de armazenamento e quais as vantagens e desvantagens significa em termos prticos. Conjectura de cerveja e da viabilidade de consistentes, disponveis, servios partio tolerantes web - Consistncia, Disponibilidade, Partio tolerncia escolher dois. Berkeley DB desempenho - Uma viso um tanto tendenciosa do desempenho bdb. Google Bigtable - Para efeito de comparao, uma abordagem muito diferente. Um Fit Tamanho tudo: uma idia cujo tempo chegou e saiu - Papel muito interessante pelo criador de Ingres, Postgres e Vertica Tamanho nico? - Parte 2, resultados comparativos - Benchmarks para ir com o papel acima Consistncia na Dynamo da Amazon - Um bom post sobre Dynamo Paxos Made Simple Duas fases - Wikipdia descrio.

Configurao
H trs arquivos de configurao que a operao do servidor de controle:

cluster.xml - Este contm as informaes sobre todos os ns (servidores, por exemplo) no cluster, o que eles esto em nome de host, as portas que eles usam, etc exatamente o mesmo para todos os ns de Voldemort. No guarda parmetros de ajuste ou diretrios de dados para os ns, j que no informao pblica ao cluster, mas especfico para que a configurao de ns em particular. stores.xml - Este contm as informaes sobre todas as lojas (tabelas, por exemplo) no cluster. Isso inclui informaes sobre o nmero necessrio de sucesso l para manter a consistncia, o nmero necessrio de gravaes, bem como a forma como chaves e valores so serializados em bytes. o mesmo em todos os ns do cluster. server.properties - Este contm os parmetros de ajuste que controlam um determinado n. Isto inclui o ID do n local para que ele saiba o que a entrada em cluster.xml corresponde a si mesma, tambm o tamanho do pool de threads, bem como qualquer configurao necessria para o mecanismo de persistncia local, tais como BDB ou mysql. Este arquivo diferente em cada n.

Finalmente, h uma varivel de ambiente, VOLDEMORT_HOME, que controla o diretrio no qual dados e configurao residem. Voc pode ver um exemplo de como a configurao Definiu no. Config / subdiretrio do projeto Isto inclui configuraes de exemplo que voc pode modificar com suas especificidades prprias.

Configurao de cluster
Aqui est um exemplo cluster.xml para um cluster de 2 ns com 8 parties de dados. Ns tambm temos opcionais "zona" campos que permitem mapear os ns para determinados grupos lgicos (datacenter, rack, etc) chamadas zonas: <cluster> <-! O nome apenas para ajudar os usurios a identificar este cluster do gui -> <name> mycluster </ name> <Zone> <zone-id> 0 </ zona-id> <proximity-list> 1 </ proximidade lista-> <Zone> <Zone> <zone-id> 1 </ zona-id>

<proximity-list> 0 </ proximidade lista-> <Zone> <servidor> <-! O ID de n nico, um incio ID seqencial com 0 que identifica cada servidor no cluster -> <id> 0 </ id> <host> vldmt1.prod.linkedin.com </ host> <http-port> 8081 </ http-port> <socket-port> 6666 </ socket porta-> <admin-port> 6667 </ admin porta-> <-! Uma lista de parties de dados atribudos a este servidor -> <partitions> 0,1,2,3 </ parties> <zone-id> 0 </ zona-id> </ Server> <servidor> <id> 1 </ id> <host> vldmt2.prod.linkedin.com </ host> <http-port> 8081 </ http-port> <socket-port> 6666 </ socket porta-> <admin-port> 6667 </ admin porta-> <partitions> 4,5,6,7 </ parties> <zone-id> 1 </ zona-id> </ Server> <Cluster /> Uma coisa que importante entender que as parties no so parties estticas de servidores, mas eles so um mecanismo para particionar o espao da chave de tal forma que cada tecla estaticamente mapeado para uma partio de dados em particular. O que isto significa que um determinado cluster pode suportar muitas lojas cada uma com replicao diferentes fatores, o fator de replicao no codificado no projeto do cluster. Isto importante, uma vez que alguns dados mais importante do que os outros dados, e o correcto equilbrio entre o desempenho e consistncia de uma loja pode ser diferente da outra loja. Outro ponto importante a lembrar que o nmero de parties de dados no podem ser alterados.Fazemos apoiar uma redistribuio online (reequilbrio) de parties. Em outras palavras, a incluso de novos resultados em gnglios movendo propriedade de divisrias, mas o nmero total de parties ir sempre permanecer o mesmo, assim como o mapeamento de chave para partio. Isto significa que importante dar um bom nmero de parties para comear. O script aqui vai gerar esta parte da configurao para voc. Note-se que a configurao atualmente arquivos simples por isso importante que os dados em cluster.xml e stores.xml ser exatamente o mesmo em cada servidor, e que as IDs de ns e parties no pode ser alterado, uma vez que pode significar que os clientes vo pensar seus dados devem estar no n X, quando na

verdade ele foi armazenado no n Y . Esta limitao ser removida como a configurao movida em voldemort si.

Configurao da loja
Aqui um stores.xml exemplos de uma loja chamada de teste, que requer apenas uma nica leitura e escrita e usa bdb para persistncia: <stores> <store> <name> teste </ nome> <replication-factor> 2 </ replicao fator-> <preferred-reads> 2 </ preferencial l-> <required-reads> 1 </ requerido l-> <preferred-writes> 2 </ preferencial-escreve> <required-writes> 1 </ requerido-escreve> <persistence> bdb </ persistence> <routing> cliente </ routing> <routing-strategy> consistente de roteamento </ rota estratgia> <key-serializer> corda <type> tipo </> <schema-info> utf8 </ esquema info-> </ Key serializador-> <value-serializer> <type> json </ type> <schema-info version="1"> [{"id": "int32", "nome": "string"}] </ esquema info-> <compression> <type> gzip <type> <Compresso /> </ Value serializador-> </ Loja> </ Lojas> Cada um desses parmetros merece uma discusso rpida:

Nome - O nome da loja. Esta a seqncia em que os clientes sero capazes de conectar e operar sobre esta loja. equivalente ao nome da tabela no SQL. replicao factor - Este o nmero total de vezes que os dados so armazenados. Cada colocar ou apagar operao deve, eventualmente, acertar esta muitos ns. Um factor de replicao de nsignifica que pode ser possvel tolerar at n - 1 falhas de n sem perda de dados. preferido-l (opcional)-O nmero de sucesso l o cliente ir tentar fazer antes de retornar um valor para a aplicao. O padro a ser igual a leituras necessria

necessrio-l -O nmero mnimo de leituras que podem ter sucesso sem lanar uma exceo.Considere um caso em que o factor de replicao 5, leituras preferida 4, e l-se necessrio 2.Se trs dos cinco ns so operacionais, ento o cliente pode experimentar todos os ns para tentar chegar a 4 preferido l, mas uma vez que apenas trs so sensveis permitir a leitura para completar. Havia apenas um sido sensvel teria jogado uma exceo, j que era menor do que a garantia de consistncia solicitado para esta tabela (e que poderia significar retornar dados obsoletos). preferido-escreve (opcional)-O nmero de sucesso escreve o cliente tenta bloquear antes de voltar para o sucesso. O padro exigido-escreve necessrio-escreve - O menor nmero de gravaes que podem ter sucesso sem o cliente voltar uma exceo. persistncia - O backend de persistncia utilizada pela loja. Atualmente, esse poderia ser um dos bdb, mysql , memria , readonly , e de cache . A diferena entre o cache e memria que a memria vai jogar e OutOfMemory exceo se torna maior do que a pilha da JVM enquanto o cache ir descartar dados. roteamento - Determina a poltica de roteamento. Apoiamos tanto cliente (Client lado de roteamento) e servidor (encaminhamento do lado do servidor). encaminhamento estratgia - Determina como armazenamos as rplicas. Atualmente ns suportamos trs roteamento-estratgias consistente de roteamento (padro), zona de roteamento etodoroteamento . serializador-chave - O tipo de serializao usado para ler e gravar chaves . O tipo pode ser json ,javaserializao , corda , protobuff , parcimnia , ou identidade (ou seja, bytesprimas). O esquema info-d informaes para o serializador sobre como realizar o mapeamento (por exemplo, o esquema descrito no JSON aqui ). valor serializador- - O tipo de serializao usado para ler e escrever valores . Os tipos suportados so os mesmos que para as chaves. No exemplo acima, destacam-se ainda "compresso" o subelemento que atualmente suporta 'gzip' e 'lzf "compresso. Os subelementos so os mesmos que para a chave serializador, exceto que o serializador o valor pode ter vrios esquemas-infos com verses diferentes. A verso mais recente a usada para gravar dados, mas os dados sempre lido com a verso que foi escrito com. Isto permite a evoluo do esquema gradual. Controle de verso suportada apenas pelo serializador JSON como formatos de serializao outros tm os seus sistemas de controle de verso prprios. Aqui esto algumas serializers exemplo:

<-! Uma serializador que serializa cordas simples na codificao UTF8 -> <value-serializer> corda <type> tipo </> <schema-info> utf8 </ esquema info-> </ Value serializador-> <-! Uma serializador que serializa dados formato binrio JSON com o esquema dado. Cada valor um List <Map <String, ?>> onde as chaves "id" e "nome" e os valores so um ID inteiro de 32 bits e um nome de cadeia. -> <value-serializer> <type> json </ type> <schema-info> [{"id": "int32", "nome": "string"}] </ esquema info-> </ Value serializador-> <-! Uma serializador que serializa objetos protocolo tampo de determinada classe. -> <value-serializer> <type> protobuff </ type> <schema-info> java = com.something.YourProtoBuffClassName </ esquema info-> </ Value serializador-> <-! Uma serializador que serializa objetos poupana geradas atravs de um dos seguintes protocolos - 'binrio', 'json' ou 'simples-json'. Suporte atual para clientes Java apenas. -> <value-serializer> thrift <type> tipo </> <schema-info> java = com.something.YourThriftClassName, protocol = binrio </ esquema info-> </ Value serializador-> <-! Serializao Avro - ou 'avro-generic', 'avro especfica' ou 'avro-reflexivo' -> <value-serializer> <type> avro-generic </ type> <schema-info> {"nome": "tipo", "tipo": "enum", "smbolos": ["foo", "bar"]} </ esquema info-> </ Value serializador->

reteno dias (opcional) - Este parmetro opcional permite que voc defina uma propriedade de reteno para seus dados. Em seguida, todos os dias, em um momento especificado nos servidores, um trabalho programado

ser executado para apagar todos os dados que tm timestamp> reteno dias. Isso til para manter seus dados aparadas. reteno-scan-acelerador taxa (opcional) - Se reteno dias especificado esta a taxa em que ns vamos examinar as tuplas para excluir dados.

Se voc pretende usar a zona de roteamento de estratgia, precisamos estender a definio loja de dizer como para replicar zonas wrt. Aqui est um exemplo de uma definio loja com enabled 'zona de roteamento ". <stores> <store> <name> teste </ nome> ... <routing-strategy> zona de roteamento </ rota estratgia> <- Este nmero deve ser total do indivduo zona de replicao do fator -> <replication-factor> 2 </ replicao fator-> <zone-replication-factor> <replication-factor zone-id="0"> 1 </ replicao fator-> <replication-factor zone-id="1"> 1 </ replicao fator-> </ Zona-replicao fator-> <zone-count-reads> 0 </ zona-count-l> <zone-count-writes> 0 </ zona-count-escreve> <hinted-handoff-strategy> proximidade handoff </ insinuou-handoff estratgia> ... </ Loja> </ Lojas> A mudana importante aqui a introduo de zona de replicao fator que deve conter um fator de replicao que voc quer em cada zona. Outros parmetros:

zona de contagem * - O nmero de zonas que deseja bloquear para durante l / escreve, antes de retornar a solicitao. O nmero 0 significa que vamos bloquear pelo menos por um pedido do local,nica zona. O nmero 1 significa que vamos bloquear pelo menos por um pedido de uma outra zona. sugeriu-handoff estratgia (opcional) - Outro mecanismo de consistncia que ns adicionamos recentemente sugerido handoff . Podemos ativar esse recurso em uma base por loja. Este parmetro define a estratgia que usaria para decidir qual vivemos ns a escrever a nossa "dica" para. As vrias opes so qualquer handoff- , entrega consistente e proximidade handoff- .

Por n de configurao

Ns armazenamos por n de configurao baseada no arquivo server.properties. A maioria das propriedades tm padres sensatos (espero). O arquivo nua mnimo deve ter a seguinte propriedade. # A identificao da * este n de cluster * particular (diferente para cada n no cluster) node.id = 0 Aqui est uma lista de todas as opes de configurao suportadas: nome omisso descrio O identificador seqencial exclusivo para este servidor no cluster (comea com 0) O diretrio base para Voldemort. Tambm pode ser especificado atravs do VOLDEMORT_HOME varivel de ambiente ou atravs de uma opo de linha de comando. O diretrio onde os dados so armazenados voldemort O diretrio onde voldemort configurao armazenada

node.id

nenhum

voldemort.home

nenhum

data.directory

$ {Voldemort.home} / dados $ {} Voldemort.home / config BDB lojas configurao

metadata.directory

enable.bdb.engine

verdadeiro

Se o motor BDB ser ativado? O cache BDB que partilhada por todas as tabelas BDB. Maior melhor. Deve ser imediatamente transaes escrito para o disco? Quando a transao foi escrito para o disco devemos forar o disco para limpar o cache do sistema operacional. Esta

bdb.cache.size

200MB

bdb.write.transactions

falso

bdb.flush.transactions

falso

 uma operao relativamente cara. bdb.data.directory O diretrio onde o meio $ {Data.directory} / bdb ambiente est localizado BDB 1GB O tamanho de um arquivo de registro individual O tamanho fanout para a btree. Maior fanout mais effienciently suporta 'btrees' maiores. Quantas vezes (em bytes) devemos posto o log de transaes? Checkpoints fazer inicializao e desligamento mais rpido. Quantas vezes em ms devemos posto o log de transaes Use um ambiente de BDB para cada loja Nmero de tpicos mais limpas BDB

bdb.max.logfile.size

bdb.btree.fanout

512

bdb.checkpoint.interval.bytes 20 * 1024 * 1024

bdb.checkpoint.interval.ms

30000

bdb.one.env.per.store bdb.cleaner.threads

falso 1

MySQL armazena configurao Devemos ativado o mecanismo de armazenamento mysql? Se o fizer, ir criar um conjunto de ligao que ir ser utilizado para a instncia mysql O nome de usurio para usurio mysql A senha para o usurio mysql localhost 3306 O anfitrio da instncia mysql A porta da instncia mysql

enable.mysql.engine

falso

mysql.user mysql.password mysql.host mysql.port

raiz

mysql.database

voldemort

O nome do banco de dados mysql

Somente leitura configurao lojas enable.readonly.engine falso Devemos permitir que o motor de armazenamento readonly? O nmero de cpias de segurana dos dados para manter em torno de reverso. Nome da classe de estratgia de pesquisa a ser usado ao mesmo tempo encontrar a chave.Apoiamos BinarySearchStrategy e InterpolationSearchStrateg y O diretrio para armazenar arquivos de dados somente leitura. Milissegundo esperamos antes de apagar dados antigos. til para diminuir IO durante swap.

readonly.backups

readonly.search.strategy

BinarySearchStrategy

readonly.data.directory

$ {Data.directory} / somente leitura

readonly.delete.backup.ms

Configurao de armazenamento de Slop Queremos iniciar um mecanismo de armazenamento de gua suja + ter o trabalho habilitado? O mecanismo de armazenamento que devemos usar para armazenar mensagens misdelivered que precisam ser redirecionado? Ativar o trabalho empurrador slop que

slop.enable

verdadeiro

slop.store.engine

bdb

slop.pusher.enable

verdadeiro

empurra cada 'slop.frequency.ms' ms (Pr-requisito slop.enable = true) slop.read.byte.per.sec slop.write.byte.per.sec 10 * 1000 * 1000 10 * 1000 * 1000 Slop max ler rendimento Slop mximo escrever rendimento

pusher.type

Tipo de trabalho a ser StreamingSlopPusherJo usado para empurrar os b slops 5 * 60 * 1000 Reequilbrio configurao Freqncia em que vamos tentar empurrar os slops

slop.frequency.ms

enable.rebalancing

verdadeiro

Permitir reequilibrar servio? Nmero de tentativas do rebalancer lado do servidor faz para buscar dados Vez que damos para o lado do servidor reequilbrio para concluir a cpia de dados Lojas para reequilbrio em paralelo Devemos executar o nosso otimizao reequilbrio para no partio lojas conscientes?

max.rebalancing.attempts

rebalancing.timeout.seconds

10 * 24 * 60 * 60

max.parallel.stores.rebalancin 3 g

rebalancing.optimization

verdadeiro

Configurao de reteno retention.cleanup.first.start.ho 0 ur Hora em que deseja iniciar o trabalho de limpeza primeira reteno Execute o trabalho de reteno de limpar cada n horas

retention.cleanup.period.hours 24 Configurao fofocas

enable.gossip gossip.interval.ms

falso 30 * 1000 Servio de administrao

Ativar fofoca para sincronizar o estado Ativar gossup cada ms n

admin.enable

verdadeiro

Habilitar o servio de administrao? O nmero mximo de linhas utilizadas por servios de administrao. Usado por BIO (ou seja, se enable.nio.connector = false)

admin.max.threads

20

admin.core.threads

O nmero de segmentos para manter viva pelo servio de administrao, max (1, $ mesmo quando {admin.max.threads} / 2) ocioso. Usado por BIO (ou seja, se enable.nio.connector = false) Nmero de threads seletor para operaes de administrao. Usado por NIO (ou seja, se enable.nio.connector = true)

nio.admin.connector.selectors

max (8, nmero de processadores)

Ncleo Voldemort configurao do servidor enable.nio.connector falso Ativar NIO no lado do servidor Nmero de threads seletor para operaes normais. Usado por NIO (ou seja, se enable.nio.connector = true) O nmero mximo de threads o servidor pode usar (Usado por HTTP e

nio.connector.selectors

max (8, nmero de processadores)

max.threads

100

BIO - enable.nio.connector = false - nico servio) O nmero de segmentos para manter viva mesmo max (1, $ {max.threads} quando ocioso (Usado por / 2) HTTP e BIO enable.nio.connector = false - nico servio) O SO_TIMEOUT soquete. Essencialmente a quantidade de tempo de bloquear em uma operao de rede de baixo nvel antes de lanar um erro. A quantidade total de tempo para esperar por respostas adequadas de todos os ns antes de lanar um erro. Max transferncia de leitura permitida quando os fluxos de dados de servios de Admin Max rendimento gravao permitida quando os fluxos de dados de servios de Admin Ativar o servidor de dados HTTP? Ativar o servidor de dados tomada? Permitir o monitoramento JMX? Registrar cada operao em todas as lojas. Acompanhar as estatsticas de carga nas lojas.

core.threads

socket.timeout.ms

4000

routing.timeout.ms

5000

stream.read.byte.per.sec

10 * 1000 * 1000

stream.write.byte.per.sec

10 * 1000 * 1000

http.enable socket.enable jmx.enable enable.verbose.logging

verdadeiro verdadeiro verdadeiro verdadeiro

enable.stat.tracking

verdadeiro

scheduler.threads

Nmero de tpicos para usar para trabalhos programados

BDB Gesto
O armazenamento de chaves de valor subjacente tambm importante para a configurao e gesto da operao. Se BDB usado, ento toda a configurao feita atravs do arquivo server.properties. Se o MySQL usado ento administrao mysql habitual deve ser feito. A Oracle tem um writeup que d uma boa viso da parte operacional da BDB.

Configurao do cliente
As definies acima foram todos para o servidor. importante configurar correctamente o cliente tambm.Segue uma lista de opes de configurao para os clientes: nome max_connections 50 omisso descrio O nmero mximo permitido de ligao para cada n voldemort O nmero mximo de segmentos de clientes (usada pelo pool de thread do cliente) O nmero mximo de operaes de ns na fila antes de aes do cliente ser bloqueado (usada pelo pool de thread do cliente) A quantidade de tempo para manter um segmento de cliente inativo vivo (usada pelo pool de thread do cliente) Definir o tempo mximo permitido para bloquear

max_threads

max_queued_requests

50

thread_idle_ms

100000

connection_timeout_ms

500

 espera de uma ligao gratuita Mxima quantidade de tempo que o socket ir bloquear a espera por atividade de rede Definir o tempo limite para todas as operaes de bloqueio para completar em todos os ns. O nmero de operaes de bloqueio pode ser configurado usando o preferido as leituras e preferenciais escreve-configurao para a loja. Nmero de seletores utilizado para pedidos de multiplexao em nosso cliente NIO Defina o tamanho do buffer de socket (em bytes) de usar tanto para tomada de l e escreve soquete Permitir o monitoramento JMX Use a loja novo oleoduto encaminhado para o lado cliente de roteamento Nmero de vezes que vai tentar se conectar a url do bootstrap Separados por vrgula lista de URLs para usar servidores como de bootstrap

socket_timeout_ms

5000

routing_timeout_ms

15000

seletores

socket_buffer_size

64 * 1024

enable_jmx

verdadeiro

enable_pipeline_routed_store

verdadeiro

max_bootstrap_retries

bootstrap_urls

Parmetro obrigatrio

serializer_factory_class

Fbrica serializador com Personalizado

suporte para avro, pb, java, etc

serializador nome da classe fbrica Zona ID onde o cliente reside.Usado para fazer a deciso mais inteligente de roteamento em caso de "zona de roteamento '

client_zone_id

Detector de falha configs Nome da classe do detector de falha que o cliente ir BannagePeriodFailureD utilizar.Apoiamos failuredetector_implementation etector BannagePeriodFailureD etector e ThresholdFailureDetecto r BannagePeriodFailureD etector: O nmero de milissegundos este n considerado como 'proibido' ThresholdFailureDetecto r: Nmero mnimo de falhas que devem ocorrer antes que o ndice de sucesso verificado contra o limiar ThresholdFailureDetecto r: intervalo de milissegundos para o qual o limite vlido, 'reset' aps esse perodo excedido ThresholdFailureDector: A representao percentual inteiro do limiar que devem ser cumpridos ou excedidos

failuredetector_bannage_period 30000

failuredetector_threshold_count 10 minimum

failuredetector_threshold_interv 10000 al

failuredetector_threshold

80

Algumas sugestes adicionais

JVM Configuraes No LinkedIn mantemos dois conjuntos de clusters, somente leitura e de leitura e escrita. Os cachos de leitura e escrita so clusters usando lojas BDB e tm caractersticas totalmente diferentes daquelas JVM usando somente leitura lojas. Aqui o que usamos no LinkedIn para nossas leitura-gravao lojas: # Min, max, tamanho total de JVM JVM_SIZE = "-server-Xms22g Xmx22g" # Novos Tamanhos Gerao JVM_SIZE_NEW = "-XX: NewSize = 2048m-XX: MaxNewSize = 2048m" # Tipo de coletor de lixo para usar JVM_GC_TYPE = "-XX: + UseConcMarkSweepGC-XX: + UseParNewGC" # Ajustando opes para o coletor de lixo acima JVM_GC_OPTS = "-XX: CMSInitiatingOccupancyFraction = 70-XX: SurvivorRatio = 2" # JVM atividade GC configuraes de log JVM_GC_LOG = "-XX: + PrintTenuringDistribution-XX: + PrintGCDetails-XX: + PrintGCDateStamps-Xloggc: $ LOG_DIR / gc.log" Esta a configurao em uma caixa de RAM 32GB com um tamanho de cache BDB de 10GB e 3 tpicos mais limpas. H duas coisas importantes aqui: (1) cache BDB deve caber na pilha ou ento ele no vai funcionar (obviamente), (2) voc deve usar a marca concorrente e varredura gc ou ento o GC pausas da coleta de tais monte um grande causar perodos sem resposta (isso no acontece no primeiro ou, se arrasta para cima e depois, eventualmente, entra em uma espiral de morte gc pausa). Para os clusters de somente leitura que usamos as mesmas configuraes de JVM GC, exceto o tamanho da pilha definido para um valor menor. # Min, max, tamanho total de JVM JVM_SIZE = "-server-Xms4096m-Xmx4096m" Isso feito porque, no caso de somente leitura lojas contamos com o cache da pgina OS e realmente no queremos que a nossa pilha da JVM para ocupar espao.

Publicar / Assinar API

Sistemas de armazenamento tornaram-se muito mais especializado nos ltimos anos com cada sistema de fornecimento de conhecimentos em determinadas reas-Hadoop e armazns de dados proprietrios fornecer capacidades de processamento em lote, os

ndices de pesquisa fornecem suporte para consultas complexas texto classificados, e uma variedade de bancos de dados distribudos surgiram. Voldemort um sistema de valoreschave especializada, mas os mesmos dados armazenados no Voldemort pode precisar de ser indexados por pesquisa, agitaram mais em Hadoop, ou processados por outro sistema. Cada um desses sistemas tem a possibilidade de subscrever as mudanas que acontecem em Voldemort e obter um fluxo de tais mudanas que eles podem processar em sua prpria maneira especializada. Na verdade ns at mesmo Voldemort poderia subscrever um ao outro como um mecanismo rpido catch-up para a recuperao de falhas. Amaznia tem implementado essa funcionalidade como uma "rvore Merkle" estrutura de dados em seu sistema que permite que ns Dynamo de comparar os seus contedos de forma rpida e pegar at diferenas que eles perderam, mas isso no a nica abordagem. Poderia ser um simples ndice secundrio que implementa um contador especfico do n lgico que rastreia nmero de modificao para cada chave. A API que seria fornecido seria algo como getAllChangesSince (ChangeNumber int), e esta api daria a ltima alterao para cada chave.

Interface operacional
Um dos problemas principais para um sistema prtico distribudo saber o estado do sistema. Voldemort tem um rudimentar GUI que fornece informaes bsicas. Este projeto seria fazer uma primeira taxa de gesto de GUI e funcionalidades de controle correspondente a ser capaz de conhecer o desempenho ea disponibilidade de cada n do sistema, bem como realizar operaes mais intensas como iniciar / parar os ns, a restaurao de replicao, o reequilbrio, etc .

Scala Voldemort Shell

Voldemort vem com um shell de texto muito simples. A melhor maneira de construir uma coisa integrar completamente uma lngua com um intrprete e fornecer um conjunto de comandos administrativos pr-definidos como funes no shell. Scala tem uma sintaxe flexvel e integra-se facilmente com o Java de modo que seria uma boa escolha para tal uma casca.

Suporte para LevelDB mecanismo de armazenamento

Desde Voldemort suporta um interface do mecanismo de armazenamento conectvel, ns definitivamente queremos tentar outras solues. Por exemplo, temos um Krati mecanismo de armazenamento baseado em contrib. Outro mecanismo de armazenamento que pegar um impulso do Google LevelDB . A primeira fase deste projeto exigiria a construo de JNA / JNI ligaes para o mecanismo de armazenamento seguido pela integrao com Voldemort.

DESCANSAR baseado API

Alm dos j existentes Ruby / Python clientes com um RESTO baseada API iria aumentar a adoo entre a comunidade web. Um bom v1 poderia derivar idias existentes bem sabe sistemas como Riak

Memcache suporte ao protocolo

Um projeto fcil seria a de fornecer a mesma API como Memcache.

Pedido de ajuda Duplex

O trabalho preliminar foi feito para apoiar os nossos pedidos de impresso duplex soquete. Isso seria minimizar o impacto da latncia de rede em centros de dados. Alguns pensamentos iniciais podem ser encontrados aqui

Apoio Maven
Queremos adicionar a capacidade de empurrar frascos em um repositrio Maven central.

Melhor sistema de configurao

Os XML arquivos podem ficar realmente fora de controle, uma vez que aumenta o tamanho de cluster. Migrando do XML para YAML iria aliviar este problema um pouco. No longo prazo, gostaramos de chegar a um melhor sistema de configurao (Explore Zookeeper?)