Proč jsou názvy klíčů uloženy v dokumentu v MongodDB

To, o čem mluvíte, se často nazývá „komprese klíče“*. Existuje několik důvodů, proč nebyla implementována:

1. Pokud to chcete udělat, můžete to v současnosti udělat na úrovni Aplikace/ORM/ODM poměrně snadno.
2. Není to nutně výkonnostní** výhoda ve všech případech – představte si kolekce se spoustou názvů klíčů a/nebo názvů klíčů, které se mezi dokumenty velmi liší.
3. Dokud nebudete mít miliony dokumentů, nemusí to vůbec poskytnout měřitelnou výkonnost** výhodu.
4. Pokud to server udělá, musí se přes síť přenést celá jména klíčů.
5. Pokud jsou komprimované názvy klíčů přenášeny po síti, pak je čitelnost skutečně trpí používáním javascriptové konzole.
6. Komprimace celého dokumentu JSON může nabídnout nabízí ještě lepší výkonnostní výhodu.

Stejně jako u všech funkcí existuje analýza nákladů a přínosů pro její implementaci a (alespoň zatím) další funkce nabídly více „za peníze“.

Úplná komprese dokumentu je [zvažuje se][1] pro budoucí verzi MongoDB. k dispozici od verze 3.0 (viz níže)

* Vyhledávací tabulka pro názvy klíčů v paměti je v podstatě speciální případ komprese ve stylu LZW – to je víceméně to, co většina kompresních algoritmů dělá.

** Komprese poskytuje prostorovou i výkonnostní výhodu. Menší dokumenty znamenají, že na IO lze číst více dokumentů, což znamená, že v systému s pevnou IO lze číst více dokumentů za sekundu.

Aktualizovat

MongoDB verze 3.0 a vyšší nyní mají plnou schopnost komprese dokumentů pomocí WiredTiger úložiště.

K dispozici jsou dva kompresní algoritmy:snappy a zlib . Záměrem je, aby snappy byl nejlepší volbou pro všestranný výkon a aby zlib byl nejlepší volbou pro maximální kapacitu úložiště.

V mém osobním (nevědeckém, ale souvisejícím s komerčním projektem) experimentování, snappy komprese (nehodnotili jsme zlib) nabízela výrazně lepší hustotu úložiště bez znatelných čistých nákladů na výkon. Ve skutečnosti byl v některých případech mírně lepší výkon, zhruba v souladu s mými předchozími komentáři/předpověďmi.