Bazaj Dezajnaj Bazaj Bazoj - Komparante PostgreSQL, Cassandra kaj MongoDB

Saluton, amikoj. Antaŭ ol foriri al la dua parto de la majaj ferioj, ni dividas kun vi la materialon, kiun ni tradukis antaŭ la lanĉo de nova fluo laŭ la rapideco. "Relacia DBMS".

Programistoj de aplikaĵoj pasigas multan tempon komparante plurajn funkciajn datumbazojn por elekti tiun, kiu plej bone funkcias por sia celita laborkvanto. Bezonoj povas inkluzivi simpligitan datummodeladon, transakciajn garantiojn, legadon/skriban efikecon, horizontalan skalon, kaj faŭltoleremo. Tradicie, la elekto komenciĝas per la kategorio de datumbazo, SQL aŭ NoSQL, ĉar ĉiu kategorio disponigas klaran aron de kompromisoj. Alta rendimento laŭ malalta latenteco kaj alta trafluo estas ĝenerale vidita kiel postulo kiu ne povas esti endanĝerigita kaj estas tial esenca por iu datumbazo en la specimeno.

La celo de ĉi tiu artikolo estas helpi programistojn fari la ĝustan elekton inter SQL kaj NoSQL en la kunteksto de aplikaĵa datuma modelado. Ni rigardos unu SQL-datumbazon, nome PostgreSQL, kaj du NoSQL-datumbazon, Cassandra kaj MongoDB, por kovri la bazaĵojn de datumbaza dezajno, kiel krei tabelojn, plenigi ilin, legi datumojn de tabelo kaj forigi ilin. En la sekva artikolo, ni certe rigardos indeksojn, transakciojn, JOIN-ojn, TTL-direktivojn kaj datumbazan dezajnon bazitan sur JSON.

Kio estas la diferenco inter SQL kaj NoSQL?

SQL-datumbazoj pliigas aplikaĵflekseblecon per ACID-transakciaj garantioj, same kiel sian kapablon pridemandi datenojn uzante JOIN-ojn en neatenditaj manieroj aldone al ekzistantaj normaligitaj interrilataj datumbazmodeloj.

Surbaze de ilia monolita/ununoda arkitekturo kaj uzo de majstra-sklava reproduktadmodelo por redundo, al tradiciaj SQL-datumbazoj mankas du gravaj ecoj - linia skribskaleblo (t.e. aŭtomata disigo trans multoblaj nodoj) kaj aŭtomata/nul datenperdo. Ĉi tio signifas, ke la kvanto de datumoj ricevitaj ne povas superi la maksimuman skriban trairon de ununura nodo. Krome, iu provizora perdo de datenoj devas esti enkalkulita por misfunkciadotoleremo (en ne-komuna arkitekturo). Ĉi tie vi devas memori, ke lastatempaj komitaĵoj ankoraŭ ne reflektiĝis en la sklava kopio. Neniuj malfunkciaj ĝisdatigoj ankaŭ malfacilas atingi en SQL-datumbazoj.

NoSQL-datumbazoj estas tipe distribuitaj en naturo, t.e. en ili, la datumoj estas dividitaj en sekciojn kaj distribuitaj sur pluraj nodoj. Ili postulas malnormaligon. Ĉi tio signifas, ke la enigitaj datumoj ankaŭ devas esti kopiitaj plurfoje por respondi al la specifaj petoj, kiujn vi sendas. La ĝenerala celo estas akiri altan rendimenton reduktante la nombron da fragmentoj disponeblaj ĉe legado. Ĉi tio implicas, ke NoSQL postulas, ke vi modelu viajn demandojn, dum SQL postulas, ke vi modelu viajn datumojn.

NoSQL emfazas atingi altan rendimenton en distribuita areto kaj ĉi tio estas la ĉefa raciaĵo por multaj datumbazaj dezajnokomercoj, kiuj inkluzivas perdon de ACID-transakcioj, JOIN-oj kaj konsekvencaj tutmondaj sekundaraj indeksoj.

Estas opinio ke kvankam NoSQL-datumbazoj disponigas linearan skribskaleblon kaj altan faŭltoleremo, la perdo de transakciaj garantioj igas ilin malraciaj por kritikaj datumoj.

