Teoria i pràctica de l'ús de l'HBase

Bona tarda Em dic Danil Lipovoy, el nostre equip de Sbertech va començar a utilitzar HBase com a emmagatzematge de dades operatives. En el curs d'estudiar-lo s'ha acumulat experiència que he volgut sistematitzar i descriure (esperem que sigui útil per a molts). Tots els experiments següents es van realitzar amb les versions HBase 1.2.0-cdh5.14.2 i 2.0.0-cdh6.0.0-beta1.

1. Arquitectura general
2. Escriptura de dades a HBASE
3. Lectura de dades d'HBASE
4. Emmagatzematge en memòria cau de dades
5. Processament de dades per lots MultiGet/MultiPut
6. Estratègia per dividir les taules en regions (divisió)
7. Tolerància a errors, compactació i localitat de dades
8. Configuració i rendiment
9. Proves d'estrès
10. Troballes

1. Arquitectura general

El Mestre de còpia de seguretat escolta el batec del cor de l'actiu al node ZooKeeper i, en cas de desaparició, es fa càrrec de les funcions del mestre.

2. Escriu dades a HBASE

Primer, mirem el cas més senzill: escriure un objecte valor-clau en una taula amb put(rowkey). El client primer ha d'esbrinar on es troba el servidor de regió arrel (RRS), que emmagatzema la taula hbase:meta. Rep aquesta informació de ZooKeeper. Després d'això, accedeix a RRS i llegeix la taula hbase:meta, de la qual extreu informació sobre quin RegionServer (RS) és responsable d'emmagatzemar les dades d'una clau de fila determinada a la taula d'interès. Per a un ús futur, el client emmagatzema la meta taula i, per tant, les trucades posteriors van més ràpid, directament a RS.

A continuació, RS, després d'haver rebut una sol·licitud, en primer lloc l'escriu a WriteAheadLog (WAL), que és necessària per a la recuperació en cas d'accident. A continuació, desa les dades a MemStore. Aquest és un buffer a la memòria que conté un conjunt ordenat de claus per a una regió determinada. Una taula es pot dividir en regions (particions), cadascuna de les quals conté un conjunt disjunt de claus. Això us permet col·locar regions en diferents servidors per aconseguir un major rendiment. Tanmateix, malgrat l'obvietat d'aquesta afirmació, veurem més endavant que això no funciona en tots els casos.

Després de col·locar una entrada al MemStore, es retorna una resposta al client que l'entrada s'ha desat correctament. Tanmateix, en realitat només s'emmagatzema en una memòria intermèdia i només arriba al disc després d'haver passat un període de temps determinat o quan s'omple de dades noves.

Quan es realitza l'operació "Suprimeix", les dades no s'eliminen físicament. Simplement es marquen com a suprimits i la destrucció en si es produeix en el moment de cridar la funció compacta principal, que es descriu amb més detall al paràgraf 7.

Els fitxers en format HFile s'acumulen en HDFS i de tant en tant s'inicia el procés compacte menor, que simplement fusiona fitxers petits amb més grans sense esborrar res. Amb el pas del temps, això es converteix en un problema que només apareix en llegir les dades (hi tornarem una mica més endavant).

A més del procés de càrrega descrit anteriorment, hi ha un procediment molt més eficaç, que potser és el costat més fort d'aquesta base de dades: BulkLoad. Rau en el fet que formem HFiles de manera independent i els posem al disc, la qual cosa ens permet escalar perfectament i aconseguir velocitats molt decents. De fet, la limitació aquí no és HBase, sinó les capacitats del maquinari. A continuació es mostren els resultats d'arrencada en un clúster format per 16 RegionServers i 16 NodeManager YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 fils), versió HBase 1.2.0-cdh5.14.2.

Aquí podeu veure que augmentant el nombre de particions (regions) a la taula, així com els executors de Spark, obtenim un augment de la velocitat de descàrrega. A més, la velocitat depèn del volum de gravació. Els blocs grans donen un augment en MB/s, els blocs petits en el nombre de registres inserits per unitat de temps, amb totes les altres coses iguals.

