докер у меня в ранчере нормаль бегал

@dd_bb а settings yml также через переменную передавать ?

ага, точно так-же работает

-p можно в args а настройку пути в env

сенкс

походу я все таки криворук))

делаю MONGO_EXPORT_CONF=/opt/settings.yml

стартую контейнер docker run -it —name mongo-exp -p 8080:8080 yopp/mongo_collection_exporter

и все равно он пытается не туда

Topology type 'single' initializing. D, [2017-05-04T11:34:38.876161 #5] DEBUG — : MONGODB | Server localhost:27171 initializing. D, [2017-05-04T11:34:38.884595 #5] DEBUG — : MONGODB | Address already in use - connect(2) - Connection refused

делаю MONGO_EXPORT_CONF=/opt/settings.yml

ну ещё бы :) docker run -it --name mongo-exp -e MONGO_EXPORT_CONF=/opt/settings.yml -p 8080:8080 yopp/mongo_collection_exporter

а шайтан))

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

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

Реплику в shards засунь, остальное заккоментируй

В смысле все ноды из реплики

Dmitry Semenyk, [07.05.17 13:11] пожалуйста подскажите в чем проблема) вообще не понял что происходит...... Dmitry Semenyk, [07.05.17 13:11] MongoDB shell version v3.4.3 connecting to: mongodb://127.0.0.1:27017 2017-05-07T13:07:49.267+0300 W NETWORK [thread1] Failed to connect to 127.0.0.1:27017, in(checking socket for error after poll), reason: Connection refused 2017-05-07T13:07:49.267+0300 E QUERY [thread1] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed : connect@src/mongo/shell/mongo.js:237:13 Dmitry Semenyk, [07.05.17 13:12] #mongod до этого спокойно запускал.....а сейчас проблема вылезла) не могу понять в чем дело( Dmitry Semenyk, [07.05.17 13:12] 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] MongoDB starting : pid=2683 port=27017 dbpath=/data/db 64-bit host=samuil 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] db version v3.4.3 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] git version: f07437fb5a6cca07c10bafa78365456eb1d6d5e1 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] allocator: tcmalloc 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] modules: none 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] build environment: 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] distmod: ubuntu1604 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] distarch: x86_64 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] target_arch: x86_64 2017-05-07T13:08:03.529+0300 I CONTROL [initandlisten] options: {} 2017-05-07T13:08:03.536+0300 I STORAGE [initandlisten] exception in initAndListen: 29 Data directory /data/db not found., terminating 2017-05-07T13:08:03.536+0300 I NETWORK [initandlisten] shutdown: going to close listening sockets... 2017-05-07T13:08:03.536+0300 I NETWORK [initandlisten] shutdown: going to flush diaglog... 2017-05-07T13:08:03.536+0300 I CONTROL [initandlisten] now exiting 2017-05-07T13:08:03.536+0300 I CONTROL [initandlisten] shutting down with code:100

Привет. Есть лям документов. В них постоянно обновляются данные. Надо сортировку по 6 из 10 полям по отдельности. Индексы, как я понял, расставлять в таком количестве плохо. Есть какой-то подход к решению данной проблемы?

Почему плохо?

Лям документов это гиг данных по килобайту. Индекс будет ну пусть 10% от размера документов. Если все десть индексов ну ещё гиг от силы. Может начать тупить вставка немного

Привет. Есть лям документов. В них постоянно обновляются данные. Надо сортировку по 6 из 10 полям по отдельности. Индексы, как я понял, расставлять в таком количестве плохо. Есть какой-то подход к решению данной проблемы?

Постоянно обновляется..., 6 из 10 сорт.. Помоему эту задачу нужно решать в inmemory на сервере а не в базе

Привет. Начал разбираться с mongodb и вот тут встал вопрос, а можно ли как то выбрать в одном запросе, все коллекции, с вложенными объектами?

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

А почему бы сразу не хранить с вложенными объектами а не ссылки

ну там же будет храниться много не нужной для этого сообщения информации о пользователе

Я так понял что сильная сторона документоориент БД и MongoDB в частности в том что бы хранить всё целиком, в готовом виде, возможно с избыточностью, но не напирать на связи, т.к. быстрее достать всё сразу с лишними полями, чем бегать по связям и собирать документ. Для связей есть SQL базы данных

ну там же будет храниться много не нужной для этого сообщения информации о пользователе

Вы используете MongoDB как SQL-базу. Не надо так

Вы используете MongoDB как SQL-базу. Не надо так

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

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

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

ну вот я про тоже, и хотел узнать, можно ли выбрать так чтобы еще некоторые поля пользователя попали в это сообщение

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

Включить необходимые поля из юзера, вместо ссылки на юзера. Для NoSQL баз нужна инная архитектура данных чем дял SQL