La sekva tabelo montras kiel datuma modelado en NoSQL diferencas de SQL.

SQL kaj NoSQL: Kial ambaŭ estas bezonataj?

Realvivaj aplikoj kun granda nombro da uzantoj, kiel Amazon.com, Netflix, Uber kaj Airbnb, respondecas pri plenumi kompleksajn taskojn de diversaj specoj. Ekzemple, e-komerca aplikaĵo kiel Amazon.com bezonas stoki malpezajn, tre sentemajn datumojn kiel informojn pri uzantoj, produktoj, mendoj, fakturoj, kune kun pezaj sed malpli sentemaj datumoj kiel produktaj recenzoj, subtenaj mesaĝoj. , uzantagado. , recenzoj de uzantoj kaj rekomendoj. Kompreneble, ĉi tiuj aplikoj dependas de almenaŭ unu SQL-datumbazo kune kun almenaŭ unu NoSQL-datumbazo. En inter-regionaj kaj tutmondaj sistemoj, NoSQL-datumbazo funkcias kiel geo-distribuita kaŝmemoro por datumoj stokitaj en fidinda fonto, SQL-datumbazo, funkcianta en iu ajn regiono.

Kiel YugaByte DB kombinas SQL kaj NoSQL?

Konstruita sur ŝtip-orientita miksita stokado-motoro, aŭto-sharding, sharded distribuita interkonsentreproduktado, kaj ACID distribuitaj transakcioj (inspiritaj de Google Spanner), YugaByte DB estas la unua malfermfonta datumbazo de la monda kiu estas samtempe NoSQL (Cassandra & Redis) kongrua. ) kaj SQL (PostgreSQL). Kiel montrite en la malsupra tabelo, YCQL, YugaByte DB API kongrua kun Cassandra, aldonas la konceptojn de unuopaj kaj plurŝlosilaj ACID-transakcioj kaj tutmondaj sekundaraj indeksoj al la NoSQL-API, tiel enkondukante la epokon de transakciaj NoSQL-datumbazoj. Krome, YCQL, YugaByte DB API kongrua kun PostgreSQL, aldonas la konceptojn de lineara skribskalo kaj aŭtomata malsukceso al la SQL-API, alportante distribuitajn SQL-datumbazon al la mondo. Ĉar la YugaByte DB-datumbazo estas esence transakcia, la NoSQL-API nun povas esti uzata en la kunteksto de kritikaj datumoj.

Kiel antaŭe dirite en la artikolo "Enkondukante YSQL: PostgreSQL Kongrua Distribuita SQL-API por YugaByte DB", la elekto inter SQL aŭ NoSQL en YugaByte DB dependas tute de la karakterizaĵoj de la subesta laborkvanto:

• Se via ĉefa laborŝarĝo estas plurklavaj JOIN-operacioj, tiam elektante YSQL, konsciu, ke viaj ŝlosiloj povas esti disvastigitaj tra pluraj nodoj, rezultigante pli altan latentecon kaj/aŭ pli malaltan trairon ol NoSQL.
• Alie, elektu iun el la du NoSQL-API-oj, memorante, ke vi ricevos pli bonan rendimenton kiel rezulto de demandoj servitaj de unu nodo samtempe. YugaByte DB povas funkcii kiel ununura funkcia datumbazo por realaj kompleksaj aplikoj, kiuj bezonas administri plurajn laborŝarĝojn samtempe.

La Laboratorio pri Modelado de Datumoj en la sekva sekcio baziĝas sur la API-datumbazaj YugaByte DB kongruaj PostgreSQL kaj Cassandra, kontraste al la originaj datumbazoj. Tiu aliro emfazas la facilecon de interagado kun du malsamaj APIoj (sur du malsamaj havenoj) de la sama datumbaza areto, kontraste al uzado de tute sendependaj aretoj de du malsamaj datumbazoj.
En la sekvaj sekcioj, ni rigardos la Laboratorion pri Modelado de Datumoj por ilustri la diferencon kaj iujn komunajn partojn de la koncernaj datumbazoj.

Laboratorio pri Modelado de Datumoj

Instalado de datumbazoj

