Является ли MongoDB правильным выбором в моем случае? [закрыто]

9

Я собираюсь построить свой первый настоящий проект на Rails, который состоит из веб-приложения, состоящего из 3 основных частей:

  • Статическая часть, где база данных не используется
  • Часть регистрации пользователя, которая потребует базы данных, и я могу использовать MySQL, поскольку строки каждого пользователя будут иметь одинаковые поля
  • Приложение, в котором пользователи смогут создавать, организовывать, редактировать ... элементы в коллекциях и делиться ими с другими пользователями.

Будет несколько типов элементов, и у каждого будут разные параметры, например, у меня могут быть элементы «видео» со следующими параметрами:

  • Я бы
  • ID пользователя
  • collection_id
  • заглавие
  • платформа (если встроена)
  • URL (если встроен)
  • имя файла (если оно размещено в моем приложении)
  • размер файла (идентификатор размещен в моем приложении)

и элементы "карты":

  • Я бы
  • ID пользователя
  • collection_id
  • заглавие
  • платформа (карты Google, карты Bing ...)
  • расположение
  • URL
  • размер карты

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

До сих пор я всегда использовал PHP и MySQL (всегда на виртуальном хостинге для небольших проектов), и масштабируемость - это совершенно новое слово для меня.

У меня есть время учиться, но я бы хотел сделать что-то конкретное за 1 месяц.

Я много читал о MongoDB и NoSQL против RDMS и MySQL, и после того, как я попробовал это, я должен сказать, что мне нравится, как работает MongoDB: нет таблиц, нет строк и документов JSON, например:

  • В моей ситуации, что бы вы порекомендовали? Почему?
  • По поводу масштабируемости могут быть проблемы с MongoDB? если да, когда (с точки зрения размера БД) и могут ли эти проблемы значительно замедлить мое приложение?

Редактировать: как приложение будет работать

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

  1. Регистрация пользователя
  2. Он залогинен
  3. Он создает свою первую коллекцию, в которой он может создавать бесконечные предметы
  4. Элементы имеют различный тип, и каждый тип требует различных данных для сохранения в базе данных, и тип элементов может быть добавлен или изменен

Пользователи могут создавать другие коллекции и предметы внутри него.

Таким образом, у нас есть CRUD для коллекций и элементов внутри них, и каждая коллекция / элемент относится к определенному пользователю

Основная проблема с MySQL состоит в том, что у него нет гибкой схемы, есть способ решить эту проблему (обходной путь?)?

Думая о NoSQL, я сомневаюсь только в соединении, например, учитывая определенную совокупность, я хочу получить данные, связанные с пользователем, с полем id = user_id в коллекции.

РЕДАКТИРОВАТЬ: Идея продолжать использовать MySQL

Создайте поле в таблице «items» с дополнительными настройками, каждая настройка делится на | или другой символ.

Затем я сохраню где-нибудь структуру необязательных настроек каждого элемента, например, для типа элемента «notes» нужны две необязательные настройки «color» и «ird_setting », когда я получу данные из MySQL, я разделю поле для необязательных настроек на массив, зная, что первый элемент в массиве для "цвета" и так далее.

Что вы думаете? Есть проблемы с этим решением? у тебя есть другие идеи?

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

Ответы:

10

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

Как кто-то однажды сказал мне здесь, на SO:

реляционная часть реляционной БД гораздо более оптимизирована, чем некоторые другие части

Это означает, что вы можете использовать реляционную базу данных, даже если это соответствует вашим вариантам использования. Не просто использовать MongoDB из-за его гибкости / масштабируемости. Это первая строка о MongoDB в Википедии:

MongoDB (от "humongous") - это документально-ориентированная система баз данных NoSQL с открытым исходным кодом.

Вы действительно собираетесь использовать документно-ориентированную БД? Если в ваших сценариях использования есть некоторая графичность, то вы вполне можете использовать графическую базу данных, такую ​​как Neo4j. Или вы можете очень хорошо использовать лучшее из SQL и NoSQL вместе, как это делают некоторые люди.

Кстати, я также делаю проект, в котором я использую лучшие части как SQL, так и NoSQL.

РЕДАКТИРОВАТЬ: я говорю еще раз:

Проверьте раздел Neo4j против Hadoop в этой статье. Это говорит:

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