Включить необходимые поля из юзера, вместо ссылки на юзера. Для NoSQL баз нужна инная архитектура данных чем дял SQL

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

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

Представь что никак, и тогда сделаешь верную архитектуру.

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

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

Представь что никак, и тогда сделаешь верную архитектуру.

В этой истории два стула, насколько я понимаю: 1. Вложенные доки с быстрым чтением и избыточностью 2. Долгое чтение с агрегацией и без избыточности Но правильно тут не сделаешь ведь? Или я не прав?

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

Немного не по теме, но всё же. Зачем так подключать mongoose? Почему он у вас не в папке node_modules?

Немного не по теме, но всё же. Зачем так подключать mongoose? Почему он у вас не в папке node_modules?

одно подключение

А, понял

В этой истории два стула, насколько я понимаю: 1. Вложенные доки с быстрым чтением и избыточностью 2. Долгое чтение с агрегацией и без избыточности Но правильно тут не сделаешь ведь? Или я не прав?

всетаки интересно былобы услышать как правильно реализовать в данной ситуации

всетаки интересно былобы услышать как правильно реализовать в данной ситуации

Мне тоже интересно

как называется цветовая схема? :)

В этой истории два стула, насколько я понимаю: 1. Вложенные доки с быстрым чтением и избыточностью 2. Долгое чтение с агрегацией и без избыточности Но правильно тут не сделаешь ведь? Или я не прав?

А зачем в 1 доставить сразу все поля? Или обсуждаемый orm только так умеет?

как называется цветовая схема? :)

плагин Material Theme UI https://github.com/equinusocio/material-theme

эм... а вот под Idea бы...

Офтоп. Ребята, я создал приложение для плэймаркет, которое поможет МонгоДБшникам изучить инглиш.. Пишите в личку. Скину ссылку.

Офтоп. Ребята, я создал приложение для плэймаркет, которое поможет МонгоДБшникам изучить инглиш.. Пишите в личку. Скину ссылку.

Зачем учить иншлиш, если они все слова из Си взяли?

эм... а вот под Idea бы...

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

Если вы начинаете хранить в монге реляционные данные, то где-то в выборе базы вы свернули не туда

Если вы начинаете хранить в монге реляционные данные, то где-то в выборе базы вы свернули не туда

вот и хочется познать все прелести mongo и понять как делается тут правильней

да продлит Йогг-Сотот твои дни, добрый человек :)

Если вы начинаете хранить в монге реляционные данные, то где-то в выборе базы вы свернули не туда

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

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

Это нормально в такой ситуации взять SQL.

Потому что как только понадобится строить более сложные запросы - начнётся ад.

Это нормально в такой ситуации взять SQL.

ну с чего то же нужно начинать

увидел подобный чат, тоже человек использует объект юзера а не ссылку https://github.com/raineroviir/react-redux-socketio-chat/blob/master/src/server/models/Message.js#L9

Что делать будешь, когда пользователя надо будет апдейтнуть?

Что делать будешь, когда пользователя надо будет апдейтнуть?

ахаха, вот хз

увидел подобный чат, тоже человек использует объект юзера а не ссылку https://github.com/raineroviir/react-redux-socketio-chat/blob/master/src/server/models/Message.js#L9

Смотря что в этом объекте будет лежать. Пароль и адрес email там явно хранить не стоит. Как и любые данные, которые пользователь сможет поменять.

Смотря что в этом объекте будет лежать. Пароль и адрес email там явно хранить не стоит. Как и любые данные, которые пользователь сможет поменять.

фото и username допустим, но фото он может поменять

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

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

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

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

И скорее всего запрос придётся писать вручную через aggregation framework.

(но это от orm зависит)

фото и username допустим, но фото он может поменять

Зачем хранить фото в базе?

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

Эффективную архитектуру можно предложить только зная подробности про задачу, и что нужно скорость или локаничность (простота), и др требования Почему вы выбрали MongoDB для своего проекта ?

Зачем хранить фото в базе?

ссылка на фото

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

Просто возьмите обычную SQL-базу

Эффективную архитектуру можно предложить только зная подробности про задачу, и что нужно скорость или локаничность (простота), и др требования Почему вы выбрали MongoDB для своего проекта ?

быстродействие

быстродействие

А монго почему выбрали ?

задача организовать чат, авторизация - регистрация - сокеты - пользователи - скорость и тд. Почему mongo? во первых знакомлюсь, и сколько не встречал, подобные задачи на монго реализованы

на чём сервер написан ?

node

Советую почитать про монго про её сильные и слабые стороны, изучить потестить операции. И написать чат используя приемущества монги

Тогда всё будет круто ! )

спасибо, именно на этом этапе я сейчас) знаю что будет весело, но уверен оно того стоит

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