Konsiderante la fokuson pri datummodelo-dezajno (prefere ol kompleksaj disfaldaj arkitekturoj), ni instalos la datumbazojn en Docker-ujoj sur la loka maŝino kaj poste interagos kun ili uzante iliajn respektivajn komandliniajn ŝelojn.

PostgreSQL & Cassandra kongrua, YugaByte DB datumbazo

mkdir ~/yugabyte && cd ~/yugabyte
wget https://downloads.yugabyte.com/yb-docker-ctl && chmod +x yb-docker-ctl
docker pull yugabytedb/yugabyte
./yb-docker-ctl create --enable_postgres

MongoDB

docker run --name my-mongo -d mongo:latest

Komandlinia aliro

Ni konektu al la datumbazoj uzante la komandlinian ŝelon por la respektivaj APIoj.

PostgreSQL

psql estas komandlinia ŝelo por interagi kun PostgreSQL. Por facileco de uzo, YugaByte DB venas kun psql ĝuste en la bin dosierujo.

docker exec -it yb-postgres-n1 /home/yugabyte/postgres/bin/psql -p 5433 -U postgres

Cassandra

sqlsh estas komandlinia ŝelo por interagado kun Cassandra kaj ĝiaj kongruaj datumbazoj per CQL (Cassandra Query Language). Por facileco de uzo, YugaByte DB venas kun cqlsh en la katalogo bin.
Notu, ke CQL estis inspirita de SQL kaj havas similajn konceptojn de tabeloj, vicoj, kolumnoj kaj indeksoj. Tamen, kiel NoSQL-lingvo, ĝi aldonas certan aron da restriktoj, la plej multajn el kiuj ni kovros ankaŭ en aliaj artikoloj.

docker exec -it yb-tserver-n1 /home/yugabyte/bin/cqlsh

MongoDB

Mongo estas komandlinia ŝelo por interagi kun MongoDB. Ĝi troveblas en la bin dosierujo de la instalado de MongoDB.

docker exec -it my-mongo bash 
cd bin
mongo

Kreu tabelon

Nun ni povas interagi kun la datumbazo por fari diversajn operaciojn uzante la komandlinion. Ni komencu kreante tabelon, kiu konservas informojn pri kantoj skribitaj de malsamaj artistoj. Ĉi tiuj kantoj povas esti parto de albumo. Ankaŭ laŭvolaj atributoj por la kanto estas eldonjaro, prezo, ĝenro kaj rangigo. Ni devas konsideri kromajn atributojn, kiuj eble estos bezonataj estonte per la kampo "etikedoj". Ĝi povas stoki duonstrukturajn datumojn kiel ŝlosil-valoraj paroj.

PostgreSQL

CREATE TABLE Music (
    Artist VARCHAR(20) NOT NULL, 
    SongTitle VARCHAR(30) NOT NULL,
    AlbumTitle VARCHAR(25),
    Year INT,
    Price FLOAT,
    Genre VARCHAR(10),
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);	

Cassandra

Krei tabelon en Cassandra tre similas al PostgreSQL. Unu el la ĉefaj diferencoj estas la foresto de integreclimoj (kiel NOT NULL), sed ĉi tio estas la respondeco de la aplikaĵo, ne la NoSQL-datumbazo.. La primara ŝlosilo konsistas el dispartiga ŝlosilo (Artista kolumno en la malsupra ekzemplo) kaj aro de grupigaj kolumnoj (SongTitle-kolumno en la malsupra ekzemplo). La sekcioŝlosilo determinas en kiun subdiskon/shardon meti la vicon, kaj la grupaj kolumnoj indikas kiel la datumoj devus esti organizitaj ene de la nuna peceto.

CREATE KEYSPACE myapp;
USE myapp;
CREATE TABLE Music (
    Artist TEXT, 
    SongTitle TEXT,
    AlbumTitle TEXT,
    Year INT,
    Price FLOAT,
    Genre TEXT,
    CriticRating FLOAT,
    Tags TEXT,
    PRIMARY KEY(Artist, SongTitle)
);

MongoDB

