nosql familia de colunas monografia
TRANSCRIPT
Universidade Federal de Pernambuco
Centro de Informática (CIn)
NoSQL Orientado a
Colunas
Augusto Juvenal F. G. Costa ([email protected])
Resumo
A tecnologia NoSQL é pioneira nas companhias que lideram com grande
público na internet (e.g. Google, Facebook Amazon e LinkedIn) para superar as
limitaçõees da base de dados relacionais que possui cerca de 40 anos. NoSQL,
abreviação de “not only SQL”, vem da ideia de que ao produzir uma solução de
software ou produto, deve haver mais do que um mecanismo de armazenamento
que pode ser utilizado em função das necessidades. Hoje em dia, empresas
estão adotando tecnologias NoSQL para um grande número de casos de uso,
os quais são impulsionados por algumas tendências: Big Data, Internet das
Coisas, Computação em Nuvem. NoSQL foi uma hashtag (#nosql) utilizada para
um meetup para discutir estas novas bases de dados. NoSQL não tem uma
definição formal, mas é possível observar pontos em comum, como por exemplo
não utilizar o modelo relacional; ser open-source; funcionar bem em clusters;
construído para as propriedades da web contemporânea.
Sumário
1 - Introdução .............................................................................................................................. 5
2 - O que é NoSQL? .................................................................................................................. 6
3 - Características ...................................................................................................................... 8
3.1 - O Teorema CAP ................................................................................................ 9
3.2 - Modelos NoSQL .............................................................................................. 10
4 - NoSQL Orientado a Colunas ............................................................................................ 12
4.1 – Ferramentas ................................................................................................... 13
4.1.1 – BigTable................................................................................................... 14
4.1.2 – Apache Cassandra .................................................................................. 16
4.1.3 – HBase ...................................................................................................... 18
5 - Referências .......................................................................................................................... 20
Índice de Ilustrações Figura 1 - Complexidade e quantidade durante as eras da web ........................................ 6
Figura 2 - Diagrama CAP .......................................................................................................... 9
Figura 3 - Ferramentas em Diagrama CAP .......................................................................... 10
Figura 4 - exemplo de armazenamento em um SGBD e em um NoSQL de colunas ... 13
Figura 5 - exemplo de armazenamento de NoSQL de colunas com layout de grupos de
localidade ................................................................................................................................... 13
Figura 6 - Arquitetura BigTable .............................................................................................. 14
Figura 7 - Cluster do Cassandra ............................................................................................ 16
Figura 8 - Arquitetura HBase .................................................................................................. 18
5
1 - Introdução
A web 2.0 trouxe um aumento considerável de dados para o mundo digital.
Devido a isto, as bases relacionais tradicionais enfrentam diversos desafios para
lidar com problemas relacionados a demanda (performance, escalabilidade...)
(HECHT; JABLONSKI, 2011). Mas é sabido que sua estrutura torna muito difícil
de escalar e ser ágil o suficiente para suportar aplicações modernas.
Recentemente, um novo tipo de solução de storage, denominado NoSQL,
prometeria ganhos muito significativos em escalabilidade e performance,
custando um pouco da consistência. O poder do NoSQL é útil para armazenar
grande volume de dados e recuperá-los mais rápido do que uma base de dados
relacionais tornando-se útil para aplicações onde o armazenamento é mais
importante do que manter a relação entre os dados.
O Big Data é um termo utilizado para denominar as técnicas de captura,
análise e processamento que estão disponíveis, mas não são acessíveis sem
realização de uma mineração dos dados e nem estão em padrões predefinidos
(KUMAR et al., 2014). Tal modelo de análise é uma tendência que tem muito a
se desenvolver. Este desenvolvimento está integrado com a popularidade dos
sistemas de armazenamento NoSQL e geralmente é o mecanismo mais utilizado
nos ambientes de nuvem. Existem cerca de 150 tipos de bases de dados, dentro
das cinco categorias (valor-chave, documento, coluna, grafos, orientada a
objetos) (NAYAK; PORIYA; POOJARY, 2013). Cada tipo de armazenamento
NoSQL possui suas vantagens e desvantagens, cabendo ao desenvolvedor
escolher a que melhor se adeque às necessidades de sua aplicação. O objetivo
deste trabalho é realizar um apanhado sobre uma das categorias, NoSQL de
colunas. Serão apresentados também exemplos de bases contidas nesta
categoria, assim como conceitos e apresentar duas bases de dados importantes,
Hbase e Cassandra.
6
2 - O que é NoSQL?
O termo NoSQL pode ser confundido com nenhuma tecnologia SQL é
permitida, do inglês “no SQL is allowed in this technology”. Mas na realidade,
NoSQL vem da abreviação “de não apenas SQL” (do inglês “not only SQL”)
(ZVAREVASHE; GOTORA, 2014). Tal termo se refere aos grupos de base de
dados não relacionais que são utilizadas na manipulação de grande volume de
dados. Desde os anos 80 os bancos de dados relacionais (RDBMS) tem sido o
modelo dominante (ferramentas como MySQL, ORACLE, Microsoft SQL Server).
No entanto os RDBMS lidam com uma deficiência em sua escalabilidade e isto
é totalmente relacionado com o crescimento exponencial de informações
geradas por usuários, sistemas, sensores, também causados por grandes
sistemas distribuídos devido aos serviços Amazon e Google dentre outras
empresas de serviços Cloud.
Figura 1 Complexidade e quantidade durante as eras da web
A Figura 1 nos dá uma visualização de quanto os dados disponíveis
cresceram com o tempo além de um crescimento de sua complexidade e
variedade. O desenvolvimento contínuo destas tecnologias levanta algumas
motivações para as bases de dados NoSQL:
7
Alta escalabilidade e disponibilidade:
O aumento do número de requisições paralelas, é preciso um suporte a
fáceis expansões sem interromper o serviço oferecido.
Escrita e Leitura lentas:
Bancos de dados relacionais se tornam propensos a problemas de
concorrência levando a uma lentidão na leitura e escrita de acordo com o
aumento do volume.
Capacidade Limitada:
As bases de dados relacionais não suportam Big Data. Os dados que
interessam para empresas como Facebook, Yahoo e Google, entre outras,
não são possíveis de armazenar em bases de dados relacionais.
Eficiência em armazenamento e acesso a Big Data:
Aplicações que necessitam de armazenamento eficiente (em nível de
Petabytes) e que responda as necessidades de milhões de tráfegos.
Alta concorrência de leitura e escrita:
RDBMS tem baixa concorrência com alta latência, o que é completamente
oposto as expectativas requeridas na atualidade.
8
3 - Características
Dada as motivações anteriormente citadas para uma base de dados capaz
de suprir as necessidades atuais, surgindo assim o paradigma NoSQL com as
seguintes características:
Ausência do esquema (Schema-free)
É justamente essa ausência de esquema que facilita uma alta escalabilidade
e alta disponibilidade, mas em contrapartida não há a garantia de integridade
dos dados, fato este que não ocorre no Modelo Relacional.
Escalabilidade Horizontal e Suporte nativo a replicação
Esta característica é também uma vantagem dos bancos de dados NoSQL.
A ausência de bloqueios permite a escalabilidade horizontal, sem afetá-la
pelo aumento de concorrência. Dentre todas as formas de escalar a
escalabilidade horizontal é a mais viável. Além disto a escalabilidade é
agilizada devido ao suporte nativo de replicações, diminuindo o tempo gasto
para recuperar informações.
Map Reduce
Permite a manipulação de enormes volumes de dados ao longo de nós em
uma rede [23]. Funciona da seguinte forma: na fase map, os problemas são
particionados em pequenos problemas que são distribuídos em outros nós
na rede. Quando chegam à fase reduce, esses pequenos problemas são
resolvidos em cada nó filho e o resultado é passado para o pai, que sendo
ele consequentemente filho, repassaria para o seu, até chegar à raiz do
problema.
MVCC (do inglês Multiversion Concurrency Control)
Oferece suporte a transações paralelas em banco de dados. Por não fazer
uso de locks para controle de concorrência, faz com que transações de
escrita e leitura sejam feitas simultaneamente
9
Vector Clocks
Ordenam eventos que ocorreram em um sistema. Como existe a
possibilidade de várias operações estarem acontecendo simultaneamente, o
uso de um log de operações informando suas datas se faz importante para
informar qual versão de um dado é a mais atual.
Ao se projetar um sistema distribuído, é de extrema importância
compreender o Teorema CAP e não há exceções quando se trata de problemas
que envolvam bases de dados NoSQL.
3.1 - O Teorema CAP
Em 2000, o professor Eric Brewer conjecturou que um sistema distribuído
não pode, simultaneamente, fornecer todos os três das seguintes propriedades
desejáveis:
Consistência (do inglês Consistensy): Uma leitura vê todas as gravações
concluídas anteriormente.
Disponibilidade (do inglês Avaliability): Leitura e escrita sempre bem
sucedidos.
Tolerância de Partição (do inglês Partition Tolerance): Propriedades são
mantidas mesmo quando falhas na rede impedir que algumas máquinas se
comuniquem.
Portanto bancos de dados NoSQL podem ser classificados usando o teorema
de CAP. Os bancos de dados NoSQL seguem as diferentes combinações de a
C, A, P a partir do Teorema CAP. A figura a seguir mostra uma breve descrição
das três combinações CA, CP, AP.
Figura 2 Diagrama CAP
10
3.2 - Modelos NoSQL
A partir do teorema descrito acima, fica a critério e necessidades da
equipe na construção de um produto para a escolha do Sistema de
Gerenciamento de Banco de Dados (SGBD). A Figura 3 mostra os modelos
NoSQL e suas respectivas bases de dados localizada em uma das arestas do
diagrama CAP.
Os Modelos SGBD NoSQL são descritos a seguir:
● Armazenamento Chave-Valor - O sistema armazena dados estruturados
como pares de chaves e valores. É um modelo de estrutura mais simples,
tendo em cada chave um identificador para vários valores, identificados
por índices hash. As consultas e as inserçoes sao feitas sob alto
desempenho, devido a operaçao ser totalmente sobre a chave; já para
consultas ad-hoc e atualizações o desempenho torna-se ruim porque
essas operações não se restringem a operaçoes com a chave.
Exemplos: Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle DB;
Figura 3 - Ferramentas em Diagrama CAP
11
● Orientado a colunas - Armazena os dados em colunas de uma tabela.
As colunas são independentes entre si, isto é, não possuem
relacionamentos entre elas, diferentemente do que ocorre no modelo
relacional. As colunas podem ter chaves como no modelo chave-valor,
porém elas apontam para múltiplas colunas. Foram criados para
processar grande volume de dados e proporcionam pesquisas rápidas e
boa distribuição no armazenamento de dados.
Exemplos: Cassandra, Riak, HBase, BigTable;
● Orientado a documentos - Armazena documentos que são JSON
(Javascript Object Notation) com uma chave associada. Esse modelo
associa uma chave a um documento, permitindo valores aninhados a
cada chave, ou seja, a documentos associados. São tolerantes a dados
incompletos, processa consultas ad-hoc sobre atributos dos documentos
armazenados;
Exemplos: CouchDB, MongoDb.
● Orientados a Grafo - Esse modelo foge totalmente dos conceitos SQL
comumente visto, pois ao invés de utilizar a estrutura de tabelas com
colunas e linhas, utiliza a estrutura de grafo para armazenamento de
informaçoes. Tem aplicabilidade em redes sociais e sistemas de
recomendaçoes. Temos como Exemplos de base de dados: Neo4J,
Infogrid, InfiniteGraph;
12
4 - NoSQL Orientado a Colunas
Na subseção 3.2 foi dada uma definição comumente encontrada para este
modelo, porém, podemos definir NoSQL orientado a colunas em dois tipos de
layouts.
Layout Colunar Armazenamento - serializa tabelas anexando as suas colunas.
Assim, as operações em colunas tornam-se rápidas e baratas, enquanto as
operações de linhas são caros e podem levar a procura de um lote ou de todas
as colunas. Um campo de aplicação típica para este tipo de layout de
armazenamento é analytics onde uma análise eficaz das colunas para fins
estatísticos é importante.
Layout Colunar de armazenamento com Grupos de Localidade - semelhante
ao layout de armazenamento colunar, mas adiciona o recurso de definir os
chamados grupos locais, que são grupos de colunas que deverão ser acessados
em conjunto pelos clientes. As colunas de um tal grupo podem ser armazenadas
em conjunto e fisicamente separada de outras colunas e grupos de colunas. A
ideia de grupos locais foi introduzida nas pesquisas do Bigtable. Ele descreve
em primeiro lugar, o modelo lógico de coluna-famílias para colunas
semanticamente afins ou inter-relacionados e, mais tarde, apresenta a ideia de
grupos locais como um refinamento onde colunas-famílias podem ser agrupadas
ou segregado para o armazenamento físico.
Se comparar com o acesso a dados em um SGBD relacional, pode-se
afirmar que o acesso a uma consulta relacional custará o tempo proporcional a
quantidade de dados a ser analisada. Enquanto o acesso a dados em um banco
de dados orientado a colunas ser resume a um mapeamento por índice
construído por algum indexador atribuído à ferramenta. A Figura 4 e a Figura 5
é possível ter uma ideia de como é armazenado os dados em uma tabela em um
RDBMS e respectivamente os mesmos dados em um sistema NoSQL de
colunas.
13
Figura 4 - exemplo de armazenamento em um SGBD e em um NoSQL de colunas
Figura 5 - exemplo de armazenamento de NoSQL de colunas com layout de grupos de localidade
4.1 – Ferramentas
O modelo baseado em colunas tem como vantagem permitir o divisão de
dados, oferecendo forte consistência, no entanto, a baixa disponibilidade é o seu
ponto fraco. Nas subseções a seguir detalharemos o BigTable, HBase e o
Apache Cassandra.
14
4.1.1 – BigTable
A Google trabalha no BigTable desde 2003 com o intuito de atender suas
demandas dos tempos atuais. É uma ferramenta muito dependente do
MapReduce, esparso, distribuído e possui um mapeamento ordenado e
multidimensional persistente. Organizado nas dimensões linha, coluna e hora
(formam uma célula), onde as linhas ordenadas lexicograficamente são
organizadas em tablets; as colunas são agrupadas em famílias que formam a
unidade de controle e a hora é utilizada para indexação de várias versões de
uma célula.
4.1.1.1 – Arquitetura
Figura 6 - Arquitetura BigTable
Bigtable possui três componentes principais:
Biblioteca Cliente: Cada biblioteca cliente contém um cache com as
informações de localização. E se o cache estiver vazio ou se o cliente detecta
que o cache informação não é correta, o cliente vai subir na hierarquia para
recuperar o local recursivamente. No pior dos casos, uma busca através de uma
15
hierarquia de três níveis pode exigir 6 round trips1 na rede, incluindo uma
pesquisa nos arquivos do Chubby. O Chubby é um serviço de armazenamento
de metadados que contém informações como a localização de um servidor tablet
raiz.
Servidor Master: responsável pela atribuição de tablets ao servidor de tablets,
detectando os adicionais e os expirados a fim de equilibrar a carga dos
servidores tablets. É também responsável pela coleta de lixo, além de
administrar alterações dos esquemas de linhas e colunas.
Tablet Servers: foi criado para gerir o conjunto de tablets, lidando com leitura e
gravação de solicitações para os tablets. Quando um tablet está muito grande,
ele é dividido em tablets menores para processamento futuro. Servidores tablets
podem ser adicionados ou removidos de um cluster Bigtable com base na carga
de trabalho. Este processo é gerenciado pelo servidor Master. Embora haja
apenas um servidor Master existente no aglomerado, uma vez que os clientes
não dependem de servidor principal para a informação de localização tablet, a
carga do servidor principal é muito baixa. O cliente comunica com o servidor de
tablets diretamente para ler ou escrever dados.
4.1.1.2 – Considerações
BigTable se tornou uma ferramenta fundamental em algumas aplicações
do Google como Orkut, Google Maps, Blogger e Google Earth, aonde consegue
atingir escalabilidade e confiabilidade de maneira simples e eficiente utilizando
outras ferramentas como o Google File System, Zippy entre outros. Visando
sempre ocupar o menor espaço possível, mas focando ainda mais no
desempenho, na velocidade das suas aplicações. A BigTable se mostrou uma
ótima ferramenta distribuída que foi construída, e continua em constante
desenvolvimento, com o auxílio de pesquisas já desenvolvidas pela Google.
1 Tempo total para percorrer de um ponto origem ao ponto destino, voltando em seguida ao ponto origem.
16
4.1.2 – Apache Cassandra
O Cassandra é um SGBD baseado na abordagem NoSQL. Existem
alguns tipos diferentes de NoSQL, sendo que o Cassandra é baseado no tipo
chave/valor. Nesse tipo de banco de dados, os dados são identificados através
de uma chave. A principal promessa do Cassandra é de prover um sistema de
armazenamento distribuído, altamente escalável e eventualmente consistente.
Para garantir essas promessas, foram unidas características de dois
sistemas NoSQL, o BigTable do Google e o Dynamo da Amazon. Esse sistema
foi criado no Facebook em 2008, por Avinash Lakshman e Prashant Malik. Foi
bastante usado no próprio Facebook para tornar a busca de mensagens mais
robusta. No final de 2010 seu uso no Facebook foi descontinuado. Hoje em dia
é utilizada uma outra solução NoSQL no lugar do Cassandra.
4.1.2.1 – Arquitetura
A Figura 7 mostra a arquitetura de um cluster do Cassandra, sendo possível
de observar que o Cassandra é um sistema distribuído. É utilizado hashing
Figura 7 - Cluster do Cassandra
17
consistente para calcular o hash de chaves de cada item de dados armazenados,
sendo divididos em intervalos entre os nós no cluster. A arquitetura acima
fornece as seguintes propriedades:
1. O Cassandra distribui dados entre seus nós de forma transparente para o
usuário. Qualquer nó pode aceitar qualquer solicitação (leitura, gravação ou
exclusão) e encaminhá-la ao nó correto, mesmo que os dados não estejam
armazenados nesse nó.
2. Os usuários podem definir quantas réplicas são necessárias, e o Cassandra
cuida da criação e gerenciamento de réplicas de forma transparente.
3. Consistência ajustável: ao armazenar e ler dados, os usuários podem
escolher o nível de consistência esperado em cada operação. Por exemplo,
quando o nível de consistência "quórum" é usado ao gravar ou ler, os dados
são gravados e lidos em mais de metade dos nós no cluster. O suporte a
consistência ajustável permite que os usuários escolham o melhor nível de
consistência para o caso de uso.
4. O Cassandra fornece gravações muito rápidas (até mesmo mais rápidas que
as leituras), transferindo dados até 360 MB/s por nó.
5. O Cassandra mantém a maior parte dos dados na memória do nó
responsável. As atualizações são feitas na memória e gravadas no
armazenamento persistente (sistema de arquivos) de forma lenta. No
entanto, para evitar a perda de dados, ele grava todas as transações em um
log de confirmação no disco. Ao contrário da atualização de itens de dados
no disco, as gravações em logs de confirmação envolvem apenas anexação
e, portanto, evitam o atraso de rotação ao gravar no disco.
6. A menos que a gravação tenha solicitado consistência total, o Cassandra
grava dados em nós suficientes sem resolver inconsistências de dados,
resolvendo-as apenas na primeira leitura. Esse processo é chamado de
"reparo na leitura".
4.1.2.2 – Considerações
Para quem busca mudar de um RDBMS para o Cassandra (assim como
a Netflix, Facebook, Twitter fizeram um dia), alguns cuidados devem ser
tomados. Apesar da semelhança na sintaxe com bancos de dados relacionais
para consultas, inserções, criações de tabelas, a principal diferença entre o
Cassandra e os bancos relacionais é a consistência. A atomicidade também não
18
é suportada no Cassandra, ou seja, qualquer operação que falhe, pode deixar
mudanças (consequentemente inconsistência).
4.1.3 – HBase
HBase é um projeto de código aberto da Apache cujo objetivo é fornecer
Big Table como armazenamento. Originalmente foi criado como um subprojeto
Hadoop para trabalhos com MapReduce, uma das aplicações do Hadoop. Foi
construído para fornecer pedidos com baixa latência e diferentemente da
consistência eventual das bases colunares, é significativamente consistente. Os
dados são logicamente organizados em tabelas, linhas e colunas. As colunas
podem ter várias versões para a mesma chave de linha. O modelo de dados é
semelhante ao do Big Table.
4.1.3.1 – Arquitetura
A Figura 8 exemplifica a arquitetura do HBase, onde três principais
componentes da arquitetura são descritos a seguir:
Figura 8 - Arquitetura HBase
19
1. HBaseMaster: O HBaseMaster é responsável por atribuir regiões a
HRegionServers. A primeira região a ser atribuída é a região root 2que localiza
todas as meta-regiões a serem atribuídas. O HBaseMaster também monitora a
saúde de cada HRegionServer, e se detectar um HRegionServer não é mais
acessível, ele vai dividir log write-ahead do HRegionServer de modo que há
agora um log write-ahead para cada região que o HRegionServer estava
servindo. Depois de ter feito isso, ele vai voltar a atribuir às regiões que estavam
sendo atendidos pela HRegionServer inacessível. Além disso, o HBaseMaster
também é responsável por funções de tabela manipulação administrativas, tais
como on / off de tabelas, alterações para o esquema da tabela (adição e remoção
de famílias de colunas), etc.
2. HRegionServer: O HRegionServer é responsável pelo tratamento do cliente
ler e escrever pedidos. Ele se comunica com o HBaseMaster para obter uma
lista de regiões para servir e para dizer que “está vivo”. Atribuição de regiões e
outras instruções que o ancoram a um HBaseMaster.
3. cliente HBase: O cliente HBase é responsável por encontrar HRegionServers
que estão servindo a gama de interesse específico. Na instanciação, o cliente
HBase comunica-se com o HBaseMaster para encontrar a localização da região
de “root”. Esta é a única comunicação entre o cliente e o mestre.
4.1.3.2 – Considerações
HBase é recentemente novo e em processo de desenvolvimento,
portanto, muito instável, visto que muitos módulos essenciais ainda estão sendo
desenvolvidos.
2 Região de execução de onde parte todas as cargas de endereço, chamada também de admin em alguns sistemas e possui todas as permissões.
20
5 – Conclusão
Os bancos de dados NoSQL, em geral, é uma tecnologia muito recente
se comparado com outros SGBDs que possuem no mínimo duas décadas de
sucesso no mercado. Porém os SGBDs NoSQL estão ganhando espaço no
mercado e empresas que utilizam NoSQL em sua maioria do sistema, Datastax
e Cloudera por exemplo, já surgem no mesmo quadrante de empresas líder de
mercado em 2015, como pode ser visto na Figura 9.
Figura 9 - Quadrante Mágico para o mercado de sistemas de gerenciamento de base de dados
21
6 - Referências
(MONIRUZZAMAN; HOSSAIN, 2013) - MONIRUZZAMAN, A B M; HOSSAIN,
Syed Akhter. NoSQL Database: New Era of Databases for Big data Analytics -
Classification, Characteristics and Comparison. International Journal Of
Database Theory And Application. 2013.
(HECHT; JABLONSKI, 2011) - HECHT, Robin; JABLONSKI, Stefan. NoSQL
Evaluation: A Use Case Oriented Survey. University Of Bayreuth, Germany,
2011.
(NAYAK; PORIYA; POOJARY, 2013) - NAYAK, Ameya; PORIYA, Anil;
POOJARY, Dikshay. Type of NOSQL Databases and its Comparison with
Relational Databases. International Journal Of Applied Information Systems.
New York, p. 16-19. Mar. 2013.
(ZVAREVASHE; GOTORA, 2014) - ZVAREVASHE, Kudakwashe; GOTORA,
Tatenda Trust. A Random Walk through the Dark Side of NoSQL Databases in
Big Data Analytics. International Journal Of Science And Research. Hyderabad,
p. 506-509. jun. 2014.
(DEDE et. al, 2013) - DEDE, Elif et.al. Performance Evaluation of a MongoDB
and Hadoop Platform for Scientific Data Analysis. 2013, Binghamton, 2013.
(KUMAR et al., 2014) - KUMAR, Rakesh et al. Apache Hadoop, NoSQL and
NewSQL Solutions of Big Data. International Journal Of Advance Foundation And
Res Earch In Science & Engineering. Jaipur, p. 28-36. out. 2014.
(SOUZA; SANTOS, 2015) - SOUZA, Vanessa Cristina Oliveira de; SANTOS,
Marcus Vinícius Carli dos. Amadurecimento, Consolidação e Performance de
SGBDs NoSQL: Estudo Comparativo. XI Brazilian Symposium On Information
System. Itajubá, p. 235-242. May 2015.
(HAN et al., 2012) - HAN, Jing et al. Survey on NoSQL Database. Beijing
University Of Posts And Telecommunications, Beijing, 2011.