Ссылаясь на ту же статью, вам действительно нужна плоская структура данных, для которой вы собираетесь использовать MongoDB? В конечном итоге это зависит от ваших подробных вариантов использования, от того, как будут выполняться шаги 3 и 4.

Кроме того, вы можете обратиться к этим вопросам:

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( Проверьте верный / выбранный ответ на второй вопрос наверняка. Вы находитесь в той дилемме, что это может просто решить. )

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

ВНОВЬ РЕДАКТИРОВАТЬ (для части MySQL): Как я понял, вы планируете хранить что-то в БД и разделять их через разделитель. Это представляет 2 проблемы:

  1. Вам необходимо дополнительно обработать любой ввод, который будет иметь разделитель.
  2. Часть реляционного хранилища реляционной базы данных гораздо более оптимизирована, чем часть соответствия строк. Я бы не стал использовать схему, в которой мне нужно сопоставлять строки в базе данных, чтобы получить какой-то конкретный результат. Я снова подчеркиваю:

    реляционная часть реляционной БД гораздо более оптимизирована, чем некоторые другие части (например, сопоставление строк)

  3. Не используйте многозначные атрибуты. Люди обычно боятся их.
c0da
источник
в основном я собирался использовать MongoDB для его гибкой схемы, но у меня есть некоторые сомнения, поскольку он не имеет соединения. Во всяком случае, в моем приложении у меня будет база данных для пользователей, а затем базовая учетная запись, в которой каждый элемент связан с пользователем, и набор элементов
Matteo Pagliazzi
Вам не нужно присоединяться к Монго, но вам нужно будет спланировать свою схему. Думайте в терминах объектов вместо таблиц, если вы используете монго. Затем подумайте, как вы получите доступ к своим объектам.
2012 года
8

Я вижу этот вопрос много. Кажется, это всегда считается или / или. MongoDB - отличный новый инструмент. Это также иногда кажется блестящим инструментом для всего, и это может быть плохим выбором в моем опыте.

Я думаю, что лучшая комбинация определенно ОБА, и я хотел бы поблагодарить вас за ваш подход к использованию mylsql для некоторых частей, например для пользователей, но используйте MongoDB для других частей, так как я считаю, что аутентификация и авторизация лучше всего выполняются с помощью MySQL, и есть тонна примеров и модулей, которые делают это действительно хорошо.

Для части «большое количество элементов» вы можете использовать mongoDB, если у вас большой объем, и / или он в основном читает и / или неструктурированные данные.

Я бы посоветовал не основывать ваше решение на гибкости без схемы Монго. SQL и sql-схемы возникли из-за необходимости иметь структурированные данные и уметь выполнять вычисления и преобразования, которые возможны только при такой структуре. Я узнал об этом за 5 лет работы в роли хранилища данных. Я бы только обратился к MongoBD за проблемой производительности. Если вы ожидаете или ожидаете большого количества пользователей и запросов, скажем, 100 000 пользователей и 20 запросов в секунду, я бы использовал mongoDB, в противном случае я бы попытался остаться с sql. Во многих случаях я использовал бы mySQL для небольшого объема, а затем, по мере того, как объем, доход и инфраструктура его поддерживают, переключался на Oracle, прежде чем смешивать в mongoDB. Я согласен, что вы не должны пытаться решать проблемы с объемом, прежде чем испытать их, однако, если у вас есть четкое представление о том, куда вы направляетесь и не Я не хочу переписывать что-то наполовину, поэтому имеет смысл выбрать правильные технологии в самом начале. Просто помните, что если у вас действительно такой большой объем, на всех уровнях стека есть огромное количество опций и технологий, которые вы будете использовать.

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

Аспект проектирования схемы, вероятно, станет самым большим препятствием для традиционных пользователей MySQL. Я думаю, что страница MongoDb по дизайну схемы помогает в этом. В заключение я хочу сказать, что каждая технология, которую вы добавляете в смесь, добавляет сложности. За каждым конкретным произведением часто выступают огромные сторонники, которые скажут, что вы «должны» его использовать, но я обнаружил, что по-настоящему важным фактором является только количество произведений. Это подразумевает больше возможных точек сбоя и больше всего базы знаний, необходимой для того, чтобы кто-то еще должен был знать, чтобы работать над этим.

