MongoDB как первичная база данных?

Question

Я много читал MongoDB.

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

Я знаю, что он компрометирует долговечность в ACID, но я буду в качестве решения иметь 1 мастер и 2 ведомых в разных местах.

Если я это сделаю, можно ли использовать его в качестве первичной базы данных, сохраняя все?

UPDATE:

Позволяет это следующим образом.

Мне действительно нужно хранение документов, а не традиционные dbms, чтобы иметь возможность создавать мое гибкое приложение. Но является ли MongoDB достаточно надежным, чтобы хранить конфиденциальную информацию клиента, если у меня есть несколько репликаций базы данных и master-slave? Причина, насколько я знаю, одна из главных недостатков заключается в том, что она компрометирует D в ACID. Поэтому я решаю его с несколькими базами данных.

Теперь нет серьезных проблем, таких как потеря данных?

И кто-то сказал мне, что с MongoDB клиенту может быть выставлен счет дважды. Может ли кто-нибудь просветить это?

Answer 1

Да, MongoDB может работать только в качестве хранилища данных приложения. Используйте репликацию и убедитесь, что вы знаете о safe writes и w.

И кто-то сказал мне, что с MongoDB клиенту может быть выставлен счет дважды. Может ли кто-нибудь просветить это?

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

Answer 2

Возможно ли это? Конечно. Почему нет? Можно хранить все как XML в текстовых файлах, если хотите.

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

Answer 3

Ваше приложение, гибкое или нет, не имеет ничего общего с тем, что вы используете «nosql», «документ db» или правильную СУБД. Никто из ваших приложений не будет заботиться в любом случае.

Если вам нужна гибкость при кодировании, вам следует исследовать структуры, такие как ActiveRecord для Ruby, которые могут сделать DB-интерфейс намного более простым, универсальным и мощным. На этом уровне вы можете получить больше, чем просто изменить БД, и вы даже можете стать DB-агностиком, то есть вы можете изменить БД без изменения любого кода. Действительно, я обнаружил, что ActiveRecord повышает мою производительность много раз, уменьшая меня от утомительного и подверженного ошибкам «кода, смешанного с SQL».

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

Я чувствую, что вы неохотно относитесь к РСУБД, потому что на самом деле вам не очень комфортно со всеми языками, синтаксисом и звуковыми принципами CS.

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

Низкоуровневые инструменты, такие как MongoDB и эквивалент, предоставляют вам бесконечно больше боеприпасов, чтобы стрелять в ногу. Они кажутся легкими. На самом деле, однако, они оставляют тяжелую работу для вас, кодера, для решения, в то время как РСУБД будет обрабатывать больше трещин для вас, как только вы поймете основы.

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

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

Не покупайте рекламу. Вы задаете вопрос о MongoDB здесь, но включите, что вам действительно нужно его функций. С 25-летним опытом работы с компьютером я просто не покупаю его. Если вы думаете творчески, СУБД можно заставить делать то, что вы хотите, или можно использовать фреймворк, чтобы избавить вас от ошибок и потерянного времени.

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