MongoDB organizas datumojn en datumbazojn (Datumbazo) (simila al Keyspace en Kasandra), kie estas kolektoj (Kolektoj) (similaj al tabeloj) kiuj enhavas dokumentojn (Dokumentoj) (similaj al vicoj en tabelo). En MongoDB, principe, neniu komenca skemdifino estas postulata. Teamo "uzi datumbazon", montrita malsupre, instantiigas la datumbazon sur la unua voko kaj ŝanĝas la kuntekston por la lastatempe kreita datumbazo. Eĉ kolektoj ne bezonas esti kreitaj eksplicite, ili estas kreitaj aŭtomate, ĝuste kiam la unua dokumento estas aldonita al nova kolekto. Notu, ke MongoDB uzas testan datumbazon defaŭlte, do ajna kolektonivela operacio sen specifa datumbazo estos farita en ĝi defaŭlte.

use myNewDatabase;

Akiri informojn pri tablo
PostgreSQL

d Music
Table "public.music"
    Column    |         Type          | Collation | Nullable | Default 
--------------+-----------------------+-----------+----------+--------
 artist       | character varying(20) |           | not null | 
 songtitle    | character varying(30) |           | not null | 
 albumtitle   | character varying(25) |           |          | 
 year         | integer               |           |          | 
 price        | double precision      |           |          | 
 genre        | character varying(10) |           |          | 
 criticrating | double precision      |           |          | 
 tags         | text                  |           |          | 
Indexes:
    "music_pkey" PRIMARY KEY, btree (artist, songtitle)

Cassandra

DESCRIBE TABLE MUSIC;
CREATE TABLE myapp.music (
    artist text,
    songtitle text,
    albumtitle text,
    year int,
    price float,
    genre text,
    tags text,
    PRIMARY KEY (artist, songtitle)
) WITH CLUSTERING ORDER BY (songtitle ASC)
    AND default_time_to_live = 0
    AND transactions = {'enabled': 'false'};

MongoDB

use myNewDatabase;
show collections;

Enigante datumojn en tabelon
PostgreSQL

INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Year, Price, Genre, CriticRating, 
    Tags)
VALUES(
    'No One You Know', 'Call Me Today', 'Somewhat Famous',
    2015, 2.14, 'Country', 7.8,
    '{"Composers": ["Smith", "Jones", "Davis"],"LengthInSeconds": 214}'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, CriticRating)
VALUES(
    'No One You Know', 'My Dog Spot', 'Hey Now',
    1.98, 'Country', 8.4
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre)
VALUES(
    'The Acme Band', 'Look Out, World', 'The Buck Starts Here',
    0.99, 'Rock'
);
INSERT INTO Music 
    (Artist, SongTitle, AlbumTitle, 
    Price, Genre, 
    Tags)
VALUES(
    'The Acme Band', 'Still In Love', 'The Buck Starts Here',
    2.47, 'Rock', 
    '{"radioStationsPlaying": ["KHCR", "KBQX", "WTNR", "WJJH"], "tourDates": { "Seattle": "20150625", "Cleveland": "20150630"}, "rotation": Heavy}'
);

Cassandra

Ĝenerale, la esprimo INSERT en Cassandra aspektas tre simila al tiu en PostgreSQL. Tamen, estas unu granda diferenco en semantiko. En Kasandra INSERT estas efektive operacio UPSERT, kie la plej novaj valoroj estas aldonitaj al la ĉeno, se la ĉeno jam ekzistas.

Eniro de datumoj similas al PostgreSQL INSERT altaj

.

MongoDB

Eĉ kvankam MongoDB estas NoSQL-datumbazo kiel Cassandra, ĝia enigo de datumoj ne havas nenian rilaton kun la semantika konduto de Cassandra. En MongoDB enmeti () havas neniun ŝancon UPSERT, kiu faras ĝin simila al PostgreSQL. Aldonante defaŭltajn datumojn sen _idspecified rezultigos novan dokumenton aldonitan al la kolekto.

