Тюнинг запросов это естественно нужно, opsManager не плохо помогает мониторить. Но проблема в том что упираешься в сопротивление монги, ну не можешь ты решить проблему, даже изменив сам запрос. Ну вот хоть тресни. Приходится менять коллекции... А это импакт по производительности и иногда очень затратно по времени. Главный бич монги это поддержка индексов и массивов.
писать на орм и не учить эти ваши старые сложны sql
SQL в разы легче, больше инструментов, оптимизаторы которые десятилетия допиливыли. Простой синтекс, поддержка индексов везде. Но в sql есть проблема, это описание структуры данных, когда ты не знаешь что у тебя будет ещё добавлено в систему, какие будут требования. У сильно изменяемой системы. Вот тут решение nosql...
В Монге очень плохой оптимизатор, при сложном логическом запросе с И и ИЛИ он использует не тот индекс, если указать его хинтом то он его использует, но подставляет не все поля. Даже с учётом правильного порядка полей в индексе, и одинаково начала у составных индексов, что-то идёт не так :) хотя бороться можно.
После Lookup индексы не работают, то есть если тебе нужна пост сортировка или фильтр, монга будет грузить в память коллекции а не индексы. Если таких запросов много то...
Если есть один массив в коллекции, то жить впринципе можно, допустим с проверкой ACL, но в $text поиск нельзя добавить массив для фильтрации индекс. Так как текстовое поле представляет собой индекс, и место массива в текстовом индексе уже занято по дефолту, а два массива в индексе нельзя.
Ну а если в коллекции нужно делать фильтр по двум массивам, вот тут начинается самое главное :)
Шардинг тоже имеет тучу нюансов к lookup и индексам.
Хорошие моменты тоже есть, разработки на с#, мапинг, дескриминатор, это всё круто и удобно, codeFirst, просто класс, в базу даже не нужно заглядывать создавать какие-то там типы, строго типизировать коллекции, но если нужен поиск и фильтрация что-то тяжелее чем по id_, filed1 && filed2, и есть массив вот тут приходит крах производительности.
Тюнинг запросов это естественно нужно, opsManager не плохо помогает мониторить. Но проблема в том что упираешься в сопротивление монги, ну не можешь ты решить проблему, даже изменив сам запрос. Ну вот хоть тресни. Приходится менять коллекции... А это импакт по производительности и иногда очень затратно по времени. Главный бич монги это поддержка индексов и массивов.
SQL в разы легче, больше инструментов, оптимизаторы которые десятилетия допиливыли. Простой синтекс, поддержка индексов везде. Но в sql есть проблема, это описание структуры данных, когда ты не знаешь что у тебя будет ещё добавлено в систему, какие будут требования. У сильно изменяемой системы. Вот тут решение nosql...
В Монге очень плохой оптимизатор, при сложном логическом запросе с И и ИЛИ он использует не тот индекс, если указать его хинтом то он его использует, но подставляет не все поля. Даже с учётом правильного порядка полей в индексе, и одинаково начала у составных индексов, что-то идёт не так :) хотя бороться можно.
После Lookup индексы не работают, то есть если тебе нужна пост сортировка или фильтр, монга будет грузить в память коллекции а не индексы. Если таких запросов много то...
Если есть один массив в коллекции, то жить впринципе можно, допустим с проверкой ACL, но в $text поиск нельзя добавить массив для фильтрации индекс. Так как текстовое поле представляет собой индекс, и место массива в текстовом индексе уже занято по дефолту, а два массива в индексе нельзя.
Ну а если в коллекции нужно делать фильтр по двум массивам, вот тут начинается самое главное :)
Шардинг тоже имеет тучу нюансов к lookup и индексам.
Хорошие моменты тоже есть, разработки на с#, мапинг, дескриминатор, это всё круто и удобно, codeFirst, просто класс, в базу даже не нужно заглядывать создавать какие-то там типы, строго типизировать коллекции, но если нужен поиск и фильтрация что-то тяжелее чем по id_, filed1 && filed2, и есть массив вот тут приходит крах производительности.