SQL (MySQL) против NoSQL (CouchDB) [закрыто]

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

Есть ли у кого-нибудь мысли или рекомендации по этому поводу?

Вот цитата из недавнего сообщения в блоге Dare Obasanjo .

Базы данных SQL подобны автоматической передаче, а базы данных NoSQL подобны ручной передаче. Как только вы переключитесь на NoSQL, вы станете ответственным за большой объем работы, которую система выполняет автоматически в системе реляционной базы данных. Подобно тому, что происходит, когда вы выбираете механическую коробку передач вместо автоматической. Во-вторых, NoSQL позволяет повысить производительность системы за счет устранения большого количества проверок целостности, выполняемых реляционными базами данных на уровне базы данных. Опять же, это похоже на то, как вы можете добиться большей производительности от своего автомобиля, управляя механической коробкой передач по сравнению с автомобилем с автоматической коробкой передач.

Однако наиболее заметное сходство заключается в том, что так же, как большинство из нас не может реально воспользоваться преимуществами транспортного средства с механической коробкой передач, поскольку большая часть нашего вождения находится в пробке по дороге на работу и с работы, существует аналогичная суровая реальность. в том, что большинство сайтов не в масштабе Google или Facebook и, следовательно, не нуждаются в Bigtable или Cassandra.

К этому я могу добавить только то, что переход с MySQL, где у вас есть хотя бы некоторый опыт, на CouchDB, где у вас нет опыта, означает, что вам придется иметь дело с совершенно новым набором проблем и изучать различные концепции и лучшие практики. Хотя сам по себе это замечательно (я играю дома с MongoDB, и он мне очень нравится), это будет стоимость, которую вам нужно будет вычислить при оценке работы для этого проекта, и она несет неизвестные риски, но обещает неизвестные преимущества. Будет очень сложно судить, сможете ли вы выполнить проект вовремя и с тем качеством, которое хотите / необходимо для успеха, если он основан на технологии, которую вы не знаете.

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

Обновление : просто чтобы подлить бензина в открытый огонь, который вы развели, вот две интересные статьи от людей из лагеря SQL. :-)

Я не могу дождаться, когда NoSQL умрет (исходная статья утеряна, вот копия )
Борьба с мышлением NoSQL, хотя это не
обновление части, направленное против NoSQL : вот интересная статья о NoSQL, которая
понимает смысл NoSQL

Похоже, что только настоящие решения сегодня вращаются вокруг масштабирования или сегментирования. Все современные базы данных (как NoSQL, так и NewSQL) поддерживают горизонтальное масштабирование прямо из коробки, на уровне базы данных, без необходимости для приложения иметь код сегментирования или что-то в этом роде.

К сожалению, для старого доброго MySQL, которому доверяют, сегментирование не предусмотрено "из коробки". ScaleBase (отказ от ответственности: я работаю там) - производитель полного горизонтально масштабируемого решения, если хотите, «автоматической шардировочной машины». ScaleBae анализирует ваши данные и поток SQL, разделяет данные по узлам БД и объединяет их во время выполнения - так что вам не придется! И это бесплатно.

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

Здесь вы можете увидеть больше данных о MySQL, NoSQL ...: http://www.scalebase.com/extreme-scalability-with-mongodb-and-mysql-part-1-auto-sharding

Надеюсь, это помогло.

Один из лучших вариантов - использовать MongoDB (NOSql dB), который поддерживает масштабируемость. Хранит большие объемы данных только в виде больших данных в форме документов, в отличие от строк и таблиц в sql. Это быстрее, чем выполняется сегментирование данных. Использует наборы реплик. для обеспечения гарантии данных, которые обслуживают несколько серверов с основным сервером db в качестве базы. Независимый от языка. Гибкость в использовании