També podeu començar a carregar en dues taules alhora i aconseguir el doble de velocitat. A continuació podeu veure que l'escriptura de blocs de 10 KB en dues taules alhora es produeix a una velocitat d'uns 600 MB/s en cadascuna (un total de 1275 MB/s), que coincideix amb la velocitat d'escriptura en una taula de 623 MB/s (vegeu núm. 11 anterior)

Però la segona tirada amb registres de 50 KB mostra que la velocitat de descàrrega està creixent lleugerament, fet que indica que s'acosta als valors límit. Al mateix temps, heu de tenir en compte que pràcticament no hi ha cap càrrega creada al mateix HBASE, només cal que primer doneu dades des de hbase:meta i, després d'alinear HFiles, reinicieu les dades de BlockCache i deseu el MemStore buffer al disc, si no està buit.

3. Lectura de dades d'HBASE

Si suposem que el client ja té tota la informació de hbase:meta (vegeu el punt 2), aleshores la sol·licitud va directament al RS on s'emmagatzema la clau requerida. Primer, la cerca es realitza a MemCache. Independentment de si hi ha dades o no, la cerca també es fa a la memòria intermèdia de BlockCache i, si cal, a HFiles. Si s'han trobat dades al fitxer, es col·locaran a BlockCache i es tornaran més ràpidament a la següent sol·licitud. La cerca a HFile és relativament ràpida gràcies a l'ús del filtre Bloom, és a dir. després de llegir una petita quantitat de dades, determina immediatament si aquest fitxer conté la clau necessària i, si no, passa a la següent.

Després d'haver rebut dades d'aquestes tres fonts, RS genera una resposta. En particular, pot transferir diverses versions trobades d'un objecte alhora si el client demana la versió.

4. Emmagatzematge en memòria cau de dades

Els buffers MemStore i BlockCache ocupen fins a un 80% de la memòria RS assignada a l'heap (la resta es reserva per a tasques de servei RS). Si el mode d'ús típic és tal que els processos escriuen i llegeixen immediatament les mateixes dades, llavors té sentit reduir BlockCache i augmentar MemStore, perquè Quan les dades d'escriptura no entren a la memòria cau per llegir-les, BlockCache s'utilitzarà amb menys freqüència. La memòria intermèdia de BlockCache consta de dues parts: LruBlockCache (sempre a l'heap) i BucketCache (normalment fora de l'heap o en un SSD). BucketCache s'ha d'utilitzar quan hi ha moltes sol·licituds de lectura i no encaixen a LruBlockCache, la qual cosa comporta un treball actiu de Garbage Collector. Al mateix temps, no hauríeu d'esperar un augment radical del rendiment de l'ús de la memòria cau de lectura, però hi tornarem al paràgraf 8.

Hi ha un BlockCache per a tot el RS i hi ha un MemStore per a cada taula (un per a cada família de columnes).

Com descrit en teoria, quan s'escriu, les dades no entren a la memòria cau i, de fet, aquests paràmetres CACHE_DATA_ON_WRITE per a la taula i "Dades de la memòria cau a l'escriptura" per a RS s'estableixen en fals. No obstant això, a la pràctica, si escrivim dades a MemStore, després les netegem al disc (per tant, l'esborrem), després suprimim el fitxer resultant i, executant una sol·licitud d'obtenció, rebrem les dades amb èxit. A més, fins i tot si desactiveu completament BlockCache i ompliu la taula amb dades noves, després reinicieu el MemStore al disc, les suprimiu i les sol·liciteu d'una altra sessió, encara es recuperaran d'algun lloc. Així, HBase emmagatzema no només dades, sinó també misteris misteriosos.

