Коллэги, подскажите как решить проблему когда после вставки документа в базе findOne() его не находит? Используется meteor (node.js) и кластер из 6 шардов, w=majority проблему не решил

Поможет ли передача параметра MONGO_OPLOG при запуске приложения?

Я молчу :)

Я молчу :)

Стесняетесь????

нет, просто он троль

Ну, значит читает не оттуда куда записал. Насколько я понимаю, это не проблема с find и пропуском при записи

Писать на всё или не надеяться, что оно мгновенно появится

Писать на всё или не надеяться, что оно мгновенно появится

Спасибо

Ребят. А можно вопрос немного не по теме, но все же по теме. Очень нужна помощь двум джунам по этому поводу. Есть база приложения на mssql и винде. Нужен хороший способ экспорта этой базы в базу postgreSql на никсах. У приложения есть драйвер для postgre и mssql(web app на tomcat) Официально postgre недоступна, но мы завели(через конфиги и скрытый функционал) и она сама создает таблички. В mssql приложение создает таблички в формате [Resto].[dbo].[DbVersion] Ее аналог в postgre [resto].[dbversion] Собственно возникает вопрос как это автоматизировать. Мы перенесли одну табличку руками в CSV(по сути все основные сущности в ней), приложение завелось. Только вот таблиц 127, и перенести нужно все. Буду рад любым советам, ибо гугл советует в основном утилиты, которые нам не подходят.

https://telegram.me/pgsql наверное профильнее

блять. слон в ушанке, они там стекломоя обпились? врочем, чего ожидать

Один либерал пригорел в этом чате

как там Чебурашка, гимн поёшь при авторизации?

гайз

есть вопрос

допустим есть коллекция документов с тучей полей

и есть одно поле которое есть во всех документах в этой коллекции

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

типа select field, count(*) from my_collection group by field ?

с помощью мапредьюс я получил это

а если я хочу по нескольким полям сделать такое, мапредьюс тут не товарищ?

а если я хочу по нескольким полям сделать такое, мапредьюс тут не товарищ?

Почему же?

Надо с объектами работать

а если я хочу по нескольким полям сделать такое, мапредьюс тут не товарищ?

m/r в принципе не товарищ

пользуйте aggregation framework

{ $group: { _id: "$myfield", myfield_sum: { $sum: 1 } } }

m/r в принципе не товарищ

Lol

Lol

ты лол

пользуйте aggregation framework

Вот когда у вас память кончится... Свапить в фс не предлагать

Ну и rereduce

В данном случае, AF к месту

Вот когда у вас память кончится... Свапить в фс не предлагать

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

Но, mr - незаменимый инструмент во многих случаях

заменимый

заменимый

Кроме случаев, когда незаменимый

10gen настоятельно рекомендуют не использовать m/r

10gen настоятельно рекомендуют не использовать m/r

Пруф или gfo

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

Я видел только заявление, что mr никуда не уйдет, а AF - просто другой инструмент

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

м

походу переписка осталась в старой рабочей почте, щас в другом месте ещё посмотрю

https://jira.mongodb.org/browse/DOCS-7843

ой

нет, не то

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

Да покажи где?

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

Без MR я из этого веселья вообще выпилюсь...

Да покажи где?

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

и несколько раз просили переехать на AF

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

Не осилили, поэтому пилят новое, это да

Но пока все мои кейсы с MR было с rereduce, который никак не заменяется с AF

Да, короче переписка канула в лету вместе с рабочей почтой. Пруфов у меня, увы нет так что gfo. ¯\_(ツ)_/¯

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

а то тут хотят использовать 2.4.10 и чет я не уверен что это хорошо

или я не прав ?

а то тут хотят использовать 2.4.10 и чет я не уверен что это хорошо

Ммм, да они бравые камикадзе

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

последняя стабильная!

3.2 ?

3.2.10 as for today

спасибо

с 2.4 у меня был опыт общения, негативный =)

Но пока все мои кейсы с MR было с rereduce, который никак не заменяется с AF

А чо вы с rereduce делаете?

и какие у вас объёмы?

потому что на малюсеньком шарде с парой сотен миллиардов записей мапредьюс это такое очень щекочущее очко развлечение

Да, короче переписка канула в лету вместе с рабочей почтой. Пруфов у меня, увы нет так что gfo. ¯\_(ツ)_/¯

Ну, надо спросить в девелоперской рассылке будет...

потому что на малюсеньком шарде с парой сотен миллиардов записей мапредьюс это такое очень щекочущее очко развлечение

Я помню это обсуждение здесь же

У нас отчеты достраивались

Т.е. есть актуальная версия доьавлялась в последнюю до этого через rereduce. В итоге map работал очень быстро, только по последним данным

А много данных было? Шарженные?

А много данных было? Шарженные?

не шарженные, 4 терабайта в старой реплике master-slave, но из-за правильных индексов и допихивания данных в отчеты, спокойно жило на 32 гигах оперативы

А, ну понятно.

да, если кто-то пытался посмотреть старые данные отчета, могло на пол секунды протупить

А индексов сколько было на 4Тб?

Вы subdocuments юзали?

8-10 гигов индексов было

Ого

Нормально ваще

там много отчетов;)

10 гигов индексов на 4тб данных это копейки ваще

ну, потому что отчеты без индексов

только по _id

и _id хорошо локализовывал отчёт?

угу