Какую бд, MySQL или MongoDB, использовать для моего сайта на node?

Question

[Renhor]

Добрый день! До этого использовал на бекенде PHP + Mysql, сейчас пишу проект с бекендом на Node.

Данные в новом проекте будут примерно такие же как и в старом, а именно:

1) Users
2) Players
3) Orders
4) Reviews
5) Chat
6) Notifications
7) Matches
8) Heroes
9) Items
10) Blog

К некоторым таблицам есть доп. таблицы со связью один к одному.

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

Для меня "эластичность" mongodb выглядит привлекательно, например, я мог бы отказаться от некоторых таблиц(коллекций) и зависимостей один к одному, просто создавая в записи (документе) дополнительное поле-объект.

Но шерстя интернет наткнулся на фразу на тостере, что если есть 10% шанс, что между таблицами будут отношения/связи, то лучше использовать реляционные бд (в моем случае mysql).

Если это действительно так, то с какими трудностями я бы столкнулся, если бы решил все-таки использовать MongoDB?

Answer 1

[Frozen Coder]

Надо смотреть на данные и как они будут использоваться. Если они полны отношений, т.е. носят ярко выраженный реляционный характер, вам нужны запросы с join и транзакционностью, то берите MySQL и всё. К тому же в MySQL есть возможность хранить JSON и вроде даже индексы по нему строить.

Mongodb брать хорошо, когда у данные можно выразить через документ. Т.е. по максимуму все связанные сущности встроить в один документ. Join по факту надо делать руками, т.е. через приложение. Многие фишки реляционных БД как бы есть, но работают похуже, чем в реляционных (есть и схема, и транзации и вроде join, но это такое, лучше избегать по возможности).

Comments

[Renhor]

Получается в монго я должен делать примерно так?

user = {
  _id: 1,
  name: 'Name',
  account_level: 4,
  player: {
    isPlayer: true,
    balance: 500,
    publicProfile: {
      // pubProfile
    },
    privateProfile: {
      // privateProfile
    }
  },
  orders: [
    {
      _id: 1,
      type: 'Type',
      chat: [
        // messages
      ],
      review: {
        // review
      },
      matches: [
        {
          _id: 1,
          hero: 'hero1',
          items: ['item1', 'item2']
        }
      ]
    }
  ],
  siteNotifications: [
    // notifications
  ]
}

Но вот если мне нужно будет вывести только заказы / отзывы, то лучше использовать mysql? Или с выборкой проблем не будет? Или вообще только матчи (например сейчас в бд 20000 матчей в отдельной таблице, в заказе в среднем 50 матчей)

[Иван Шумов]

Renhor, нет, не так. Вам все-равно придется денормализовывать базу данных. Так или иначе. Хотябы до 3NF

Answer 2

[Пасечник Кузьмич]

Готовьтесь к большему потреблению памяти, чем с MySQL.

Answer 3

[Иван Шумов]

Каждому решению своя база данных. Надо смотреть на проект в целом и как всё будет коммуницировать. Будет ли архитектура микросервисная или монолитная? Будет ли SPA или SSR?

Comments

[Renhor]

По поводу микросервисная/монолитная не понял, будет SPA с SSR

[Иван Шумов]

Renhor, а что вам не ясно в различиях монолитной и микросервисной архитектур?

[Frozen Coder]

Скажите, а какая связь между микросерис-монолит или SPA, SSR и БД? Особенно SPA и SSR с БД.

[Renhor]

Иван Шумов, Сами понятия не ясны

[Иван Шумов]

Frozen Coder,

Скажите, а какая связь между микросерис-монолит или SPA, SSR и БД? Особенно SPA и SSR с БД.

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

Сами понятия не ясны

Советую погуглить, но тогда с 99% вероятностью у вас монолит, а это значит что с Mongo вам будет куда труднее

[Frozen Coder]

Иван Шумов, а можете чуть подробнее развернуть мысль? В упор не вижу как SPA и SSR (клиентская же часть) имеет какое-то отношение к БД? Разве клиенту не должно быть фиолетово, что там за бекендом - MySQL или Mongo? Клиент же не ходит напрямую в базу.

Про монолит и микросервис тоже спорно. Если монолит маленький и крутится вокруг одного или пары несвязанных между собой документов, то почему не Mongo? И почему не выбрать MySQL для микросервиса?

[Иван Шумов]

Frozen Coder,

а можете чуть подробнее развернуть мысль? В упор не вижу как SPA и SSR (клиентская же часть) имеет какое-то отношение к БД? Разве клиенту не должно быть фиолетово, что там за бекендом - MySQL или Mongo? Клиент же не ходит напрямую в базу.

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

Про монолит и микросервис тоже спорно. Если монолит маленький и крутится вокруг одного или пары несвязанных между собой документов, то почему не Mongo? И почему не выбрать MySQL для микросервиса?

я не говорил иного, просто вы начали уже говорить про связи, а в микросервисном подходе их не существует. Ну, не в известном большинству понимании. Там вообще архитектура БД иная, как правило и заточена чаще всего на асинхронное взаимодействие

[Виталий]

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

[Иван Шумов]

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

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

[Виталий]

Иван Шумов, просто, ты помни куда ты пришел, если помогать, так помоги людям, если самооценку подтянуть, то имхо ты промахнулся.... ну или твой архитект уровень не так крут, как ты его расписываешь на хх.... без обид

[Иван Шумов]

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

[Виталий]

Иван Шумов, вот я тебя направляю а ты не понимаешь, думаешь остальные иначе воспринимают этот мир?