2013-08-22 2 views
43

Недавно я немного поиграл с Node.js. В моем конкретном случае я закончил использование MongoDB, отчасти потому, что это имело смысл для этого проекта, потому что это было очень просто, а отчасти потому, что Mongoose, казалось, был чрезвычайно простым способом начать работу с ним.Реляционные базы данных плохо подходят для Node.js?

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

Итак, на мой вопрос, есть твердая техническая причина, почему реляционные базы данных хуже подходят для работы с Node.js, чем альтернативы, такие как MongoDB?

EDIT: Просто хочет прояснить несколько вещей:

  • Я специально не ищу детали, относящиеся к конкретному приложению Я здание
  • Nor я ищу не-технические причины (например, я не отвечаю на такие вопросы, как «Node и MongoDB являются новыми, поэтому разработчики используют их вместе»)

То, что я ищу, является исключительно техническими причинами, ТОЛЬКО. Например, если была техническая причина, по которой реляционные базы данных выполнялись необычно плохо при использовании с Node.js, тогда это будет то, что я ищу (обратите внимание, что из ответов до сих пор не появилось, что случай)

+0

Это было закрыто в другом месте: http://programmers.stackexchange.com/questions/198224/why-is-mongodb-popular-with-node-js – WiredPrairie

ответ

23

Нет, нет технической причины. В основном это мнение, и использование NoSQL с Node.js в настоящее время является популярным выбором.

Предоставлено, что экосистемой узла является largely community-driven. Все, что находится за пределами Node core API, требует участия сообщества. И, конечно же, люди будут более склонны поддерживать то, что соответствует их личным предпочтениям.

Но многие используют и поддерживают реляционные базы данных с помощью Node.js. Некоторые известные проекты включают в себя:

+0

Это, вероятно, один из самых печальных ответов, которые я видел - есть огромные технические различия между MongoDB и RDBM и т. д. –

+1

@AlexanderMills. Существуют определенные различия между типами баз данных, но это не означает, что реляционные базы данных непригодны для использования с Node.js. –

+0

правильно, я согласен, см. Мой ответ по техническим причинам –

8

Можете ли вы объяснить, какие конкретные проблемы вы столкнулись с выбранной базой данных и Node.js?

Несколько причин, почему MongoDB может быть более популярным, чем реляционные базы данных:

  • MongoDB, по существу, объект JSON магазин, поэтому он переводит очень хорошо для яваскрипта приложения. Функции MongoDB - это функции javascript.

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

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

Но, к моему основному моменту, мы могли говорить об этом весь день, и это не то, для чего предназначен этот форум. Если у вас есть какие-либо проблемы в любом коде с помощью Node.js и вашей базы данных по выбору, задайте эти вопросы.

Редактировать: Строго технические причины, кроме совместимости с JSON с обеих сторон: их нет.

+0

Я немного разъяснил свой вопрос, чтобы исключить нетехнические ответы.Я ищу только технические причины (если есть), почему разработчик не должен использовать реляционную базу данных с Node.js. –

+1

@MatthewDaly Строго технические причины, кроме совместимости JSON с обеих сторон: их нет. Не стесняйтесь использовать свой Node.js в своем реляционном хранилище данных. До тех пор, пока он является популярным, как MySQL или PostgreSQL, вы не должны сталкиваться с какими-либо проблемами. – Munim

13

Я люблю Node.js, но с узлом он действительно делает больше смысла использовать RDBM, в отличие от нереляционной БД. С помощью noSQL/нереляционного решения вам часто приходится выполнять ручные объединения в коде Node.js и иногда работать с отсутствием транзакций, технической особенностью RDBM, которые имеют функции фиксации/отката. Вот некоторые потенциальные проблемы, связанные с использованием нереляционной БД + Node.js серверов:

(а) присоединяется медленнее и ответы медленнее, потому что узел не является C/C++

(б) дорогие объединения блокируют ваш цикл событий , потому что соединение происходит в вашем коде Node.js, но не на каком-то сервере базы данных.

(c) ручные записи соединений часто сложны и подвержены ошибкам; ваши запросы noSQL могут быть легко ошибочными, или ваш код объединения может быть неправильным или субоптимальным; оптимизированные объединения были сделаны ранее мастерами RDBM, и в большинстве случаев соединения в RDBM оказались правильными, математически.

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

с более мощным реляционной базой данных, которая может сделать оптимизированные соединения в C/C++ на сервере базы данных, а не в коде Node.js, то пусть ваш сервер Node.js делать то, что это лучше всего.

С учетом сказанного, я думаю, что это довольно глупо, что многие крупные производители noSQL не поддерживают объединения (?) Полная де-нормализация - это только мечта, насколько я могу ее видеть. И отсутствие транзакций может быть немного странным. Без транзакций только один запрос является атомарным, вы не можете сделать несколько запросов атомарными без механизма блокировки уровня приложения:/

В качестве стороннего варианта я предпочитаю термин «нереляционный», а не «noSQL».

9

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

Смежные вопросы