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

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

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

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

эм... а вот под 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

возможно заюзать Capped collection для сообщений, если не нада архивировать очень старую историю

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

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

А вообще Фото меняется реже чем запрашиваются сообщения - выгоднее обновлять везде фото, чем делать ссылкой

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

- фича твоего чата ! Это сильно)

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

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

спасибо

Привет, а можно ли sql таблицу перевести в json и запушить в mongo?

Можно. А зачем?

Можно что угодно перевести в JSON и запушить в MongoDB.

Можно. А зачем?

нужна таблица готовых данных которая есть только в sql формате

Доброго всем. Подскажите пожалуйста, можно ли вытащить с коллекции документы фильтра {type: "type1}, {type: "type2} и для каждого типа ограниченный лимит, допустим каждого типа по 20 документов. Можно ли сделать так в одном запросе? Промиссы? Отдельные роуты для каждого типа?

Доброго всем. Подскажите пожалуйста, можно ли вытащить с коллекции документы фильтра {type: "type1}, {type: "type2} и для каждого типа ограниченный лимит, допустим каждого типа по 20 документов. Можно ли сделать так в одном запросе? Промиссы? Отдельные роуты для каждого типа?

пришел сюда спросить то же самое %) в моем случае прокатило бы что-т вроде db.objects.aggregate({ "$group": { "_id": "$parent.id", "objects" : {"$slice": [{"$push": "$$ROOT"}, 20]} } })

Доброго всем. Подскажите пожалуйста, можно ли вытащить с коллекции документы фильтра {type: "type1}, {type: "type2} и для каждого типа ограниченный лимит, допустим каждого типа по 20 документов. Можно ли сделать так в одном запросе? Промиссы? Отдельные роуты для каждого типа?

Только агрегацией. Но толку от этого в целом мало. Лучше несколько запросов.

о, йопп! привет! а если надо убедиться, что type лишь уникальные? к примеру db.coll.find({}).limit(5) возвращает пять документов [{group_id: 4}, {group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}] _id я опустил для упрощения. а хочется чтобы хуяк distinct/unique по полю group_id и вернуло либо [{group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}] (что не совсем круто, т.к. стоял лимит 5, и хотелось бы получить 5) либо [{group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}, {group_id: 10}]

Доброго всем. Подскажите пожалуйста, можно ли вытащить с коллекции документы фильтра {type: "type1}, {type: "type2} и для каждого типа ограниченный лимит, допустим каждого типа по 20 документов. Можно ли сделать так в одном запросе? Промиссы? Отдельные роуты для каждого типа?

Ну и да, на будущее — ваши драйвера никому не интересны. Промисы-шмомисы и прочее специфичное к языку барахло это в чят по языку.

о, йопп! привет! а если надо убедиться, что type лишь уникальные? к примеру db.coll.find({}).limit(5) возвращает пять документов [{group_id: 4}, {group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}] _id я опустил для упрощения. а хочется чтобы хуяк distinct/unique по полю group_id и вернуло либо [{group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}] (что не совсем круто, т.к. стоял лимит 5, и хотелось бы получить 5) либо [{group_id: 4}, {group_id: 2}, {group_id: 1}, {group_id: 8}, {group_id: 10}]

Привет. Какую проблему ты пытаешься этим решить?

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

записей всего сколько?

сейчас - 3000. может быть раз в 10-50 больше. distinct('group_id') - сейчас 200. может быть тоже раз в 10 больше.

я правильно понимаю что у тебя есть коллекция, в которой есть аттрибут group_id. Тебе нужно выбрать 5 объектов с уникальным group_id?

да! сорри, что хреново сформулировал

по group_id индекс есть?

но вообще на 3к докуметов я бы не запаривался и делал бы как быстрее и понятнее

сделаем если что :) правда, удручает еще, что на проде монга 2.6.7 и обновляться не хотят

быстрее в смысле «быстрее реализуется»

на 3 тыщах докуметов вообще по барабану :)

ок, а 50 тыщ тоже пофигу? объекты небольшие, килобайт наверное плейнтекстом если

хотя я в любом случае планировал выбирать, скажем, limit(5*2) и фильтровать дальше на бекенде потом

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

писят тыщ килобайт это целых 48 мегабайт

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

но идея с 5*2 более простая, да

я бы её выбрал :)

спасибо огромное :)

пришел сюда спросить то же самое %) в моем случае прокатило бы что-т вроде db.objects.aggregate({ "$group": { "_id": "$parent.id", "objects" : {"$slice": [{"$push": "$$ROOT"}, 20]} } })

спасибо

Только агрегацией. Но толку от этого в целом мало. Лучше несколько запросов.

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

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

курсор? я решал еще подобное пакетной обработкой

то есть с использованием skip() и limit()

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

а через skip как?

Добрый день, подскажите пожалуйста, я новичок в mongodb, хочу написать приложение на связки express + mongodb, раньше писал на ruby, python немного на go, использовал postgres либо mysql, можете сказать пожалуйста какие есть ограничения у mongodb, в плане, на сколько она лучше/хуже postgres'а либо mysql, можно ли делать какой-то большой сервис целиком на связки mongo и express ?

Добрый день, подскажите пожалуйста, я новичок в mongodb, хочу написать приложение на связки express + mongodb, раньше писал на ruby, python немного на go, использовал postgres либо mysql, можете сказать пожалуйста какие есть ограничения у mongodb, в плане, на сколько она лучше/хуже postgres'а либо mysql, можно ли делать какой-то большой сервис целиком на связки mongo и express ?

Сильно зависит от характера сервиса

Подобный medbooking.com

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

Подобный medbooking.com

А почему решил на монге делать?

Очень много слышу про популярный стек MEAN, захотел изучить его, ну и как я понял mongo и express тесно дружат

Попробуй

Подобный medbooking.com

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

Спасибо)

Я использую монго в игровом сервере, мне нравится возможность хранить структурированые иерарх данные, т.е объекты перегоняю в json напрямую. Отсутствие схемы, гибко можно добавлять удалять поля(но осторожно)

Скорость довольно высокая

Удобно хранить разреженные данные(это в другом проекте, где система собирала статистику на покер игроков для системы принятия решени0й для бота)

Нравится gridFS, и не нада париться с sql blob