Escolar Documentos
Profissional Documentos
Cultura Documentos
SQL e NoSQL
Escalabilidade em Data Stores
060316042 050316021
Contedo
1. 2. 2.1 2.2 2.2.1 2.2.2 2.2.3 2.3 3. Introduo ..................................................................................................................... 2 Diferentes Tipos de Base de Dados ............................................................................... 2 Bases de Dados SQL e NoSQL .................................................................................... 2 Teorema de CAP ........................................................................................................ 3 Consistncia........................................................................................................... 3 Disponibilidade ...................................................................................................... 4 Tolerncia a Falhas ................................................................................................ 4 Terminologia ............................................................................................................. 4 Categorias das Data Stores............................................................................................ 5 3.1 Key-Value Stores ........................................................................................................... 5 3.1.1 Projecto Voldemort ...................................................................................................... 5 3.1.2 Memcached, Membrain e Membase ........................................................................... 6 3.1.3 Yahoo Sherpa ............................................................................................................... 6 3.2 Document Store ............................................................................................................ 6 3.2.1 SimpleDB ...................................................................................................................... 7 3.2.2 MongoDB...................................................................................................................... 7 3.3 Extensible Data Records ............................................................................................... 8 3.3.1 HBase............................................................................................................................ 9 3.3.2 Cassandra ..................................................................................................................... 9 3.4 Sistemas Relacionais Escalveis .................................................................................. 10 3.4.1 MySQL Cluster ............................................................................................................ 10 3.4.2 ScaleBase .................................................................................................................... 10 4. 4.1 4.2 4.3 5. 6. Anlise dos Sistemas ................................................................................................... 11 Comparao entre Sistemas.................................................................................... 11 SQL vs. NoSQL Conflito de Opinies ..................................................................... 12 Benchmaking ........................................................................................................... 12 Concluso .................................................................................................................... 15 Bibliografia .................................................................................................................. 17
Page 1
1. Introduo
Com advento da Web 2.0 surgiram aplicaes que necessitam de sistemas que consigam lidar com milhares de utilizadores e escalar milhes de updates e leituras a base de dados. Este volume de operaes contrasta com o design das bases de dados e data warehouses tradicionais. Para responder a esta necessidade necessrio desenvolver novos sistemas e mecanismos que consigam escalar estas aplicaes por diversos servidores. Nos ltimos anos verificou-se o desenvolvimento de novos sistemas, desenhados para proporcionar uma boa escalabilidade horizontal, permitindo operaes de leitura/escrita distribudas pelos diversos servidores. Estes novos sistemas vm contrastar com as bases de dados tradicionais que tm pouca ou nenhuma capacidade para essa escalabilidade horizontal. Nesta monografia apresentamos e comparamos alguns desses novos sistemas de bases de dados distribudas.
Page 2
Figura 1 - Diagrama representativo da interligao das propriedades do Teorema de CAP e as diversas data stores.
2.2.1 Consistncia
a caracterstica que descreve como e se o estado de um sistema fica consistente aps uma operao. Num sistema distribudo de dados significa que uma vez escrito um registo, este fica imediatamente disponvel e pronto para ser utilizado. Uma base de dados distribuda consistncia classificada como fortemente consistente ou como tendo fraca consistncia. Os sistemas com uma forte consistncia, implementam as caractersticas ACID (Atomicidade, Consistncia, Isolamento e Durabilidade), sendo estas implementadas na maior parte das bases de dados relacionais. Na outra extremidade, de fraca consistncia, temos as bases de dados BASE (Basic Availability, Soft-State, Eventual Consistency). A consistncia fraca fornecida de forma de consistncia eventual. Isto significa que a base de dados pode atingir um estado consistente. Nestas incluem-se, normalmente, as bases de dados em que os dados so replicados. Aqui apenas existe a garantia que a verso mais
Page 3
recente de um registo est consistente num n, sendo que as verses mais antigas deste registo podem ainda existir noutros ns, mas eventualmente todos os ns iro ter a ltima verso.
2.2.2 Disponibilidade
Esta caracterstica refere-se concepo e implementao de um sistema de modo a que seja assegurado que este permanece activo durante um determinado perodo de tempo. Ou seja, significa que o sistema tolerante a falhas de software e/ou hardware e que se encontra igualmente disponvel durante a actualizao destes. Disponibilidade no apenas um proteco contra falhas, mas tambm uma forma de obter um balanceamento de carga e operaes concorrentes, nomeadamente para operaes de leitura. Uma das formas mais comuns de fazer a implementao desta caracterstica numa base de dados relacional recorrendo replicao master-master. Desta forma, a falha ou actualizao de um n no implica a indisponibilidade do sistema.
2.3 Terminologia
Antes de descrevermos os diversos sistemas necessrio clarificar alguns termos que sero utilizados neste trabalho (1). Por operaes simples entendemos key lookups, leitura ou escrita de um registo ou de uma pequena quantidade de registos. Tendo em conta o estado actual das aplicaes, onde milhes de utilizadores lem e escrevem informao, a escalabilidade destas pequenas operaes tornou-se muito importante. J foi referido anteriormente o termo escalabilidade horizontal. Este termo refere-se capacidade de distribuir a informao e a carga de processamento das operaes por vrios servidores, sem ser necessrio a partilha de RAM ou disco entre os servidores. Esta escalabilidade difere da escalabilidade vertical onde o disco e memria so partilhados pelos servidores. A terminologia utilizada em NoSQL Data Stores , muitas vezes inconsistente. De forma a existir consistncia, vamos definir alguns termos importantes: Tuplo: uma linha numa tabela relacional com os atributos pr-definidos no esquema da base de dados e cujos valores so escalares. Os valores so referenciados pelo nome do atributo.
Page 4
Document: permite que os valores estejam agrupados em documentos ou listas e os nomes dos atributos so automaticamente definidos a cada execuo. A grande diferena em relao aos tuplos que aqui os atributos no esto esquematizados. Extensible Record: um hbrido entre um tuplo e um document. Aqui a famlia de atributos est pr-definida na base de dados, mas novos atributos podem ser adicionados Objecto: similar ao conceito de objecto em linguagens de programao, mas no tem mtodos procedimentais. Os valores que este toma ou so referncias ou objectos agrupados.
Page 5
informao, o resto das operaes so transparentes. Os ns podem ser adicionados ou removidos que o sistema adapta-se automaticamente. Voldemort detecta automaticamente falhas nos ns e capaz de as recuperar. Este sistema permite guardar a informao na RAM mas permite, da mesma forma, armazen-la num sistema de armazenamento, suportando Berkeley BD e Random Access File.
Page 6
3.2.1 SimpleDB
Este sistema propriedade da Amazon (5). Tal como o nome sugere um sistema simples: SimpleDB tem as operaes Select, Delete, GetAttributes e PutAttributes. Por ser to simples no permite documentos agrupados. Este sistema suporta consistncia eventual, mas no consistncia transaccional. Suporta tambm replicao assncrona. Tal como as Document Stores, o SimpleDB suporta mais do que um grupo por base de dados. Os documents so postos em domnios que suportam indexao mltipla. Os domnios e a sua meta-informao podem ser enumerados. A operao de Select feita num domnio, onde so especificados um conjunto de restries. So da forma de:
select <atributes> from <domain> where <list of attribute value constraints>
Os diferentes domnios so armazenados em diferentes ns da Amazon. Os ndices num domnio so automaticamente actualizados quando os atributos de um document so modificados. Este sistema no particiona automaticamente os dados pelos servidores. Pode-se conseguir alguma escalabilidade horizontal lendo qualquer uma das rplicas, isto se a verso mais actual no for importante. A escrita no escalvel porque as actualizaes tm de ser de forma assncrona. Se um cliente quiser melhor escalonamento tem de ser ele a implement-lo.
3.2.2 MongoDB
O MongoDB (6) um sistema open source e GPL que proporciona ndices em collections, lockless e fornece um mecanismo de query aos documentos. Este sistema possui algumas caractersticas interessantes: Suporta sharding automtico, distribuindo os documentos pelos servidores; A replicao na maior parte dos casos utilizada em casos de failover; No fornece consistncia global mas tem consistncia local, mantendo actualizada a cpia original do documento; Suporta queries dinmicas, com uso automtico de ndices, como as bases de dados relacionais; As operaes sobre os documentos so atmicas.
As operaes sobre os campos fornecidas so: O comando update ampliado, facilitando mudanas atmicas a valores individuais. Por exemplo, $inc incrementa um valor, $push adiciona um elemento a um array, etc. Os updates so feitos localmente para evitar overhead no servidor. A conveno update if current apenas permite alterar um campo se o valor corresponder a um valor prvio;
Page 7
A operao findAndModify faz um update atmico e retorna automaticamente o documento actualizado. Esta operao muito til quando lidamos com estruturas de dados que requerem atomicidade;
O MongoDB guarda a informao num formato binrio, semelhante ao JSON, denominado de BSON. Este formato suporta os tipos booleanos, integer, float, date, string e binrio. Este sistema suporta ainda GridFS fundamental para dados binrios de grande dimenso, como imagens ou vdeos. Como so armazenados em pedaos, ao serem transmitidos para o cliente h eficincia na entrega. Este sistema suporta ainda replicao master-slave, com recuperao automtica de failovers. Esta recuperao feita ao nvel dos shards. As collections so automaticamente partilhadas por uma shard-key definida pelo utilizador. A replicao assncrona para que a performance do sistema seja elevada o que faz com que alguns updates sejam perdidos em caso de crash do sistema.
Os grupos de colunas so pr-definidas com extensible record stores. As linhas so anlogas a documents, tendo um nmero varivel de atributos, com nomes distintos, e esto agrupadas em collections.
Page 8
Figura 3 - Esquema do caminho de leitura e escrita em bases de dados baseadas na Big Table.
3.3.1 HBase
O HBase (8) um projecto da fundao Apache, derivando da BigTable da Google: Usa Hadoop como sistema de ficheiros distribudo. Os updates so guardados em memria e periodicamente so escritos em disco; Os updates vo para o fim do ficheiro de dados, para evitar procuras desnecessrias. Para uma recuperao mais eficiente, em caso de crash do servidor, os updates vo para o fim do log. As operaes sobre as linhas so atmicas, com um locking das transaces de baixo nvel. Usa controlo de concorrncia optimista, abortando se existir conflitos entre updates. O particionamento e distribuio so transparentes. Existe mltiplo suporte para masters, para evitar um ponto singular de falhas. A utilizao do MapReduce permite que as operaes sejam distribudas de forma eficiente.
3.3.2 Cassandra
O Cassandra (9) similar aos outros sistemas Extensible Record Stores. Tem grupos de colunas, as actualizaes so guardadas na cache da memria e periodicamente escritas em disco. Faz particionamento e replicao. Tem mecanismos de deteco de falhas assim como recuperao automtica. Contudo, o Cassandra tem um modelo de concorrncia fraco, no apresentando mecanismos de locking e tendo as actualizaes das rplicas assincronamente. Este sistema confere automaticamente nova disponibilidade aos ns de um cluster. Usando o algoritmo Phi Accrual consegue detectar a falha de um n. tambm capaz de determinar se um n pertence a um cluster utilizando um algoritmo gossip-style. Cassandra cria o conceito de super-coluna, proporcionando um novo nvel de agrupamento com os grupos de colunas originais. Este sistema usa ainda uma hash de ndices ordenados, dando as potencialidades quer de uma hash quer de uma rvore-B no nvel dos
Page 9
ndices. Desta forma, possvel saber que ns podem ter aquele conjunto particular de valores no havendo necessidade de procurar em todos os ns.
O NoSQL contorna estes dois problemas impossibilitando, ou tornando difcil, fazer operaes e transaces deste calibre. No caso das SGBDR, estas apenas penalizam o utilizador se as realizar. Uma vantagem dos SGBDR escalveis a linguagem de alto nvel que possui e as propriedades ACID.
3.4.2 ScaleBase
Esta uma nova abordagem, procurando obter escalabilidade horizontal com uma camada nova sobre o MySQL em vez de alterar o prprio MySQL. Este sistema possui um parser parcial de SQL e um optimizador que particiona as tabelas por mltiplos ns nicos de bases de dados MySQL (10). Implementar sharding em cima de MySQL introduz um novo problema se as transaces no forem abrangidas pelo MySQL.
Page 10
Sistema Key-Value Data Store Document Data Store Extensible Records Data Store Sistemas Relacionais Escalveis Voldemort Membrain Membase SimpleDB MongoDB HBase Cassandra MySQL Cluster ScaleBase
Controlo de Concorrncia MVCC Locks Locks Nenhum Locks Locks MVCC ACID ACID
Armazenamento RAM ou DBD Flash + Disco Disco S3 Disco Hadoop Disco Disco Disco
Replicao Assncrona Sncrona Sncrona Assncrona Assncrona Assncrona Assncrona Sncrona Assncrona
A comparao dos diversos data stores apresentados pode resumir-se, a nvel de mecanismos Tabela 1. Mecanismos de Controlo de Concorrncia Locks: permitem que apenas um utilizador leia ou modifique uma entidade (objecto, document, linha ou campo); MVCC: fornecem um mecanismo de multi-verses, permitindo que exista uma consistncia na leitura das base de dados mas que tm como desvantagem um conflito de verses caso existam modificaes simultaneamente; ACID: j bem conhecido dos sistemas relacionais. A estes, de forma a evitar conflitos, acrescentou-se uma pr-anlise de transaces; Nenhum: existem data stores que no implementam qualquer mecanismo de controlo de concorrncia, permitindo que diferentes utilizadores alterem diferentes partes de um objecto em paralelo e no fornecendo qualquer garantia de que verso o utilizador vai obter quando ler a base de dados. Sistemas de Armazenamento Alguns sistemas esto desenhados para armazenar a informao na RAM, podendo ou no armazenar replicas ou snapshots em disco. Outros sistemas, esto desenhados para armazenar a informao no disco e conter alguma informao na RAM. Mecanismos de Replicao Este mecanismo garante que as cpias que existem esto sempre sincronizadas. Isso conseguindo fazendo um lock base de dados sempre que existe um update a ser feito que apenas termina quando as rplicas tambm so actualizadas. Uma alternativa utilizada a actualizao assncrona que feita em background permitindo que a base de dados continue operacional enquanto essas actualizaes so feitas.
Page 11
Este tpico um assunto bastante controverso (1). Os argumentos a favor do SQL so: Existem novos sistemas SQL que conseguem fazer aquilo a que o NoSQL se prope, com performance e escalabilidade similar, mas com a vantagem de ser SQL e ACID. SGBDR tm uma grande quota do mercado. J foram construdos muitos SGBDR para responder s necessidades dos clientes no passado. Os produtos SQL tm uma interface comum, transaces e esquemas relacionais que facilitam a aprendizagem e a troca de informao.
Por outro lado, os argumentos a favor do NoSQL so: No existem bons e independentes benchmarkings que mostrem que um SGBDR consegue a escalabilidade comparvel com sistemas NoSQL, como por exemplo a BigTable do Google. A ideologia key-value mais simples de entender do que o esquema relacional tradicional. Assim como o armazenamento de documentos. A curva de aprendizagem depende da complexidade do que se quer aprender. Algumas aplicaes necessitam de um esquema flexvel, permitindo que cada collection tenha atributos diferentes. Atribuir novos atributos, em execuo, incomum nos SGBDR. Os SGBDR permitem facilmente operaes em multi-tabelas em multi-ns. No NoSQL essas operaes so impossveis ou demasiado custosas de implementar (logo mal existem). Enquanto que os SGBDR tm uma grande quota de mercado, os sistemas NoSQL tm um mercado mais restrito onde existe realmente necessidade de implementar estas capacidades em particular.
4.3 Benchmaking
Os testes e resultados que sero aqui apresentados foram efectuados pela equipa de investigao da Yahoo! e esto disponveis online para consulta (11) (4). Configuraes
Page 12
Seis servidores: o 8 cores (2x quadcore) 2.5 GHz CPUs, 8 GB RAM, 6 x 146GB 15K RPM SAS drives in RAID 1+0, Gigabit ethernet, RHEL 4 Mquinas extra para simular clientes, routers, controlo, etc. Cassandra 0.5.0 HBase 0.20.3 MySQL 5.1.32 organizado numa configurao com sharding Sherpa 1.8 com MySQL 5.1.24 Sem replicao Updates forados para o disco (excepto no HBase que os updates vo primeiro para a memria) Workloads
120 milhes de registos de 1KB = 20GB por servidor Reads: retornam um registo inteiro Updates: escrevem num nico campo 100 ou mais threads dos clientes
Teste 1 Escalabilidade Neste teste o hardware aumenta-se o harware proporcionalmente com o volume de informao e o workload. Mede-se a latncia. Idealmente a latncia deve ser constante.
Como podemos ver no grfico, Sherpa e Cassandra tm um bom escalonamento, mantendo a linha da latncia quase sem variaes medida que o sistema aumenta. Por outro
Page 13
lado, o HBase muito instvel, tendo uma performance medocre com trs ou menos servidores.
TESTE 2 Elasticidade Neste testes o workload executado em N servidores. Gradualmente o nmero de servidores aumenta. medida a latncia das leituras base de dados. Idealmente, a latncia deve diminuir medida que so adicionados novos ns.
Figura 5 - Read heavy workload utilizando o Sherpa. Inicialmente em 2 servidores. Depois foram adicionados um 4, um 5 e um 6.
Esta data store mostra alguma variao de performance quando os tablets (shards) migram. Mas depois desse processo, a performance estabiliza e torna-se mais rpido com o 6 servidor adicionado.
Figura 6 Read heavy workload utilizando Cassandra. Inicialmente em 2 servidores. Depois foram adicionados um 4, um 5 e um 6.
Page 14
A data store Cassandra apresenta bastantes variaes de latncia sempre que h necessidade de migrar dados para os novos servidores, demorando algumas horas a estabilizar.
Figura 7 - Read heavy workload utilizando HBase. Inicialmente em 2 servidores. Depois foram adicionados um 4, um 5 e um 6
Esta data store apresenta valores de latncia muito baixos comparativamente s duas data stores anteriormente apresentadas. O pico que podemos ver no grfico deve reconfigurao do cluster. Contudo, estes valores so ilusrios. A informao s vai migrar para os novos servidores quando for compactada, sendo essa operao uma actividade peridica. Esses valores no esto presentes no grfico no sendo ento possvel fazer uma verdadeira comparao com os sistemas anteriores.
5. Concluso
Neste trabalho descrevemos brevemente o constrangimento relacionado com a escalabilidade de bases de dados relacionais e apresentamos algumas alternativas NoSQL para resolver esse mesmo problema. Das diversas alternativas apresentadas, fizemos um sumrio das caractersticas das diferentes data stores que apresentamos na Tabela 1. Dos dados analisados podemos concluir que os sistemas que so RAM-based permitem a utilizao da memria virtual do sistema operativo. Contudo, a performance decresce significativamente quando existe um overflow da memria fsica da mquina. Da anlise dos dados disponveis verificou-se tambm que a replicao assncrona permite operaes mais rpidas, nomeadamente para rplicas remotas. Por outro lado, alguns updates podem perder-se caso se verifique um crash no sistema. Uma alternativa implementada a replicao sncrona em cpias locais e replicao assncrona para cpias alojadas
Page 15
remotamente. Esta foi a nica soluo prtica que encontramos para actualizaes de informao remota. Na nossa opinio existem vantagens e desvantagens em utilizar NoSQL como soluo para uma base de dados escalvel. As bases de dados NoSQL escalam de forma elstica, expandindo-se de forma transparente pelos ns, tirando partido de novas tecnologias, como a Cloud, uma vez que esto desenhadas para um escalonamento low cost. Outra vantagem do NoSQL a facilidade com que manuseiam grandes quantidades de dados. Apesar dos sistemas relacionais tentarem acompanhar este aumento de dados, tm demasiadas restries o que as torna impeditivas para algumas situaes. Os sistemas NoSQL utilizam sistemas como o Hadoop para lidar com esse volume de dados, solucionando esse problema. Manter um SGBDR de grandes dimenses precisa de administradores especializados, o que envolve mais custos. As bases de dados NoSQL esto desenhadas para necessitar de menos gesto: tm recuperao automtica de falhas, distribuio automtica de informao, e modelos de dados mais simples, na teoria. Na prtica continua a necessitar de gesto humana. Economicamente menos custosa que uma base de dados relacional. Enquanto a base de dados relacional necessita de servidores dedicados a essa funo e servidores para armazenar os dados, uma base de dados no relacional pode utilizar um cluster reduzindo o custo, por gigabyte ou por transaco/segundo. A ausncia de um modelo especfico de dados para utilizar as bases de dados NoSQL igualmente uma vantagem. Enquanto uma base de dados SQL tem um modelo de dados muito especfico e inflexvel, com NoSQL h maior flexibilidade existindo uma soluo vivel para quase todos os tipos de estruturas, como mostramos neste trabalho. As bases de dados NoSQL criaram muitas expectativas e muito entusiasmo na comunidade. Contudo existem ainda alguns desafios nesta rea. Por ser um sistema relativamente recente ainda necessita de maturidade. Os sistemas existentes ainda esto a implementar as suas key features. E comparativamente com os SGBDR que existem h muito tempo, falta-lhes a estabilidade e as funcionalidades que estes possuem. O suporte existente ainda no o suficiente. Por exemplo, se numa empresa o SGBDR falhar existe suporte dos vendedores dos servios. No caso dos sistemas NoSQL, uma vez que na sua maioria so projectos open source, a ajuda advm de uma comunidade e no de uma empresa como a Oracle, Microsoft ou IBM que tm uma credibilidade maior. A administrao de uma base de dados NoSQL exige, na realidade, pessoas com bastantes conhecimentos para instalar, configurar e manter o sistema. As bases de dados NoSQL comeam a vingar no panorama das bases de dados e, quando utilizadas correctamente, oferecem benefcios reais. Contudo, a migrao das grandes bases de dados deve ser feita com muita cautela e com a conscincia das limitaes e constrangimentos que ainda esto associados a estas bases de dados.
Page 16
6. Bibliografia
1. Scalable SQL and NoSQL Data Stores. Cattell, Rick. 4, s.l. : ACM SIGMOD Record, 2010, Vol. 39. 2. Tharakan, Royans K. Brewers CAP Theorem on distributed systems. Scalable web architectures. [Online] 2010. http://www.royans.net/arch/brewers-cap-theorem-ondistributed-systems/. 3. Voldemort, Project. Project Voldemort. Project Voldemort. [Online] http://projectvoldemort.com/. 4. Cooper, Brian F. Yahoo! Cloud Serving Benchmark. 2010. 5. SimpleDB: A Simple Java-Based Multiuser System for Teaching Database Internals . Sciore, Edward. s.l. : SIGCSE, 2007. 6. MongoDB. http://www.mongodb.org/. http://www.mongodb.org/. [Online] http://www.mongodb.org/. 7. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach. Bigtable: A Distributed Storage System for Structured Data. 2006. 8. Foundation, The Apache Software. Apache HBase. Apache HBase. [Online] 9. . Cassandra. Cassandra. [Online] http://cassandra.apache.org/. 10. Ramakrishnan, Raghu. Sherpa: Cloud Computing of the Third Kind. s.l. : Yahoo! Research and Platform Engineering Team, 2008. 11. Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan, Russell Sears. Benchmarking Cloud Serving Systems with YCSB. s.l. : Yahoo! Research, 2010. 12. Inc, Scale Base. Scale Base. Scale Base. [Online] http://www.scalebase.com/. 13. Corporation, Oracle. MySQL Cluster CGE. MySQL. [Online] http://www.mysql.com/products/cluster/.
Page 17