И хороший мап редьюс

Ну и лично для меня - это скорость

И много разных ништячков:

Поиск случайных записей (одной или более)

Модификации записи при ее получении

+ посмотри модификатор графЛукап

+ репликация и шардирование с пол тыка

Ну и лично для меня - это скорость

юля с чего ты взял, что монга быстрее?

О.о

Я не Юля)))

Потому, что замеряли

это опечатка в стиле Юля Зуева? :)

Джойны есть, индексы есть частичные и полные.

О_O в монге можно связать несколько таблиц в запросе? Индексы нужны по выражениям.

О_O в монге можно связать несколько таблиц в запросе? Индексы нужны по выражениям.

Да можно.

Что значит по выражениям?

Потому, что замеряли

ссылочку пожалуйста на замеры.

О_O в монге можно связать несколько таблиц в запросе? Индексы нужны по выражениям.

И давно уже можно

ссылочку пожалуйста на замеры.

Я не публиковал. Мы сами замеряли для себя и все.

О_O в монге можно связать несколько таблиц в запросе? Индексы нужны по выражениям.

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/

А в 3.6 добавили ещё "сложные" условия при джойне

Что значит по выражениям?

https://postgrespro.ru/docs/postgrespro/10/indexes-expressional

С полной агригацией присоединяемой коллекции

https://postgrespro.ru/docs/postgrespro/10/indexes-expressional

Можно пример из жизни

Там тривиальные примеры, которые в Монго покрываются простыми индексами

Я не отрицаю, что это полезная вещь, но я пока не понимаю область ее применения

Я не отрицаю, что это полезная вещь, но я пока не понимаю область ее применения

ща доеду распишу наш кейс

https://postgrespro.ru/docs/postgrespro/10/indexes-expressional

В принципе понятно как оно устроено. Интересная штука.

Не проблема самому такое сделать, но когда оно поддерживается с коробки - это удобно

Я в монго для такого просто подготавливал данные и ложил в дополнительное поле

И фильтровал уже по этому полю

Да, так можно, но в нашем случае неудобно. У нас есть большая таблица по которой идет поиск на основе довольно специфических юзверьских запросов. мы собрали статистику по наиболее частым запросам и создали семь индексов на выражениях для ускорения этих запросов. И что очень порадовало, для этого не пришлось менять ни код приложения ни структуру БД. Просто добавили несколько хранимых процедур, считающих индексы и использовали их.

эдакая оптимизация БД не затрагивая разработчика апликухи вообще

Я не публиковал. Мы сами замеряли для себя и все.

Вот и возникают сомнения. Часто люди меряют неправильно вставки. Постгра по умолчанию настроена на ACID, а монга, ЕМНИП нет. Надо отключать WAL для таблицы и делать отложеные insert-ы, чтобы сравнивать в одинаковых условиях.

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/

А, это появилось в 3.2, мы к тому времени уже отказались от монги в новом проекте. в старом у нас задействована и монга и постгра

Вот и возникают сомнения. Часто люди меряют неправильно вставки. Постгра по умолчанию настроена на ACID, а монга, ЕМНИП нет. Надо отключать WAL для таблицы и делать отложеные insert-ы, чтобы сравнивать в одинаковых условиях.

Мы тестили все варианты в равных условиях

Мы тестили все варианты в равных условиях

Хз как вы тестили. В постгре много тонкостей, которые вы могли просто не знать. Вот например весьма интересный документ: https://www.percona.com/live/e17/sites/default/files/slides/High%20Performance%20JSON%20-%20PostgreSQL%20vs.%20MongoDB%20-%20FileId%20-%20115573.pdf

Из коробки постгра довольно тормозная. Но в любом случае мы отказались от монги не из-за скорости. Сильно не хватало транзакций. Вытащить что-то из таблицы сделать кое какие рассчеты и запихать обратно в рамках одной транзакции.

И как я уже говорил, я не хаю монгу, просто скорее всего у нас специфичный проект для которого постгра подошла лучше.