К вашему сведению, Рик Обсорн имеет довольно удивительную диаграмму сравнения, которая является совершенно уникальной!

Майкл Даррант
источник
это мой первый настоящий проект в рельсах: это хобби, и пока я не знаю, будет ли это успех или неудача, моя первая цель здесь - познакомиться с рельсами, чтобы я не мог говорить о трафике. Чтения не будут первичными, у меня также будет много новых и обновленных данных ...
Маттео Пальяцци
1
Хорошая вещь в mongodb - нет фиксированной схемы, поэтому для хобби-проекта меньше работы по настройке. Схема может со временем развиваться, и вам не нужно предпринимать дополнительных действий по обновлению таблиц SQL.
Кевин
не уверен насчет моего -1 или почему 0 плохой совет или не согласен?
Майкл Даррант
В любом случае, если это ваш первый проект в рельсах, я бы остановился на mySQL. В рельсах есть МНОГО обучения, которое стоит намного больше, чем 1 месяц, как только вы начинаете задвигать шторы.
Майкл Даррант
@michael смотрите мое последнее обновление
Matteo Pagliazzi
3

Я вижу много действительных аргументов для NoSQL против MySQL. Одна недостающая ссылка, однако, касается масштабирования: если вы действительно хотите масштабировать и хотите сделать это с собственной базой данных, вам понадобится МНОГО знаний о базах данных. Существует слишком много страшных историй, когда люди не смогли реализовать систему, которая будет бесконечно масштабироваться.

Если вы действительно хотите пойти по маршруту NoSQL (и готовы взять на себя расходы, которые идут с ним - как без присоединений), рассмотрите AWS DynamoDB (http://aws.amazon.com/dynamodb/). Здесь вы можете забыть обо всей масштабируемой части базы данных и сосредоточиться на своем приложении. Удачи.

Отказ от ответственности: я являюсь разработчиком в команде AWS DynamoDB, но я действительно верю в наш продукт. Попробуй :)

Subu Sankara Subramanian
источник
1

Таким образом, ваш дизайн может сохранить в вашей базе данных два разных типа объектов:

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

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

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

В MySQL у вас будут проблемы с разными форматами для разных приложений, но это возможно. Некоторые идеи:

  • Вы можете создать промежуточную таблицу со всей общей информацией по всем объектам (id, user_id, title и т. Д.), А затем по типу, чтобы вы могли искать ее в другой таблице, используя только не общие поля для этого формата (например, file_name и file_size для файлов). Вам нужно будет создать разные таблицы для каждого другого формата. Если обе таблицы проиндексированы с помощью app_id (первичный ключ), это будет достаточно быстро, так как доступ к таблице с помощью индексированного значения будет быстрым.
  • Вы можете кодировать данные в каком-то формате и хранить стандартизированные. Например, закодируйте необычные данные в JSON в виде строки и сохраните их в поле VARCHAR. Будьте осторожны с размером этого поля, чтобы вам не хватило места. Формат может быть сложным (JSON) или простым (только значения, разделенные запятыми)
  • Вы можете создавать различные «общие» поля, например, int1, int2, str1, str2, и определять, что str1 для типа приложения - «file_name», а для другого типа - «location».

На MongoDB это может быть так же просто, как просто использовать две коллекции MongoDB, одну для пользователей и другую для приложений. Предполагая какое-то ограничение (что не так, как вы описали, но просто для того, чтобы сказать), вы можете даже хранить приложения внутри объекта пользователя в виде списка. Хранение и извлечение данных более естественно, так как вы можете хранить любые объекты, независимо от того, какие поля. Вы можете выполнить поиск по user_id, чтобы получить все приложения, принадлежащие пользователю. В MongoDB вы все равно теряете возможность выполнения запросов на объединение, но в этом случае я думаю, что основными запросами будет получение пользователя и получение приложений, связанных с ним. Если вы планируете делать много таких вещей, как «дать мне пользователей, которые имеют более двух коллекций с тремя или менее приложениями в каждом», вам придется генерировать его не как запрос на соединение, но как процесс в коде, он будет менее естественным, чем в реляционной базе данных, и может занять больше времени для обработки. Если вы хотите выполнить поиск параметров (например, дайте мне все приложения, принадлежащие определенному пользователю; дайте мне все приложения типа X), это довольно просто для MongoDB и не требует использования объединений.