hbase(main):001:0> create 'ns:magic', 'cf'
Created table ns:magic
Took 1.1533 seconds
hbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'
Took 0.2610 seconds
hbase(main):003:0> flush 'ns:magic'
Took 0.6161 seconds
hdfs dfs -mv /data/hbase/data/ns/magic/* /tmp/trash
hbase(main):002:0> get 'ns:magic', 'key1'
 cf:c      timestamp=1534440690218, value=try_to_delete_me

El paràmetre "Dades de memòria cau en lectura" s'ha establert en fals. Si teniu alguna idea, benvingut a discutir-la als comentaris.

5. Processament de dades per lots MultiGet/MultiPut

El processament de sol·licituds individuals (Obtenir/Posar/Eliminar) és una operació força costosa, de manera que, si és possible, hauríeu de combinar-les en una llista o llista, que us permeti obtenir un augment significatiu del rendiment. Això és especialment cert per a l'operació d'escriptura, però a l'hora de llegir hi ha el següent error. El gràfic següent mostra el temps per llegir 50 registres de MemStore. La lectura es va realitzar en un sol fil i l'eix horitzontal mostra el nombre de claus de la sol·licitud. Aquí podeu veure que en augmentar a mil claus en una sol·licitud, el temps d'execució baixa, és a dir. augmenta la velocitat. Tanmateix, amb el mode MSLAB activat per defecte, després d'aquest llindar comença una caiguda radical del rendiment i com més gran sigui la quantitat de dades del registre, més llarg serà el temps de funcionament.

Les proves es van realitzar en una màquina virtual, 8 nuclis, versió HBase 2.0.0-cdh6.0.0-beta1.

El mode MSLAB està dissenyat per reduir la fragmentació del munt, que es produeix a causa de la barreja de dades de nova i antiga generació. Com a solució alternativa, quan MSLAB està habilitat, les dades es col·loquen en cel·les relativament petites (trossos) i es processen en trossos. Com a resultat, quan el volum del paquet de dades sol·licitat supera la mida assignada, el rendiment disminueix bruscament. D'altra banda, desactivar aquest mode tampoc és aconsellable, ja que comportarà aturades per GC durant els moments de processament intensiu de dades. Una bona solució és augmentar el volum de la cel·la en el cas d'escriptura activa via put al mateix temps que la lectura. Val la pena assenyalar que el problema no es produeix si, després de la gravació, executeu l'ordre de buidat, que restableix el MemStore al disc, o si carregueu mitjançant BulkLoad. La taula següent mostra que les consultes de MemStore per a dades més grans (i de la mateixa quantitat) produeixen desacceleraments. Tanmateix, augmentant la mida del tros tornem el temps de processament a la normalitat.

A més d'augmentar la mida del fragment, la divisió de les dades per regió ajuda, és a dir. divisió de taula. Això fa que arribin menys sol·licituds a cada regió i si encaixen en una cel·la, la resposta continua sent bona.

6. Estratègia per dividir les taules en regions (divisió)

Com que HBase és un emmagatzematge de valor-clau i la partició es realitza per clau, és extremadament important dividir les dades de manera uniforme en totes les regions. Per exemple, dividir aquesta taula en tres parts farà que les dades es divideixin en tres regions:

Succeeix que això comporta una forta desacceleració si les dades carregades posteriorment semblen, per exemple, valors llargs, la majoria d'ells comencen amb el mateix dígit, per exemple:

1000001
1000002
...
1100003

Com que les claus s'emmagatzemen com a matriu de bytes, totes començaran igual i pertanyen a la mateixa regió número 1 que emmagatzema aquest rang de claus. Hi ha diverses estratègies de partició:

HexStringSplit: converteix la clau en una cadena codificada hexadecimal en l'interval "00000000" => "FFFFFFFF" i el farciment a l'esquerra amb zeros.

UniformSplit: converteix la clau en una matriu de bytes amb codificació hexadecimal en l'interval "00" => "FF" i farciment a la dreta amb zeros.

A més, podeu especificar qualsevol rang o conjunt de claus per dividir i configurar la divisió automàtica. Tanmateix, un dels enfocaments més senzills i efectius és UniformSplit i l'ús de la concatenació hash, per exemple, el parell de bytes més significatiu de l'execució de la clau a través de la funció CRC32 (rowkey) i la pròpia rowkey:

hash + rowkey

Aleshores, totes les dades es distribuiran uniformement entre regions. En llegir, els dos primers bytes simplement es descarten i la clau original es manté. RS també controla la quantitat de dades i claus a la regió i, si es superen els límits, automàticament la divideix en parts.

7. Tolerància a fallades i localitat de les dades

Atès que només una regió és responsable de cada conjunt de claus, la solució als problemes associats als bloquejos de RS o la desactivació és emmagatzemar totes les dades necessàries a HDFS. Quan cau RS, el mestre ho detecta a través de l'absència de batecs cardíacs al node ZooKeeper. A continuació, assigna la regió servida a un altre RS i com que els HFfiles s'emmagatzemen en un sistema de fitxers distribuït, el nou propietari els llegeix i continua distribuint les dades. Tanmateix, com que algunes de les dades poden estar a la MemStore i no van tenir temps d'entrar a HFiles, WAL, que també s'emmagatzema a HDFS, s'utilitza per restaurar l'historial d'operacions. Després d'aplicar els canvis, RS és capaç de respondre a les sol·licituds, però el moviment porta al fet que algunes de les dades i els processos que les atenen acaben en diferents nodes, és a dir. localitat està disminuint.

La solució al problema és una compactació important: aquest procediment mou els fitxers als nodes responsables d'ells (on es troben les seves regions), de manera que durant aquest procediment la càrrega a la xarxa i als discs augmenta bruscament. Tanmateix, en el futur, l'accés a les dades s'accelerarà notablement. A més, major_compaction realitza la fusió de tots els HFiles en un sol fitxer dins d'una regió i també neteja les dades en funció de la configuració de la taula. Per exemple, podeu especificar el nombre de versions d'un objecte que s'han de conservar o el temps de vida després del qual s'elimina físicament l'objecte.

Aquest procediment pot tenir un efecte molt positiu en el funcionament de l'HBase. La imatge següent mostra com es va degradar el rendiment com a resultat de l'enregistrament de dades actiu. Aquí podeu veure com 40 fils escrivien a una taula i 40 fils llegeixen dades simultàniament. Els fils d'escriptura generen cada cop més fitxers HF, que són llegits per altres fils. Com a conseqüència, cada cop s'han d'eliminar més dades de la memòria i finalment el GC comença a funcionar, cosa que pràcticament paralitza tota la feina. El llançament d'una compactació important va comportar la neteja dels residus resultants i la restauració de la productivitat.

La prova es va realitzar en 3 DataNodes i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 fils). HBase versió 1.2.0-cdh5.14.2

Val la pena assenyalar que es va llançar una compactació important en una taula "en directe", en la qual les dades es van escriure i llegir activament. Hi va haver una declaració en línia que això podria provocar una resposta incorrecta en llegir les dades. Per comprovar-ho, es va iniciar un procés que generava dades noves i les escrivia en una taula. Després de la qual cosa immediatament vaig llegir i comprovar si el valor resultant coincideix amb el que estava escrit. Mentre s'executava aquest procés, es va fer una compactació important unes 200 vegades i no es va registrar ni una fallada. Potser el problema apareix rarament i només durant una càrrega elevada, de manera que és més segur aturar els processos d'escriptura i lectura tal com s'havia planificat i realitzar una neteja per evitar aquestes baixades de GC.

A més, la compactació important no afecta l'estat del MemStore; per esborrar-lo al disc i compactar-lo, heu d'utilitzar flush (connection.getAdmin().flush(TableName.valueOf(tblName))).

8. Configuració i rendiment

Com ja s'ha esmentat, HBase mostra el seu major èxit allà on no necessita fer res, en executar BulkLoad. Tanmateix, això s'aplica a la majoria de sistemes i persones. Tanmateix, aquesta eina és més adequada per emmagatzemar dades a granel en blocs grans, mentre que si el procés requereix diverses sol·licituds de lectura i escriptura competidores, s'utilitzen les ordres Get i Put descrites anteriorment. Per determinar els paràmetres òptims, es van realitzar llançaments amb diverses combinacions de paràmetres i paràmetres de la taula:

• Es van llançar 10 fils simultàniament 3 vegades seguides (anomenem això un bloc de fils).
• Es va fer una mitjana del temps de funcionament de tots els fils d'un bloc i va ser el resultat final de l'operació del bloc.
• Tots els fils treballaven amb la mateixa taula.
• Abans de cada inici del bloc de rosca, es va realitzar una compactació important.
• Cada bloc només va realitzar una de les operacions següents:

—Posa
-Aconseguir
—Aconsegueix + Posa

• Cada bloc va realitzar 50 iteracions del seu funcionament.
• La mida de bloc d'un registre és de 100 bytes, 1000 bytes o 10000 bytes (aleatori).
• Es van llançar blocs amb diferents nombres de claus sol·licitades (una clau o 10).
• Els blocs es van executar amb diferents configuracions de taula. Paràmetres canviats:

— BlockCache = activat o desactivat
— BlockSize = 65 KB o 16 KB
— Particions = 1, 5 o 30
— MSLAB = activat o desactivat

Per tant, el bloc té aquest aspecte:

a. El mode MSLAB s'ha activat/desactivat.
b. Es va crear una taula per a la qual es van establir els paràmetres següents: BlockCache = true/none, BlockSize = 65/16 Kb, Partition = 1/5/30.
c. La compressió es va establir a GZ.
d. Es van llançar 10 fils simultàniament fent operacions d'1/10 put/get/get+put en aquesta taula amb registres de 100/1000/10000 bytes, realitzant 50 consultes seguides (claus aleatòries).
e. El punt d es va repetir tres vegades.
f. Es va fer una mitjana del temps de funcionament de tots els fils.

Es van provar totes les combinacions possibles. És previsible que la velocitat disminueixi a mesura que augmenta la mida del registre o que la desactivació de l'emmagatzematge a la memòria cau provocarà una desacceleració. No obstant això, l'objectiu era entendre el grau i la importància de la influència de cada paràmetre, de manera que les dades recollides es van introduir a l'entrada d'una funció de regressió lineal, que permet avaluar la significació mitjançant estadístiques t. A continuació es mostren els resultats dels blocs que realitzen operacions Put. Conjunt complet de combinacions 2*2*3*2*3 = 144 opcions + 72 tk. alguns es van fer dues vegades. Per tant, hi ha 216 tirades en total:

Les proves es van dur a terme en un mini-clúster format per 3 DataNodes i 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 fils). HBase versió 1.2.0-cdh5.14.2.

La velocitat d'inserció més alta de 3.7 segons es va obtenir amb el mode MSLAB desactivat, en una taula amb una partició, amb BlockCache habilitat, BlockSize = 16, registres de 100 bytes, 10 peces per paquet.
La velocitat d'inserció més baixa de 82.8 segons es va obtenir amb el mode MSLAB habilitat, en una taula amb una partició, amb BlockCache habilitat, BlockSize = 16, registres de 10000 bytes, 1 cadascun.

Ara mirem el model. Veiem la bona qualitat del model basat en R2, però és absolutament clar que l'extrapolació està contraindicada aquí. El comportament real del sistema quan canvien els paràmetres no serà lineal; aquest model no és necessari per fer prediccions, sinó per entendre què va passar dins dels paràmetres donats. Per exemple, aquí veiem pel criteri de l'estudiant que els paràmetres BlockSize i BlockCache no importen per a l'operació Put (que generalment és bastant previsible):

Però el fet que augmentar el nombre de particions condueixi a una disminució del rendiment és una mica inesperat (ja hem vist l'impacte positiu d'augmentar el nombre de particions amb BulkLoad), tot i que és comprensible. En primer lloc, per al processament, heu de generar sol·licituds a 30 regions en lloc d'una, i el volum de dades no és tal que això doni un guany. En segon lloc, el temps total de funcionament està determinat per l'RS més lent, i com que el nombre de DataNodes és menor que el nombre de RS, algunes regions tenen una localitat zero. Bé, mirem els cinc primers:

Ara avaluem els resultats d'executar els blocs Get:

El nombre de particions ha perdut importància, la qual cosa probablement s'explica pel fet que les dades s'emmagatzemen bé i la memòria cau de lectura és el paràmetre més significatiu (estadísticament). Naturalment, augmentar el nombre de missatges en una sol·licitud també és molt útil per al rendiment. Màximes puntuacions:

Bé, finalment, mirem el model del bloc que primer va realitzar get i després posem:

Tots els paràmetres són significatius aquí. I els resultats dels líders:

9. Prova de càrrega

Bé, finalment llançarem una càrrega més o menys decent, però sempre és més interessant quan tens alguna cosa amb què comparar. Al lloc web de DataStax, el desenvolupador clau de Cassandra, hi ha troballes NT d'una sèrie d'emmagatzematge NoSQL, inclosa la versió HBase 0.98.6-1. La càrrega es va dur a terme mitjançant 40 fils, mida de dades de 100 bytes, discs SSD. El resultat de provar les operacions de lectura-modificació-escriptura va mostrar els resultats següents.

Pel que tinc entès, la lectura es va dur a terme en blocs de 100 registres i per a 16 nodes HBase, la prova DataStax va mostrar un rendiment de 10 mil operacions per segon.

És una sort que el nostre clúster també tingui 16 nodes, però no és gaire “afortunat” que cadascun tingui 64 nuclis (fils), mentre que a la prova DataStax només n'hi ha 4. En canvi, tenen unitats SSD, mentre que nosaltres tenim HDD. o més, la nova versió d'HBase i la utilització de la CPU durant la càrrega pràcticament no va augmentar significativament (visualment en un 5-10 per cent). Tanmateix, intentem començar a utilitzar aquesta configuració. Configuració per defecte de la taula, la lectura es realitza en l'interval de claus de 0 a 50 milions de manera aleatòria (és a dir, essencialment nova cada vegada). La taula conté 50 milions de registres, dividits en 64 particions. Les claus s'hagin utilitzant crc32. La configuració de la taula és per defecte, MSLAB està habilitat. En llançar 40 fils, cada fil llegeix un conjunt de 100 claus aleatòries i escriu immediatament els 100 bytes generats a aquestes claus.

Suport: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 fils). HBase versió 1.2.0-cdh5.14.2.

El resultat mitjà és més proper a les 40 mil operacions per segon, que és significativament millor que a la prova DataStax. Tanmateix, amb finalitats experimentals, podeu canviar lleugerament les condicions. És molt poc probable que tot el treball es dugui a terme exclusivament en una taula, i també només amb claus úniques. Suposem que hi ha un determinat conjunt de tecles "calents" que genera la càrrega principal. Per tant, intentem crear una càrrega amb registres més grans (10 KB), també en lots de 100, en 4 taules diferents i limitant el rang de claus sol·licitades a 50 mil. El gràfic següent mostra el llançament de 40 fils, cada fil llegeix un conjunt de 100 tecles i escriu immediatament 10 KB aleatoris en aquestes tecles.

Suport: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 fils). HBase versió 1.2.0-cdh5.14.2.

Durant la càrrega, la compactació important es va llançar diverses vegades, com es mostra anteriorment, sense aquest procediment, el rendiment es degradarà gradualment, però també es produeix una càrrega addicional durant l'execució. Les baixes són causades per diferents motius. De vegades, els fils acabaven de funcionar i hi havia una pausa mentre es reiniciaven, de vegades les aplicacions de tercers creaven una càrrega al clúster.

Llegir i escriure immediatament és un dels escenaris de treball més difícils per a HBase. Si només feu sol·licituds petites, per exemple 100 bytes, combinant-les en paquets de 10-50 mil peces, podeu obtenir centenars de milers d'operacions per segon, i la situació és similar amb les sol·licituds de només lectura. Val la pena assenyalar que els resultats són radicalment millors que els obtinguts per DataStax, sobretot a causa de les peticions en blocs de 50 mil.

Suport: 16 DataNode i 16 RS (CPU Xeon E5-2680 v4 @ 2.40 GHz * 64 fils). HBase versió 1.2.0-cdh5.14.2.

10. Conclusions

Aquest sistema es configura de manera bastant flexible, però encara es desconeix la influència d'un gran nombre de paràmetres. Alguns d'ells es van provar, però no es van incloure en el conjunt de proves resultant. Per exemple, els experiments preliminars van mostrar una importància insignificant d'un paràmetre com DATA_BLOCK_ENCODING, que codifica informació mitjançant valors de cel·les veïnes, cosa que és comprensible per a dades generades aleatòriament. Si utilitzeu un gran nombre d'objectes duplicats, el guany pot ser important. En general, podem dir que HBase dóna la impressió d'una base de dades força seriosa i ben pensada, que pot ser força productiva quan es realitzen operacions amb grans blocs de dades. Sobretot si és possible separar en el temps els processos de lectura i escriptura.

Si al vostre parer hi ha alguna cosa que no s'ha revelat prou, estic disposat a explicar-vos-ho amb més detall. Et convidem a compartir la teva experiència o discutir si no estàs d'acord amb alguna cosa.

Font: www.habr.com