db.music.insert( {
artist: "No One You Know",
songTitle: "Call Me Today",
albumTitle: "Somewhat Famous",
year: 2015,
price: 2.14,
genre: "Country",
tags: {
Composers: ["Smith", "Jones", "Davis"],
LengthInSeconds: 214
}
}
);
db.music.insert( {
artist: "No One You Know",
songTitle: "My Dog Spot",
albumTitle: "Hey Now",
price: 1.98,
genre: "Country",
criticRating: 8.4
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Look Out, World",
albumTitle:"The Buck Starts Here",
price: 0.99,
genre: "Rock"
}
);
db.music.insert( {
artist: "The Acme Band",
songTitle: "Still In Love",
albumTitle:"The Buck Starts Here",
price: 2.47,
genre: "Rock",
tags: {
radioStationsPlaying:["KHCR", "KBQX", "WTNR", "WJJH"],
tourDates: {
Seattle: "20150625",
Cleveland: "20150630"
},
rotation: "Heavy"
}
}
);

Tabeldemando

Eble la plej grava diferenco inter SQL kaj NoSQL rilate pridemandadon estas la uzo de FROM и WHERE. SQL permesas post esprimo FROM elektu plurajn tabelojn, kaj esprimon kun WHERE povas esti de ajna komplekseco (inkluzive de operacioj JOIN inter tabloj). Tamen, NoSQL emas trudi malfacilan limon al FROM, kaj labori kun nur unu specifita tablo, kaj en WHERE, la ĉefa ŝlosilo ĉiam devas esti specifita. Ĉi tio estas pro la deziro plibonigi la agadon de NoSQL, pri kiu ni parolis antaŭe. Ĉi tiu deziro kondukas al ĉiu ebla redukto de iu ajn krucklabo kaj krucŝlosila interago. Ĝi povas enkonduki grandan prokraston en inter-noda komunikado dum respondado al peto kaj tial estas plej bone evitita principe. Ekzemple, Cassandra postulas petojn esti limigitaj al certaj funkciigistoj (nur permesite =, IN, <, >, =>, <=) sur dispartŝlosiloj, krom kiam oni pridemandas sekundaran indekson (nur la = operatoro estas permesita ĉi tie).

PostgreSQL

La sekvantaroj estas tri ekzemploj de demandoj, kiuj povas esti facile efektivigitaj de SQL-datumbazo.

• Montru ĉiujn kantojn de la artisto;
• Montru ĉiujn kantojn de la artisto, kiuj kongruas kun la unua parto de la titolo;
• Montru ĉiujn kantojn de la artisto, kiuj havas certan vorton en la titolo kaj havas prezon malpli ol 1.00.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE 'Call%';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle LIKE '%Today%'
AND Price > 1.00;

Cassandra

El la postgreSQL-demandoj listigitaj supre, nur la unua funkcios senŝanĝe en Cassandra, ĉar la deklaro LIKE ne povas esti aplikita al grupigado de kolumnoj kiel ekzemple SongTitle. En ĉi tiu kazo, nur funkciigistoj estas permesitaj = и IN.

SELECT * FROM Music
WHERE Artist='No One You Know';
SELECT * FROM Music
WHERE Artist='No One You Know' AND SongTitle IN ('Call Me Today', 'My Dog Spot')
AND Price > 1.00;

MongoDB

Kiel montrite en la antaŭaj ekzemploj, la ĉefa metodo por krei demandojn en MongoDB estas db.collection.find (). Ĉi tiu metodo eksplicite enhavas la nomon de la kolekto (music en la malsupra ekzemplo), do pridemandi plurajn kolektojn ne estas permesita.

db.music.find( {
  artist: "No One You Know"
 } 
);
db.music.find( {
  artist: "No One You Know",
  songTitle: /Call/
 } 
);

Legante ĉiujn vicojn de tabelo

Legi ĉiujn vicojn estas nur speciala kazo de la demanda ŝablono, kiun ni antaŭe diskutis.

PostgreSQL

SELECT * 
FROM Music;

Cassandra

Simila al la ekzemplo de PostgreSQL supre.

MongoDB

db.music.find( {} );

Redaktado de datumoj en tabelo

PostgreSQL

PostgreSQL provizas deklaron UPDATE por ŝanĝi datumojn. Ŝi ne havas ŝancon UPSERT, do ĉi tiu deklaro malsukcesos se la vico ne plu estas en la datumbazo.

UPDATE Music
SET Genre = 'Disco'
WHERE Artist = 'The Acme Band' AND SongTitle = 'Still In Love';

Cassandra

Kasandra havas UPDATE simila al PostgreSQL. UPDATE havas la saman semantikon UPSERT, Ŝati INSERT.

