Подтвердить что ты не робот

Плюсы/минусы MongoDB или MySQL для этой цели

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

В любом случае:

  • У нас есть программное обеспечение, которое отслеживает формы.

  • У нас есть пользователи, которые могут иметь МНОГО различных свойств, буквально сотни настроек, и я не являюсь поклонником таблиц MySQL, которые широко распространены. я На самом деле, как Монго для этого.

  • У нас есть разные типы форм, каждый из которых может иметь совершенно разные поля. Сейчас у нас есть список форм с общими данными, затем присоединитесь к соответствующей таблице для получения дополнительных данных. Я бы все эти поля в одном отдельном документе с Монго, и я мог бы легко добавьте поля, не беспокоясь.

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

  • Наша политика в значительной степени сохраняет ВСЕ данные, даже удаленные или предварительно отредактированные данные... навсегда. Должна ли я быть беспокоился о том, чтобы достичь предела размера? Вероятно, мы говорим о 100 ГБ к концу 2013 года.

  • Сколько запросов Mongo на странице будет забито? 20? 100? Бы что изменилось, если бы у меня был SSD на сервере? (Сейчас у нас есть 60 MySQL запрашивает страницу. Это можно улучшить.)

  • Является ли это плохая идея для моего первого проекта в Монго, бит программного обеспечения? Я могу чему-то научиться, когда я ухожу?

  • Мне нравится нечувствительность к именам столбцов MySQL для быстрого и грязные вещи.

  • В MySQL я разбиваю вещи на разные таблицы. Хорошо ли, в Монго, объединить данные, которые могут быть разделены? Пример: username, email, phone, license1 => [num,isValid], license2 => [num, isValid], notifications => [notification1...notification50000], password hash, salt, setting1, setting2...setting1000, permission1, permission2...permission1000 Конечно, я бы использовал вложенный стиль для организации, но лучше ли хранить все это под "пользователем" или разбить его на настройки, лицензии, разрешения? Второй пример: formName, address, notes => [note1 => [user,note,date], note2 => [user,note,date]]

  • Есть ли проблемы с установкой HYBRID, где пользовательские данные являются Mongo, а данные формы - в MySQL?

  • Нам нужно запустить много отчетов, есть ли ограничения в этом в Монго? Например, я столкнулся бы с проблемами, ищущими каждую форму за последние 40 дней, с оплатой в размере более 10 долларов США, с учетом сборов в каждой строке, отсортированной по возрасту пользователя, который заполнил ее?

  • Резервирование данных. В облаке Amazon MySQL имеет МАССИВНЫЕ суммы избыточности. Есть ли какая-либо услуга, чтобы соответствовать таковой с Монго? Сложно ли это самостоятельно настраивать?

  • Поддерживается ли MongoDB любым "облачным" провайдером? AWS делает много для MySQL, но похоже, что я был бы один для Mongo

Несколько вещей с моей головы - я действительно ценю то, что кто-то должен сказать.

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Нет проблем. Вы можете использовать разные документы (или встроенные документы на основе их размера - 16 мб - это максимальный размер документа), чтобы справиться с этим без проблем. так что вы можете иметь схему как

  Form
   - form field1
   - form field1
   - id of the fees doc
   - id of the notes doc
   - id of the history doc

или (для встроенных документов)

  Form
   - form field1
   - form field2
   - embedded fees doc
             - fees field1 
             - fees field2
   - embedded notes doc
             - notes field1 
             - notes field2

Наша политика в значительной степени сохраняет ВСЕ данные, даже удаленные или предварительно отредактированные данные... навсегда. > Должен ли я беспокоиться о достижении предела размера? Вероятно, мы говорим 100 гб к концу > 2013

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

Является ли плохая идея для моего первого проекта Mongo быть немного большим программного обеспечения? Я могу чему-то научиться, когда я ухожу?

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

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

Mongo применяет чувствительность к регистру, потому что это характер пары ключевых значений BSON (а также JSON).

В MySQL я разбиваю вещи на разные таблицы. Это прекрасно, в Монго, чтобы объединить данные, которые могут быть разделены? Пример: имя пользователя, электронная почта, телефон, лицензия1 = > [num, isValid],

Основным преимуществом mongo над другим хранилищем данных sql является то, что вы можете хранить как можно больше информации в одном документе (в пределах 16 мб). Если вы не уверены в том, что размер или определенные части данных растут, вы можете разделить часть на другую. Поскольку вы обеспокоены отсутствием запросов, это резко сократит количество запросов.

Есть ли проблемы с установкой HYBRID, где пользовательские данные есть Mongo и данные формы в MySQL?

Абсолютно нет, на самом деле я в настоящее время запускаю mongodb вместе с mysql (только для транзакций). Но если вы не обрабатываете какие-либо транзакции, вы можете придерживаться mongodb.

Мы должны запускать много отчетов, есть ли ограничения на это в Монго? Например, я бы столкнулся с проблемами, ищущими каждую форму с прошлых 40 дней с гонораром свыше $10, с гонорарами в каждом ряду суммированы, отсортированы по возрасту пользователя, который заполнил его?

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

Поддерживается ли MongoDB любым "облачным" провайдером? AWS многое делает для MySQL, но похоже, что я был бы один для Mongo

Mongohq, Mongolab - это некоторые из выделенных управляемых услуг хостинга mongo. Также redhat openshift и vmware cloundfoundry предоставляют хостинговые платформы для монго, вы можете проверить центр хостинга mongo для получения дополнительной информации

Надеюсь, что это поможет

Ответ 2

Вы можете использовать MongoDB или MySQL для того, что вы хотите. Главное, что нужно знать, это масштабирование. В MySQL вы масштабируетесь вертикально. Вы получаете большую машину, лучшую машину. И надеюсь, что это имеет значение. В MongoDB вы масштабируетесь горизонтально. У вас несколько машин и shard. Масштабирование по вертикали имеет предел. Но масштабирование по горизонтали - нет. С точки зрения масштабирования затрат вертикально легко понять. Масштабирование по горизонтали обычно приводит к покупке кластера машин, а затем, когда вы хотите увеличить масштаб, он становится экспоненциальным. Итак, это то, что вам нужно рассмотреть.

Выполнение статистических запросов является недостатком MongoDB. По нескольким причинам. Прежде всего, будут возможности MySQL, которых у вас просто не будет в MongoDB. Во-вторых, для тех, кто больше относится к БД и очень хорошо знаком с операторами SQL, им может быть очень сложно настроить синтаксис MongoDB. Это что-то новое для изучения. И люди часто любят (и хорошо работают), что они знают.

Как и большинство других "NoSQL" платформ, MongoDB не использует ACID, что дает ему некоторое повышение производительности. Но это означает, что это может быть более рискованным.

Есть некоторые облачные решения. Посмотрите MongoHQ и MongoLab. Возможно, я ошибаюсь, но я не верю, что у них SSD. Все шпиндели. Но они поддерживают их. Они обычно отвечают быстро.

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

Я бы не толкал тебя в любом направлении. Это что-то, что требует некоторых исследований. Я бы не сказал, что использование MongoDB - плохая идея для такого крупного проекта, но потребуется время, чтобы выяснить, работает ли оно для вашей ситуации. Как и все.

Есть несколько альтернатив, в частности, проприетарные расширения MySQL, которые могут дать вам большой прирост производительности (в зависимости от вашей настройки, среднего типа транзакций и т.д.). Тот, который приходит на ум, InfoBright, но они часто являются дорогостоящими.