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

Я собираюсь построить свой первый настоящий проект на 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, я разделю поле для необязательных настроек на массив, зная, что первый элемент в массиве для "цвета" и так далее.

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

Мы не сможем вам помочь, пока вы не сообщите нам, что вы собираетесь делать с приложением. Реляционные базы данных хороши для одних вещей, а базы данных 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. Не используйте многозначные атрибуты. Люди обычно боятся их.

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя я думаю, что это достижимо в 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

Я бы сказал, используйте технологию, которую вы знаете лучше всего, особенно если это настоящий проект, и вы хотите быстро его реализовать. Использование 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 для пользователя
• пост стол + постмета стол пост

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

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

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

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