Ответы пользователя по тегу MongoDB
  • Переход на mongoDB?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Раньше использовал mysql, и до сих пор все нравилось, как не понадобилась иерархическая структура.


    Казалось бы, причем тут mongodb. Мускуль json умеет (хоть и не так удобно), и подозреваю что речь все же идет о графах. В этом случае стоит графовую БД брать (Neo4j например).

    Словом уточните свою задачу.

    А вот как их получать?! Не смог найти свойства и метода.


    Читаем документацию.
    Ответ написан
  • Какая суть команды .replaceOne в MongoDB?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    https://docs.mongodb.com/manual/reference/method/d...

    в английском плоховато смыслю


    google translate:


    replaceOne () заменяет первую найденную документ в коллекции, которая соответствует фильтру, с помощью замены документа.

    Если upsert: истинна и никаких документов соответствуют фильтру, replaceOne () создает новый документ, основанный на замене документа. См Заменить Upsert.
    Ответ написан
  • NodeJS + socket.io + mongoDB. Где утечка памяти?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    вызов GC вручную


    И как это могло бы помочь интересно.

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


    если там есть внутри буфер сообщений на отправку - то вполне может просто не успевать отправлять сообщеньки.
    Ответ написан
  • Выбор субд large data?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    индексы вы расставляли? explain запросов делали? Что-то мне кажется что нет.

    Для вашей задачи хватит и mysql + подтюнить. В целом же можно еще хранить агрегации готовые вместо того что бы на каждый чих по новой их делать.
    Ответ написан
  • Стоит ли использовать MongDB вместо PostgreSQL?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Не совсем. Слишком велики концептуальные различия.

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


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

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

    Стоит ли мне использовать MongoDB или все же старый добрый PostgreSQL со связями?


    Есть еще вариант. С версии 9.4 postgresql тоже умеет jsonb, хоть и не так удобно.
    Ответ написан
  • Какие есть хорошие книги по mean.js?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Может хватит использовать mongodb как основное хранилище? Это весьма скверная затея.

    В целом же рекомендую вам так же перестать пытаться мыслить стэком технологий как единым целым. учим все по отдельности.

    сначала изучаем javascript (я как-то подозреваю что вы его не особо знаете)
    - потом... углубляемся в javascript
    - потом учим express.js, попутно постигая тайный смысл аббривиатуры SOLID, изучая ООП, немного функциональщины полезно будет ну и все такое.
    - потом учим angularjs (можно express.js и angularjs поменять местами в принципе, это не столь важно).
    - Ну и еще неплохо изучить базы данных (SQL). Причем монгу оставьте на потом, эта штука клево себя ведет как основное хранилище данных только для записи логов, и в редких случаях, когда вам реально нужна документо-ориентированность (очень редкий кейс). Ну и для ускорения выборок из реляционных баз данных за счет хранения аггрегаций, но для этого должна быть необходимость (много джойнов в выборках например, очень сложные запросы, тогда монгу можно использовать как кэш первого уровня для хранения денормализованной копии данных для упрощения этих сложных выборок).
    Ответ написан
  • Как вытащить значение переменной из вложенного await вызова async функции в ES7?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    я не 100% не уверен но... из того что вы написали:

    returns Promise if no callback passed


    вам надо убрать колбэк. По поводу обработки ошибок из спецификации async-functions мы должны переписать функцию так:

    async userExistsInDB(email) {
        let userExists; 
        try {
             const db = await MongoClient.connect('mongodb://127.0.0.1:27017/notificator');
        } catch (err) {
             throw err; // тут у вас никакой обработки ошибок небыло... можно и без try/catch тогда
        }
    
        const collection = db.collection('users');
        userExists = await collection.find({email: email}).limit(1).count() > 0;
        console.log("INSIDE:\n", userExists);
        db.close();
        
        console.log("OUTSIDE:\n", userExists);
        return userExists;
    }


    код в дальнейшем можно еще упростить. Суть в том что при использовании await нет смысла в колбэках. Все происходит синхронно (с точки зрения потока управления, блокировок конечно же не будет).
    Ответ написан
  • Вопросы по быстродействию + Какую базу лучше всего использовать?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    все зависит от того что вы с этими данными делать будете. Если просто хранить - то выдержит конечно. Если делать сложные выборки - то зависит от нагрузки и количества запросов а так же расставили вы индексы или нет ну и все такое. Ну и для такой выборки памяти под индексы надо прилично и тюнить настройки mysql.

    Если вас интересует как ускорить запись - можно сначала загонять все в буфер (redis например) и потом пачками заносить все в базу.

    Если интересует как ускорить чтение - кеширование, индексы, агрегация штуками типа elasticsearch. Но опять же только если у вас есть проблемы с производительностью. Не занимайтесь преждевременной оптимизацией. Сначала напишите нагрузочные тесты и посмотрите насколько все плохо и надо ли что-то делать.
    Ответ написан
  • Как спроектировать связи в MongoDB?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Решил БД карточной игры перевести на MongoDB

    Зачем? Если у вас есть хотя бы 10% вероятность того что между записями появятся отношения/связи, то монга вам не подходит.

    Монгу стоит использовать исключительно для хранения денормализованных данных. То есть обычно все хранят в реляционной базе и потом делают агрегации данных в денормализованном виде что бы ускорить выборки. В этом случае у нас может быть одна база данных в нормализованном виде (mysq/postgres/etc) и много инстансов монги из которой данные только читаются, но ничего не пишется (кроме как агрегации инициированные изменением данных в реляционной бд.

    И то это нужно только если у вас возникают проблемы с реляционной базой (много джойнов например приходится делать в случае сложных выборок). Если у вас один-два джойна то расставить индексы и не париться.

    p.s. говорит человек который не понаслышке знает о том, насколько плохо живется если на проекте монга была выбранна основным хранилищем данных при наличии связей между ними.
    Ответ написан
  • Как организовать хранение данных в БД?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    1) я бы помимо ID хранил еще порядковый номер, который бы четко задавал последовательность изображений. В таком случае мы можем хранить рэйнджи не просмотренных изображений. Ну и так как у нас может быть произведен переход только к соседнему изображению - это легко устроить.

    2) без разницы. Лучше по дефолту брать sql и nosql для кеширования и агрегации данных в случае необходимости.
    Ответ написан
  • Стоит ли переходить на MongoDB для блога (PHP)?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    монга - документно-ориентированная база. Подумайте хорошенько. Если вы не планируете вводить связи между записями - то смело берите монгу. В противном случае не стоит.
    Ответ написан
  • Используете ли вы реляционные и документоориентированные субд в одном проекте?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Да, это более чем нормальный сценарий. Скажем хранить все в postgresql и делать агрегации данных для ускорение выборок в какой нибудь elasticsearch или монгу.

    А если вы еще и CQRS будете практиковать, то вообще ништяк. Тогда команды у нас будут работать только с postgresql и инициировать обновление агрегаций а запросы - с эластикой.
    Ответ написан
  • На чем писать Rest API?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Хорошо ли он подружится с React.js?

    А в react.js уже есть http клиент? Эта библиотека только для view layer. Так что как приготовите взаимодействие с API так и будет дружить.

    А стоит ли тратить время на написание REST API ?

    https://parse.com/
    Ответ написан
  • Правильно ли я понимаю проектирование БД на mongo?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    вы пытаетесь впихнуть реляционную модель в рамках докментоориетированной монги.

    name,date,user_id

    user_id вообще быть не должно.

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

    Коллекция в этом случае будет агрегацией данных, эдакий кэш. Можно держать несколько коллекций, как в случае с реляционными базами и формировать часть коллекций динамически через map/reduce при изменении данных. Как оптимизировать обновление этой выборки - это уже ваша задача как программиста.
    Ответ написан
  • Какие примеры реального применения MongoDB вы знаете?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Документно-ориентированные системы, когда система в рамках одного запроса работает только с одним документом или с коллекцией документов, которые никак не связаны друг с другом и ничего друг о друге не знают. У меня в контексте такой системы есть внутренняя простенькая CMS-очка, где каждая страница это документ, а сама страница собирается из разнообразных блоков. Ну или это могут быть какие-то логи, аналитика (тут удобно еще смешивать с агрегированием, когда есть одна коллекция в которую пишут события и еще одна коллекция собирается через map-reduce из других) или еще чего. Только в этом случае, когда каждая коллекция независима, монгу имеет смысл использовать в качестве основного хранилища данных.

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

    Ограничения основного хранилища данных. Например есть довольно модная MySQL которая очень многого не умеет, например вещей типа хранение и индексации массивов, геоиндексы и т.д. В этом случае мы можем поставить монгу и вернуться к пункту о кеширующем слое для ускорения выборок. Скажем если разработчики используют PostgreSQL то возможных кейсов где надо прикручивать монгу уже становится на порядок меньше. С 9.4 постгре даже JSONB умеет хранить.

    Как-то так... В целом для всего есть более специализированные средства, но в целях упрощения можно взять полу-универсальную монгу.
    Ответ написан
  • Посоветуете литературу или ресурсы по практике MEAN?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    читайте по отдельности для каждого компонента и будет вам счастье.

    Возьмем этот самый MEAN:
    - MongoDB - я лично не советую использовать оный как основное хранилище данных. Да, для 10% проектов в принципе норм, но лучше использовать как кэширующую прослойку для агрегатов данных. То есть вопрос с базой это вопрос с базой
    - Express - вместо него может быть что угодно, но по сути вам нужно сделать на нем именно Rest API или JSON RPC.
    - Angular - если он ничего не будет знать о реализации сервера - то гуд. Ему нужен только интерфейс взаимодействия с сервисом, предыдущий пункт. Так что тут явно можно читать вне контекста сервера.
    - Node.js - добавлен в mean стэк для того что бы название было симпатишнее. По сути мы уже используем express а значит и ноду. По сути вы просто должны знать JS и посмотреть API самой ноды что бы реализовать ту же самую JSON RPC или REST API. Ну и фронтэнд будет явно собираться нодой через какой галп.
    Ответ написан
  • Выбор технологий для backend в geo сервисе на yandex map?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    PHP норм, вопрос как хранить данные эффективно. Можно взять постгрес и потом если не будет хватать производительности в плане поиска (зависит от характера этого поиска) - уже можно будет подключать какой-нибудь эластик серч. Или монгу для хранения агрегированных данных для более быстрого поиска и выборок, но все вешать на монгу я бы не стал.
    Ответ написан