Simila al la ekzemplo de PostgreSQL supre.

MongoDB
Funkciado ĝisdatigo () en MongoDB ĝi povas komplete ĝisdatigi ekzistantan dokumenton aŭ ĝisdatigi nur certajn kampojn. Defaŭlte ĝi ĝisdatigas nur unu dokumenton kun semantiko malebligita UPSERT. Refreŝigu plurajn dokumentojn kaj similan konduton UPSERT povas esti aplikita metante pliajn flagojn por la operacio. Kiel ekzemple en la malsupra ekzemplo, la ĝenro de aparta artisto estas ĝisdatigita per lia kanto.

db.music.update(
  {"artist": "The Acme Band"},
  { 
    $set: {
      "genre": "Disco"
    }
  },
  {"multi": true, "upsert": true}
);

Forigante datumojn de tabelo

PostgreSQL

DELETE FROM Music
WHERE Artist = 'The Acme Band' AND SongTitle = 'Look Out, World';

Cassandra

Simila al la ekzemplo de PostgreSQL supre.

MongoDB

MongoDB havas du specojn de operacioj por forigi dokumentojn − deleteOne() /deleteMany() и forigi (). Ambaŭ tipoj forigas dokumentojn sed redonas malsamajn rezultojn.

db.music.deleteMany( {
        artist: "The Acme Band"
    }
);

Forigante tabelon

PostgreSQL

DROP TABLE Music;

Cassandra

Simila al la ekzemplo de PostgreSQL supre.

MongoDB

db.music.drop();

konkludo

La debato pri la elekto inter SQL kaj NoSQL furiozas dum pli ol 10 jaroj. Estas du ĉefaj aspektoj al ĉi tiu debato: la arkitekturo de la datumbaza motoro (monolita, transakcia SQL kontraŭ distribuita, ne-transakcia NoSQL) kaj la aliro al datumbaza dezajno (datummodeligado en SQL kontraŭ modeligado de viaj demandoj en NoSQL).

Kun distribuita transakcia datumbazo kiel YugaByte DB, la datumbaza arkitekturdebato povas esti facile dispelita. Ĉar datenvolumoj iĝas pli grandaj ol kio povas esti skribita al ununura nodo, plene distribuita arkitekturo kiu apogas linearan skribskaleblon kun aŭtomata sharding/rebalancado iĝas necesa.

Krom tio, kio estis dirita en unu el la artikoloj Google Nubo, transakciaj, forte konsekvencaj arkitekturoj nun estas pli vaste adoptitaj por disponigi pli bonan evoluflekseblecon ol ne-transakciaj, finfine konsekvencaj arkitekturoj.

Revenante al la diskuto pri datumbaza dezajno, estas juste diri, ke ambaŭ dezajnaj aliroj (SQL kaj NoSQL) estas necesaj por iu kompleksa reala aplikaĵo. La "datummodeliga" aliro de SQL permesas al programistoj pli facile renkonti ŝanĝiĝantajn komercpostulojn, dum la "demandmodeliga" aliro de NoSQL permesas al tiuj samaj programistoj pritrakti grandajn kvantojn da datenoj kun malalta latencia kaj alta trafluo. Estas tial ke YugaByte DB disponigas SQL kaj NoSQL-APIojn en komuna kerno, kaj ne rekomendas iun ajn el la aliroj. Krome, provizante kongruon kun popularaj datumbazaj lingvoj, inkluzive de PostgreSQL kaj Cassandra, YugaByte DB certigas, ke programistoj ne devas lerni alian lingvon por labori kun distribuita forte konsekvenca datumbaza motoro.

En ĉi tiu artikolo, ni rigardis kiel la bazbazoj pri datumbaza dezajno diferencas inter PostgreSQL, Cassandra kaj MongoDB. En la sekvaj artikoloj, ni plonĝos en altnivelajn dezajnokonceptojn kiel ekzemple indeksoj, transakcioj, JOIN-oj, TTL-direktivoj kaj JSON-dokumentoj.

Ni deziras al vi bonegan semajnfinon kaj invitas vin senpaga retseminariokiu okazos la 14-an de majo.

fonto: www.habr.com