Правилно сте забелязали, че документите ще имат различен размер. Така ще спестите поне 15 bytes на документ (60% за подобни документи), ако решите да приемете втората схема. Това ще завърши в нещо като 140MB за вашите 10 million записи. Това ще ви даде следното предимство:
- Икономии на HDD. Единственият проблем е, че гледайки цените на текущия твърд диск, това е почти безполезно.
- Спестяване на RAM. В сравнение с твърдите дискове, това може да бъде полезно за индексиране. В mongodb работен набор от индекси трябва да се поберат в RAM, за да се постигне добро изпълнение
. Така че, ако ще имате индекси на тези две полета, не само ще спестите
140MBпространство на HDD, но също и140MBпотенциално RAM пространство (което всъщност се забелязва). - Вход/изход . Много тесни места се случват поради ограничението на системата за вход/изход (скоростта на четене/запис от диска е ограничена). За вашите документи това означава, че със схема 2 можете потенциално да четете/пишете
twice as many documentsза 1 секунда. - мрежа . В много ситуации мрежата е дори по-бавна от IO и ако вашият DB сървър е на различна машина, тогава вашият сървър за приложения данните трябва да се изпращат по кабела. Освен това ще можете да изпращате два пъти повече данни.
След като казах за предимствата, трябва да ви кажа един недостатък за малки клавиши:
- четимост на базата данни. Когато направите
db.coll.findOne()и вижда{_id: 1, t: 13423, a: 3, b:0.2}доста е трудно да се разбере какво точно се съхранява тук. - четимост на приложението подобно с базата данни, но поне тук можете да имате решение. С логика на картографиране, която трансформира
currentDateкъмcиpriceкъмpможете да напишете чист код и да имате кратка схема.
