Ответы пользователя по тегу MongoDB
  • Как отслеживать время у объектов в базе данных?

    node-schedule
    При запуске сервиса просто взводите все джобы, которые у вас есть в базе. Если их очень много, группируйте по времени срабатывания. Ну или можно действительно делать выборку только за сегодняшний день, каждые несколько часов, нужно подобрать параметры в зависимости от задачи и нагрузки.

    Или вот ещё планировщик есть: Bree
    Ответ написан
    Комментировать
  • Как сохранить JSON в MongoDB с сохранением связей?

    Ну или, может, какие-то другие варианты есть?

    Есть. Использовать каждую СУБД по назначению и не пытаться запихнуть реляционные данные в документную БД.

    А вообще, наверное стоит просто для независимых сущностей генерировать новые ObjectId, и протаскивать их во все зависимые сущности вместо соответствующих id. Ну т.е. не нужно пытаться решать задачу в лоб, пытаясь сконвертировать один id в другой, вам нужно сконвертировать СВЯЗЬ, а не id. Чтобы сконвертировать связь, вам не нужен оригинальный id, вам важно соединить с помощью нового ObjectId те же самые сущности, что были соединены в реляционной базе оригинальным id.
    Ответ написан
    1 комментарий
  • Как оставить все нули в float в MongoDB?

    Поймите, что документы в Монге хранятся в JSON, а в JSON ваше 1.0 это число, и хранится оно вообще не так как показывается. Чтобы сохранить конкретное форматирование, вам нужно хранить строку а не число.
    Ответ написан
    Комментировать
  • Поддержка миграций или нереляционная БД?

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

    В целом, необходимость изменения схемы не должна диктовать вам какую модель данных (и следовательно СУБД) применять. В большинстве проектов использующих реляционную БД схема рано или поздно меняется, но никто не переходит на документную модель только потому что нужно выполнять миграцию данных иил схемы.
    Ответ написан
    1 комментарий
  • Где почитать про проектирование баз данных(nosql) с практическими примерами?

    используя nosql-базы

    Шаг 1. Убрать из лексикона термин "NoSQL". Хотя бы временно.
    как наиболее правильно хранить пользовательские данные, комментарии, лайки, медиа-данные.

    Шаг 2. Выписать или запомнить три важнейших свойства любой СУБД:
    • модель данных: что является элементом данных, что является коллекцией элементов, чего в СУБД должно быть постоянное количество, есть ли схема и в каком виде, как обеспечиваются связи между элементами данных на уровне модели;
      Пример: MongoDB, элемент данных - документ, описывается как JSON-документ с некоторыми специфичными для Монги расширениями. Коллекция элементов - коллекция документов. Количество коллекций более-менее постоянное, количество документов растёт.
    • ограничения и гарантии физической реализации модели данных - какие операции какую сложность имеют, какую цену (в плане пространства на устройстве хранения и процессорного времени) имеет каждая используемая структура данных или алгоритм; какие параметры как будут расти во время эксплуатации БД.
      Пример: графовые БД, имеющие "настоящий" графовый движок, т.е. такой, который хранит физические ссылки из одной вершины на другую, гарантируют константное время выборки связанных вершин. В связи с этим их выгодно использовать для сильносвязанных нечасто изменяющихся данных (графы друзей в социалочках и т.п.)
    • инструментарий логического и физического уровня: по сути это предыдущие пункты более подробно - какие структуры данных доступны, в частности какие есть индексы, какие способы выборки/фильтрации/сортировки присутствуют; для чего гарантируется транзакционность (особо важный вопрос); где находится база в CAP диаграмме; какие есть средства логического уровня, например представления (view);
    Вспомните любую социальную сеть, где над каждым постом есть куча комментариев, лайков, репостов

    Шаг 3. Научиться ставить задачу с точки зрения обрабатываемых данных:
    • какие данные будут иметь постоянный объем или расти медленно, а какие - быстро и постоянно;
    • какие будут запросы к данным, что будет выбираться как есть, а что нужно будет дополнительно агрегировать;
    • какие запросы будут плановые, а какие придётся выполнять внепланово;
    • какой нужен уровень доступности, какова ценность хранящихся данных и цена простоя.

    Шаг 4. Ознакамливаться с СУБД здесь: nosql-database.org и выбирать нужную с учётом:
    • вашей задачи;
    • порога вхождения;
    • наличия доступных специалистов.
    Ответ написан
    2 комментария
  • В каких случаях лучше использовать NoSQL, а в каких SQL?

    Вот вам развёрнутый ответ.
    Пользовался NoSQL и SQL

    Не могли вы пользоваться NoSQL, вы пользовались какой-то конкретной моделью данных и конкретной СУБД.
    какую БД лучше использовать

    Ни NoSQL ни SQL это ни БД, ни СУБД.
    Был бы признателен за ссылку на статью или развёрнутый ответ, чтобы в будущем я мог при проектировании проекта сразу определится с выбором базы данных.

    В формате "ответ на Тостере" невозможно сравнить существующие сейчас модели данных и уж тем более дать советы по выбору СУБД. Начните с другого: оставьте историко-маркетологический термин "NoSQL" в стороне и начните с рассмотрения реальных моделей данных и их популярных реализаций:
    - колоночная СУБД;
    - хранилище "ключ-значение";
    - документно-ориентированная БД;
    - графовая БД;
    Ответ написан
    2 комментария
  • Как сделать историю в Mongodb … SQL?

    Теоретическая часть:

    Про SQL: стандарт SQL:2011, средства для темпоральных баз данных. Пока поддерживается не всеми вендорами, но можно взять за основу при написании велосипеда.

    Про Монгу особо ничего не скажу, посмотрите вот это:
    https://github.com/thiloplanz/v7files/wiki/Vermongo
    https://github.com/saintedlama/mongoose-version
    Ответ написан
    Комментировать
  • Как лучше структуризировать данные mongodb?

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

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

    Но вы сделали невозможное. Вы смоделировали классическую задачу "друзья друзей" в максимально неподходящей для этого модели данных - документной. И теперь вы хотите
    Неких JOIN такой.


    Итак, еще раз, знакомьтесь: графовая БД. Из конкретных представителей рекомендую посмотреть Neo4j и OrientDB.
    Важно, что обе СУБД имеют средства для хранения "отношений со свойствами", т.е. ваших
    у друзей свои уникальные свойства по отношению к этому пользователю

    Вот пример из доков по Neo4j:
    Relationships between nodes are a key part of a graph database. They allow for finding related data. Just like nodes, relationships can have properties.

    Картинка.
    Аналогичная концепция в OrientDB:
    In addition to mandatory properties, each vertex or edge can also hold a set of custom properties. These properties can be defined by users, which can make vertices and edges appear similar to documents.

    Да, кстати о документах. OrientDB позиционируется как документно-графовая, так что вполне возможно вам с ней будет проще. Вот их самосравнение с Монгой: orientdb.com/orientdb-vs-mongodb

    P.S. Да, маркетинг - великая сила. Это я про MongoDB.
    Или вообще для реализации данного желательно делать это все не на mongo?

    Хорошо, что вы осмеливаетесь задавать себе такой вопрос. Это правильно.
    Ответ написан
    Комментировать
  • Как работает mongodb?

    При запросе к коллекции сервер mongodb уже работает или запускается призапуске сервера nodejs например.

    Кажется, вы не работали не только с nosql, а вообще с любыми многопользовательскими СУБД. Монга это не SQLite: запускается демон и слушает порт на подключения по сети.

    И mongodb устанавливается в сис. файлы?

    Вообще вопрос не понял. Что для вас "системные файлы"?

    Если установить в директорию с проектом или это не играет роли куда и как установилась mongodb.

    Я думаю, в директорию с проектом не стоит устанавливать.

    Если же в любом, то как можно указать папку с коллекциями, через mongod?

    Ну вроде бы да, в любой нормальной клиент-серверной СУБД директория к данным настраивается.

    Вообщем, почитайте отсюда что-ли https://ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B8%D... , вам нужно понять, что монга со своими данными живет сама по себе, а ваше приложение - само по себе, и взаимодействуют они с помощью TCP. Следовательно, нет никакого смысла как-либо связывать директорию с проектом и директорию с БД Монги, т.к. они могут находиться на совершенно разных машинах.
    Ответ написан
    Комментировать
  • Используете ли вы реляционные и документоориентированные субд в одном проекте?

    Да, применяем. Все данные, у которых есть нормальная схема - в постгресе, данные, для которых нет общей схемы (в том числе пользовательские атрибуты к сущностям предметной области - различные заметки и комметарии, свой набор для каждого пользователя) - в монге.
    Ответ написан
    4 комментария
  • Как правильно спроектировать бд для конструктора тестов?

    Про соответствие вариантов ответа не очень понятно, поподробнее пожалуйста.
    Про один из нескольких или письменный - можно попробовать так: если у вопроса в базе указан только один (!) вариант ответа, то тогда он же - правильный, и тогда по определению нет смысла показывать ответ пользователю - значит вопрос письменный. Если у вопроса в базе несколько вариантов ответа, то имеет смысл показать их пользователю, что он выбрал, тогда вопрос на выбор правильных вариантов.
    Ну или действительно ставить у вопроса тип, и каждый тип обрабатывать по-разному, тем более у вас там вопросы с левыми-правыми колонками, которые не похожи на предыдущие типы.
    Ответ написан
    7 комментариев