Нека да преминем към въпроса ви един по един:
Разглеждането на показатели за ефективност само от едно изпълнение наистина не работи. Трябва да вземете средната стойност за няколко изпълнения, преди да заключите, защото има няколко фактора. Като се има предвид това, MongoDB кешира най-често използваните документи в паметта и ги държи там, освен ако не трябва да предостави памет за друг документ. Така че, ако дадена заявка има достъп до вече кеширани документи от предишна заявка, тя трябва да бъде по-бърза.
Също така в MongoDB агрегирането използва индекси само в началото, ако има такива. Например $match и $sort фазите могат да използват индекси. Във вашия случай $match е първият етап на конвейер, така че това е победа.
В MongoDB данните се съхраняват в BSON , така че датите са основно числа когато се сравняват. Така че няма разлика.
Въпреки че не съм го тествал, наистина се съмнявам, че подходът time_bucket ще даде по-бърз отговор. Тъй като created_at винаги ще се увеличава, индексът в този случай също ще бъде добавен към края без time_bucket. Освен това размерът на индекса ще бъде сравнително огромен, когато е създаден върху масив, отколкото върху обикновено поле за дата. Това няма ли да причини проблем с поставянето на индекса в RAM.
Използването на time_bucket има смисъл, когато използвате някаква функция в полето за дата преди съвпадение. Ако извлечете само година от полето за дата преди съпоставяне, това ще направи съществуващия индекс на датата безполезен.
Винаги е по-добре да преобразувате параметрите си така, че да съответстват на типа данни в базата данни, вместо обратното.
Да, възможно е. Ако е $and , просто посочвате всичките си филтри, разделени със запетаи в $match фаза. Ако е $or използвайте $or
оператор.
Ако имате два $macth фази една по една MongoDB го комбинира в една
. Така че не е нужно да се притеснявате за добавяне на резултати от множество фази на съвпадение.
Сега вашата оптимизация Точки
Да, обхванати заявки са много по-бързи.
Ако размерът на документите е намален в $group етап чрез използване на $project , тогава да, вярно е.
Не е задължително да е вярно, но обикновено е така. Можете да проверите този отговор .
