Защо имената на ключовете се съхраняват в документа в MongodDB

Това, което имате предвид, често се нарича "компресия на ключ"*. Има няколко причини, поради които не е внедрен:

1. Ако искате да го направите, в момента можете да го направите на ниво Приложение/ORM/ODM доста лесно.
2. Това не е непременно предимство в производителността** във всички случаи — помислете за колекции с много имена на ключове и/или имена на ключове, които се различават значително между документите.
3. Възможно е изобщо да не осигури измеримо предимство на производителността**, докато нямате милиони документи.
4. Ако сървърът го направи, пълните имена на ключовете все още трябва да бъдат предадени по мрежата.
5. Ако компресирани имена на ключове се предават по мрежата, тогава четливостта наистина страда при използване на конзолата на javascript.
6. Компресирането на целия JSON документ може да предложи предлага още по-добро предимство в производителността.

Подобно на всички функции, има анализ на разходите и ползите за внедряването му и (поне досега) други функции предлагат по-голяма печалба за парите.

Пълното компресиране на документи [се обмисля] [1] за бъдеща версия на MongoDB. наличен от версия 3.0 (вижте по-долу)

* Справочна таблица в паметта за имена на ключове е основно специален случай на компресиране в стил LZW — горе-долу това правят повечето алгоритми за компресиране.

** Компресията осигурява както предимство в пространството, така и в производителността. По-малките документи означават, че повече документи могат да се четат на IO, което означава, че в система с фиксиран IO могат да се четат повече документи в секунда.

Актуализация

MongoDB версии 3.0 и по-нови вече имат пълна възможност за компресиране на документи с WiredTiger двигател за съхранение.

Налични са два алгоритъма за компресиране:snappy и zlib . Целта е snappy да бъде най-добрият избор за цялостна производителност, а zlib да бъде най-добрият избор за максимален капацитет за съхранение.

В моето лично (ненаучно, но свързано с търговски проект) експериментиране бързото компресиране (не оценихме zlib) предложи значително подобрена плътност на съхранение без забележими нетни разходи за производителност. Всъщност имаше малко по-добро представяне в някои случаи, приблизително в съответствие с предишните ми коментари/прогнози.