Я не уверен насчет поддержки MongoDB на Rails. Я использую его в Python и JavaScript.

РЕДАКТИРОВАТЬ: Добавлен комментарий о времени при доступе к двум таблицам и другой вариант MySQL

Khelben
источник
мне не нравится второй вариант использования MySQL для хранения необязательных настроек, потому что я думаю, что он может загружать каждую строку большим количеством ненужных байтов ... для второго: это сильно замедлит мое приложение, чтобы загрузить две строки из двух разных таблиц загрузить один элемент?
Маттео Пальяцци
пожалуйста, смотрите мое последнее обновление
Маттео Pagliazzi
Что касается вашего вопроса о скорости, он не должен быть намного медленнее (вы получаете доступ к нему через индексированное уникальное значение). Я также отредактировал свой ответ, так как последнее отредактированное предложение аналогично первой идее, и добавил еще один вариант.
Хельбен
1

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

Сказав это, одной из причин, по которым вы можете использовать MongoDB, являются ваши данные. Как вы упомянули, у вас будет несколько разных типов записей для ваших коллекций: карта, видео и так далее. Если бы вы реализовали это с использованием RDBMS, у вас есть 3 подхода:

  • таблица для каждого типа: каждая таблица содержит столбцы, специфичные для каждого типа объектов

    Недостатки : N запрос для поиска по всем типам данных.

    Преимущества : хороший ОО дизайн, простота в обслуживании

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

    Недостатки : изменение любого объекта потребует изменения таблицы, болезненно, когда таблица становится большой. Сложно поддерживать.

    Преимущества : простота реализации.

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

    Недостатки : два запроса, чтобы получить все данные для одного объекта.

    Преимущества : Чрезвычайно гибкий, не очень сложный в реализации.

Я использовал каждый из этих подходов раньше, и я могу сказать, что ни один не является естественным для работы с Монго. Ваши данные, вероятно, будут выглядеть примерно так:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

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

Заметил, что я не стал обсуждать сравнение производительности между MySql и Mongodb. Хотя вы всегда должны помнить о производительности, вы не сможете эффективно принимать решения, если не знаете схему доступа к данным. Любой хороший проект, вероятно, пройдет несколько итераций рефакторинга по мере его роста и появления новых проблем. Не беспокойтесь о производительности заранее, выберите инструмент, о котором вы лучше всего знаете, и начните писать код.

редактировать

Чтобы ответить на ваш конкретный вопрос об использовании MySQL и сохранении атрибутов в одном поле, используйте «|». Не делай этого. Такой подход даст вам больше проблем, чем решит. Прежде всего, вы не сможете запрашивать отдельные атрибуты, используя MySql. Во-вторых, это добавляет слишком много сложности вашему уровню доступа к данным. Вместо этого используйте подход типа «таблица» или «метаданные». Если вы работали с WordPress раньше, он использует подход метаданных:

  • таблица пользователя + usemeta для пользователя
  • пост стол + постмета стол пост

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

ltfishie
источник
мне не нравится опция метаданных ... но я обдумываю одну таблицу с полями, оставленными нулевыми, если не используется
Matteo Pagliazzi
Подход с одним столом, вероятно, худший из всех. Хотя вы можете делать все в одном запросе, любое изменение любого отдельного типа данных потребует изменения таблицы. И это боль в MySQL, когда ваш стол становится большим.
2012 года
0

Статья ниже дает хорошие результаты, сравнивая MySQL и MongoDB с точки зрения выбора, извлечения и вставки, учитывая количество данных в базе данных и количество извлеченных данных. Результаты показывают отличную производительность для MongoDB в отношении «вставок», но в других случаях MySQL выигрывает. См. ниже:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

У меня был опыт использования MongoDB, который я считаю хорошим решением. Я использовал его, чтобы вставлять тысячи коллекций каждый день. В сочетании с решением Solr (решение для кэширования, обновляемое один раз в день) я могу при необходимости извлекать данные MongoDB по идентификатору коллекции, поэтому мне не нужно выбирать на лету. Таким образом, учитывая, что вам приходится иметь дело со множеством вставок и не нужно заботиться о выборе и получении, MongoDB может быть отличной идеей, это зависит от каждого случая и проведет хороший анализ.

Рожерио Гильберт
источник