Мне очень надо было. Я сделал запрос на count, потом плюсовал и писал.

Но если документы могут удалятся, етот вариант не подойдет

И данных у меня было немного, лишний запрос был не критический

так а зачем вам автоинкремент? какую задачу с его помощью хотите решить?

Это для юзеров, которые будут делать import, ObjectId не красивый идентификатор

тут трейдофф - красиво и геморно против функционально и безболезненно. в общем случае честные автоинкрент треубет создания отдельной коллекции с единственным документом и единственным полем currentId. Собственно использовать findAndModify с $inc для увеличения счетчика

коллекцию со счетчиками завести

там файн и апдейт метод есть

или модифи

коллекцию со счетчиками завести

коллекция счетчиков? это где таую абстракцию добавили?

не понял вопроса

я чтото не видел в монге коллеции счетчиков

это стандартное решение из документации

ссылочку если не затруднит

обычная коллекция с именем counters или на свое усмотренип где_id имя другой коллекции а counter поле которое будет инкрементировать при каждом обращении к нему

я тож самое написал что и у тебя в ответе просто не читал что ты писал

в ормках аутоинкремент так же реализуется

например в mongoengine

собственно как и ожидалось, ни по автоинкремент ни по сиквенсу в стандартной доке чтото не нашлось. так что не стоит вводить человека в зпблуждение чтобы он начал использовать какуюто коллекцию счетчиков. их нужно либо вручную реализовывать, либо искать что может одм

Мне очень надо было. Я сделал запрос на count, потом плюсовал и писал.

Это неверный способ.

Это для юзеров, которые будут делать import, ObjectId не красивый идентификатор

Красивость волнует только разработчиков и не является технической проблемой. Будет усложнением без причины

Коллекция со счетчиками является наиболее вменяемым решением этой проблемы. Но нужно учитывать что работать это будет только через update(inc: ). find в коллекцию будет только «примерным» последним номером и его можно использовать только в информационных целях

Но как следствие использование автоинкремента будет всегда требовать чтения и записи.

И надо понимать что гарантия будет только в том, что следующий номер будет больше предыдущего. На сколько больше: не известно. Получить непрерывное множество будет очень сложно

Ребят, какие есть best practise для совершения последовательно/одновременно нескольких запросов к монге на NodeJS? у меня получается пирамидка из callback'ов и это не есть гуд.

promise

для паралельного запуска несколько есть метод promise.all

подскажите пожалуйста бесплатное облако с монгой. несколько сот тысяч записей в сутки. небольших текстовых

облачный сервис нужен

бесплатный при нагрузках в таких пределах

ничего не понял. можете дать ссылку типа хероку или firebase

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

во другое дело

а скажите

если обычную табличную бд взять то там записываются только данные. ну например количество просмотров столбец и дальше просто числа

а тут он в каждой записи будет много лишнего записывать или что

просто скрипт пока в текст пишет. и выходит несколько сот мегабайт в месяц где-то

ну он пишет со всеми данными. типа число просмотров: 5. потом через час число просмотров: 9. и тд

а в таблице бы просто числа шли

а тут как? тоже забьется быстро?

ладно буду пробовать а там видно будет

Доброе утро. Скажите пожалуйста, по своему опыту, использовать MapReduce хорошо или плохо? Просто написал код, а опыта в монге нету. Меня сейчас обвиняют, что приложение из-за MapReduce подвешивает базу(без аргументов, просто типа это плохо), хотя на сколько я понимаю, MapReduce это отличный инструмент распределенного Stateless вычисления. К тому же выборки минимальные.

по ситуации же)

по ситуации же)

Можно конкретные примеры?

Так подвешивает или просто обвиняют?)

Так подвешивает или просто обвиняют?)

Причина окончательно не установлена, просто обвиняют mapreduce и просят от него избавиться. Хотя на клиенте считать я уверен будет медленнее. Поэтому и задал вопрос, неужели mapreduce имеет такую плохую репутацию? Или это просто наброс на вентилятор был? :)

всё зависит от того какие запросы в мапредьюсе же и на каких серверах это крутится, мб там всё из говна и палок собрано и адовые запросы. Ну надо тоже какую то конкретику

Если сами запросы мимо индексов, точно будет медленно. Остальное по ситуации.

было бы интересно посмотреть на пример, заодно можно попросить админов построить план запросов

и в чём вообще обвиняют? проц\рам\ио?

Помню кто-то ругал на какой-то конфе монговский map reduce, возможно ноги от туда. Но это не значит, что его нельзя юзать.

Причина окончательно не установлена, просто обвиняют mapreduce и просят от него избавиться. Хотя на клиенте считать я уверен будет медленнее. Поэтому и задал вопрос, неужели mapreduce имеет такую плохую репутацию? Или это просто наброс на вентилятор был? :)

Да, имеет

За ряд архитектурных особенностей

Если mr с out в коллекцию, то в шардированном кластере могут быть проблемы, особенно если они очень частые

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

как в монге сортируются по дефолту записи в коллекции, по _айди?

если я не ошибаюсь, по _id создается индекс по умолчанию.

если сделать запрос типа db.collection.find({}).sort({}) то сортировка произойдет по _id

как в монге сортируются по дефолту записи в коллекции, по _айди?

не сортируются, пока не укажите в явном виде. в общем случае все зависит от порядка документов в самом хранилище монги

просто я не могу понять, я добавляю 4 записи 1 и 2 на 1 и 4 поз соотв получаются

например

в хаотическом порядке как то

если нужен порядок - указывайте ключи сортирвоки по кторым нужен порядок

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

а не про вообще работу с монгой

не сортируются, пока не укажите в явном виде. в общем случае все зависит от порядка документов в самом хранилище монги

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

даже не в порядке записи, а в порядке хранения, как внутри менеджерится расположение доков одному WT известно

надо попробовать на практике поэкспериментировать

даже не в порядке записи, а в порядке хранения, как внутри менеджерится расположение доков одному WT известно

ну вот я и офигеваю

4 подряд записи 1 3 4 2

4 подряд записи 1 3 4 2

зачем вам это нужно?

какую задачу хотите решить

возвращать самое новое сообщение

по дате, такое, не очень варик вроде

добавляйте поле со временем и берите максимальное

оно есть)

хотя

просто таймстемп в секундах юниксовый

спасибо

это критичная часть чтобы получать реально самое новое? т.е. допустимо ли просто взять предыдущее или там перепутать изза коллизии во времени?

ну хотят что бы самое новое было в самом верху

на странице

опредлитесь с критерием "самое новое", добавьте необходимую информацию в виде поля в документ и сортируйте по нему. Если данных много, то добавьте индекс

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

товарищи, а обратный индекс по _id не проще?

если таймстэмпы не нужны отдельно

ObjectId же и так содержит дату

опредлитесь с критерием "самое новое", добавьте необходимую информацию в виде поля в документ и сортируйте по нему. Если данных много, то добавьте индекс

вроде работает, сделал юниксовый таймстепм, при отправки с сервера сортирую .sort()

использовать _id для этого - костыль, который аукнется рано или поздно если проект будет хоть както развиваться. в общем случае почти всегда при необходимость показывать самый новый возникнет необходимость показать с по, а это уже на _id делается через еще большие костыли