И как я уже говорил, я не хаю монгу, просто скорее всего у нас специфичный проект для которого постгра подошла лучше.

Возможно

Из коробки постгра довольно тормозная. Но в любом случае мы отказались от монги не из-за скорости. Сильно не хватало транзакций. Вытащить что-то из таблицы сделать кое какие рассчеты и запихать обратно в рамках одной транзакции.

Транзакций нет, это минус :(

Из коробки постгра довольно тормозная. Но в любом случае мы отказались от монги не из-за скорости. Сильно не хватало транзакций. Вытащить что-то из таблицы сделать кое какие рассчеты и запихать обратно в рамках одной транзакции.

Но изменить запись, как я уже говорил выше, можно и при его получении

Но правда только одну :(

Нельзя сразу несколько

Нельзя сразу несколько

атомарность это круто, но нам нужно посерьезнее. сделать несколько select а потом в зависимости от результатов обработки сделать несколько update

что за странная нестабильность в производительности монги в том документе, который я привел?

то она как ракета вставляет, а то падает до нуля записей в секунду!

Не наблюдается такого поведения

Стабильно 20-30К апдейтов и около 8К вставок в секунду

Ни и около 30-50К выборок

Все норм

не знаю, видимо у них тесты более тяжелые

Может диски?

постгра очень равномерно все делает, впрочем для нас тоже не аргумент

а как с хранимыми процедурами в монге?

про триггеры не спрашиваю, так как мы ими не пользуемся

Все круто! Их нет)))

Все круто! Их нет)))

печаль :)

Ну такое

Мы пришли к тому, что мы все выкинули

как вы их могли выкинуть если их нет? :)

И все на АПП уровне делаем

Из Постгре

У нас 2 СУБД

Основные БД Постгре

ясно

А монго для микросервисов

А свой проект какой пилишь?

ERROR: S client not available

а гуй какой-нибудь для монги используете?

для администрирования

Парни используют что-то, лично мне очень их консоль нравится

Парни используют что-то, лично мне очень их консоль нравится

консоль из гуя гораздо приятнее использовать :)

язык запросов в монге мне ломает мозг

))

А вот мне нравится)

Сейчас покажу пример

еще странный прикол. раньше работало {_id: 123456789} а потмо оп и перестало

Одного нашего запроса)))

еще странный прикол. раньше работало {_id: 123456789} а потмо оп и перестало

В смысле?

приходится писать {_id: NumberLong(123456789)}

[{"$match":{"time":{"$gt":1522829200}}},{"$group":{"_id":"$dataId","lastTime":{"$max":"$time"},"countLog":{"$sum":1}}},{"$lookup":{"from":"test_data","as":"test_data","let":{"dataId":"$_id","lastTime":"$lastTime","countLog":"$countLog"},"pipeline":[{"$match":{"$expr":{"$and":[{"$eq":["$$dataId","$_id"]},{"$lt":["$$countLog","$inDay"]},{"$gt":[{"$subtract":[1522915600,"$$lastTime"]},"$delay"]}]}}}]}},{"$unwind":"$test_data"},{"$replaceRoot":{"newRoot":"$test_data"}}]

приходится писать {_id: NumberLong(123456789)}

А, что число больше Инта ты имеешь ввиду)))

да, все эти $gt вместо > вымораживают

)))

А мне нравится)))

А, что число больше Инта ты имеешь ввиду)))

да, это long

А мне нравится)))

вы, батенька, извращенец :)

вы, батенька, извращенец :)

У каждого свой фетиш)))

Так какой свой проект пилишь?

хз, я не фапаю на SQL, но это однако совсем бида

Так какой свой проект пилишь?

В смысле какой? Хороший!

Ну какой замысел?

Что делает проект?

Это секретная информация. :)

но мы уходим с D на Elixir

Ааа)

Ты не сам?

Нет

Ясно

Но я могу сам принимать решения какие технологии применять