Google Cloud Spanner
Školení, která pořádám 
Google nedávno veřejně nabídl databázi Spanner, kterou masivně používá i interně. Co mě na tomto úložišti zaujalo:
- Pro zadávání příkazů se používá staré dobré SQL. Kromě toho se ale na čtení a zápis dá používat i API, což mimo jiné snižuje riziko SQL Injection.
- Pevné schéma databáze, které se dá později změnit.
- Plná podpora ACID transakcí.
- Zdánlivé prolomení CAP theoremu. Spanner je vždy konzistentní (C) a tolerantní vůči výpadkům sítě (P). Nemusí být vždy dostupný (A), ale vzhledem k tomu, že běží na privátních sítích Google a dostupnost má 5 devítek, tak nás to tolik nemusí trápit. Když nebude dostupný Spanner, tak asi nebude dostupné i něco dalšího, takže naše služba stejně nepojede. Na Cloud Platform Blogu je tomuto tématu věnován samostatný článek. Vývojáři Spanneru se podívali do skutečného kódu volajícího Spanner a zjistili, že riziko možné nedostupnosti skoro nikdo neřeší.
- Prokládání řádků podřízené tabulky do řádků nadřazené tabulky. Takže pokud např. chceme získat album a všechny písničky, které na něm jsou, tak nemusíme sahat na dvě různá místa. Používá se k tomu klauzule INTERLEAVE IN PARENT. S touto optimalizací jsem se poprvé setkal u Akiban Technologies.
- Indexy podporují sestupné řazení. Také si do nich můžeme přímo uložit data, která budeme potřebovat. Používá se k tomu klauzule STORING.
- Pro primární klíče se typicky používá UUID. Jeho náhodnost data rovnoměrně rozhazuje na jednotlivé uzly.
- Databáze si vytváří snapshoty. Když dotaz položíme v čase T, tak nám všechny uzly vrátí stav, který na nich byl v tomto čase.
- Pro synchronizace uzly používají TrueTime. Ten je nejlépe popsán ve white paperu. Jestli to správně chápu, tak servery si udržují velmi přesný čas, u kterého zároveň znají maximální možnou odchylku od skutečného času. Pokud nějaká transakce začala až po uplynutí dvojnásobku maximální možné odchylky po konci mé transakce, tak mám jistotu, že začala až po mně (“during a commit, the leader may have to wait until it is sure the commit time is in the past (based on the error bounds).”).
- Cena je $0.90 za node na hodinu a $0.30 za GB na měsíc. Datové přenosy v rámci regionu jsou zdarma. Cena za GB mi přijde směšná, ale $648 za jeden node za měsíc mi přijde dost. Na druhou stranu je to srovnatelné s pronájmem lepších strojů v cloudu bez přidané služby (např. m4.4xlarge na EC2 stojí $0.862 na hodinu).
Diskuse
Kamil 
:
Pro zajímavost bych jen doplnil, že s prokládáním řádků jsem se setkal poprvé u Oracle 9i (2001), jmenuje se to Nested Tables: http://www.dba-oracle.com/art_9i_data_model.htm a se sestupnými indexy už ve verzi 8i (1998).
Kamil : Tomáš2:
v řadě věcí je srovnatelná s enterprise segmentem, za mě hlavní přínos je právě ta celosvětová stabilní síť, to je svatý grál pokud chci pokrýt větší oblast.Cena odpovídá zaměření, stačí se podívat na ceníky Oraclu, teradaty, netezzy, prostě to není nic, co si mohu pořídit na hraní, škoda.
Chybí mi tam nativní podpora šifrování už na klientu, nikde o tom nevidím informace. Hodila by se aspoň možnost si sám spravovat klíče pro šifrování a věřit googlu, že si je neschovává na horší časy.
Translace:
U takových databází ale nesmíte počítat s on-demand. AWS má například až 50pct slevy na dlouhodobé používání, což se dostává na relativně dobré ceny. Samozřejmě, proti dedikovanému serveru je to stále palba, ale to škálování za to občas prostě stojí. Navíc, sežeňte dneska rozumného admina který vám dá tu pohodlnost ve tvorbě nodů jako amazon nebo GCloudDiskuse je zrušena z důvodu spamu.
© 2005-2024 