oriolrius.cat

Des del 2000 compartiendo sobre…

Tag: databases

CouchDB: bases de dades NoSQL

2010/01/14 3 comentaris

Reading time: 4 – 6 minutes

couchdb logo

couchdb logo

Abans de parlar de CouchDB, si no heu sentit a parlar mai de les bases de dades NoSQL, és important que sapigueu que no són bases de dades ralacionals, ni orientades a objectes. Sinó que es basen en un paradigme diferet, són orientades a documents.

Doncs bé, CouchDB és un projecte de la fundació Apache i és OpenSource, és clar. Algunes de les seves característiques són:

  • RESTful API
  • schema-less document store (document=JSON format w/binary support like attachments)
  • multi-version-concurrency-control model
  • user-defined query structured as map/reduce (javascript, python, C, etc)
  • incremental index update mechanism
  • multi-master replication
  • easily distributable
  • update validation
  • programat amb erlang
  • web based basic admin features
  • binding for python, C, .NET, PHP, Ruby, etc.
  • pros: retrieve information, cons: insert data

Actualment estic estudiant si usar aquest producte en un dels projectes que estic treballant. De fet, encara no tinc clar si aplica al 100% a les necessitats que tinc en el projecte però a priori s’ajusta prou bé. Perquè no penseu que això és una raresa que no coneix ningú informar-vos que Ubuntu One usa couchDB com a backend, pels que no conegueu el servei jo el vaig descobrir gràcies a l’article d’Ars Technica: Code tutorial: make your application sync with Ubuntu One.

Inicialment volia fer un manual de les funcions bàsiques de CouchDB però degut al munt de documentació que he trobat he pensat que era una tonteria re-inventar la roda, així doncs a continuació faré una ressenya de les fonts d’informació que he usat per coneixer aquesta base de dades:

  • CouchDB Implementation: descripció molt detallada i no massa extensa de com funciona per dintre aquest sistema de BBDD especialment dedicada al Pau. Destaco aquest paràgraf:

    • CouchDB is a “document-oriented” database where document is a JSON string (with an optional binary attachment). The underlying structure is composed of a “storage” as well as multiple “view indexes”. The “storage” is used to store the documents and the “view indexes” is used for query processing.

  • Serie d’articles del blog RVZ: una pequeña introducción I, II, III y IV.
  • Llibre: CouchDB: The Definitive Guide, consultable online en format HTML.
  • CouchDB.es, sobre CouchDB y NoSQL.

Enllaços orientats a les consultes:

Abans d’acabar comentar que personalmentel que més m’ha costat d’entendre de tot plegat és el tema map/reduce especialment la part de reduce, ja que no acabava de veure al 100% com funcionava i quina finalitat tenia. Potser l’error més gran que he comès és intentar buscar un paral·lelísme directe entre SQL i NoSQL. Sota el meu punt de vista no són tecnologies substitutories, més aviat complementaries ja que cada una s’ajusta a un tipus de solucions diferents. Per tant, abans que res recomano que confronteu la vostre problemàtica amb cada un dels paradigmes: orientat a objectes, bbdd relacionals i orientat a documents.

Tuning d’un servidor MySQL

2009/07/13 7 comentaris

Reading time: 2 – 2 minutes

Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.

Doncs bé, coses que he aprés que potser ús poden anar bé són:

  1. Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
  2. Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
  3. Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
  4. Posar els logs en un disc dedicat, diferent del disc que té les dades.
  5. Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
  6. Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
  7. Montar els directori temporal de MySQL sobre una partició RAM.
  8. Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
  9. Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
  10. Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.