Какие системы баз данных следует учитывать при запуске?

Question

Сейчас я разрабатываю прототип веб-приложения, которое объединяет большое количество текстовых записей от большого числа пользователей. Эти данные должны часто отображаться и часто обновляться. На данный момент я храню содержимое в базе данных MySQL и использую слой ORM NHibernate для взаимодействия с БД. У меня есть таблица, определенная для пользователей, ролей, представлений, тегов, уведомлений и т. Д. Мне нравится это решение, потому что оно работает хорошо, а мой код выглядит неплохо и разумно, но меня также беспокоит, как MySQL будет работать после размера нашей базы данных достигает значительного числа. Я чувствую, что он может очень быстро выполнять операции соединения.

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

Answer 1

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

• Availabililty таланта. MySQL очень распространен, и вам, вероятно, будет легче (и, что более важно, дешевле) найти разработчиков для него по сравнению с более разреженными системами баз данных. Эта более крупная база разработчиков также будет означать больше учебников, более активное сообщество поддержки и т. Д.
• Простота развития. Опять же, поскольку MySQL настолько распространен, вы обнаружите, что это выбор для большого количества систем/сервисов. Эта общая основа может упростить любую внешнюю интеграцию.
• Вы готовитесь к ситуации, которая никогда не может существовать и управляема, если это произойдет. Очень немногие предприятия (без заработка) подошли вплотную к ограничениям MySQL и со всем уважением (и я просто угадываю здесь); вероятность того, что ваш стартап когда-либо ударит по типу пропускной способности данных, чтобы калечить правильно структурированный, хорошо обеспеченный ресурсами MySQL db, почти равен нулю.

В принципе, не тратить свое время (деньги) == беспокоиться о том, какие дб использовать, так как MySQL может обрабатывать много данных, хорошо зарекомендовала себя и хорошо поддерживается.

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

FYI, мое решение для кеширования - memcached.

Answer 2

Что, по вашему мнению, представляет значительный объем данных? MySQL, и в основном большинство реляционных СУБД, могут обрабатывать довольно большой объем данных с надлежащими индексами и разумной схемой базы данных.

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

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

Будьте осторожны с NHibernate, легко сделать решение, которое приятно и легко кодировать, но имеет плохую производительность с большим объемом данных. Например, следует тщательно рассмотреть вопрос о том, следует ли использовать ленивый или нетерпеливый выбор с ассоциациями. Я не имею в виду, что вы не должны использовать NHibernate, но убедитесь, что вы понимаете, как работает NHibernate, например, что означает «n + 1 selects».

Answer 3

Измерьте, не принимайте.

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

Итак, если у вас есть прецедент для NoSQL, введите код. Или, если вам более комфортно относиться к этому, кодекс. Затем измерьте, насколько хорошо он работает и как он масштабируется, и если все в порядке, пойдите с ним, если нет, проанализируйте причину.

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

Answer 4

До сих пор никто не упоминал PostgreSQL как альтернативу MySQL на реляционной стороне. Имейте в виду, что MySQL libs - это чистый GPL, а не LGPL. Это может заставить вас освободить ваш код, если вы ссылаетесь на них, хотя, возможно, кто-то с более юридическим опытом может лучше сказать вам о последствиях. С другой стороны, привязка к библиотеке MySQL - это не то же самое, что просто подключиться к серверу и выдавать команды, вы можете сделать это с закрытым исходным кодом.

PostreSQL обычно является лучшей бесплатной заменой Oracle, а лицензия BSD должна быть более дружественной к бизнесу.

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

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

1. Размер ваших данных или, если вам нужно хранить файлы в базе данных.
2. Огромное количество чтений и очень мало (даже ограничено) пишет. В этом случае больше, чем для базы данных, вам нужен такой каталог, как LDAP
3. Важность распространения и/или репликации данных. Большинство реляционных баз данных могут быть более или менее хорошо реплицированы, но из-за их концепции/дизайна не обрабатываются также распределение данных ... но вы будете обрабатывать столько данных, которые не вписываются ни в один сервер, либо имеют права доступа, которые требуют специальных отдельных/дополнительных серверов?

Однако большинство людей будет идти для не реляционных баз данных просто потому, что они не любят обучения SQL

Answer 5

Я предлагаю вам попробовать каждый бит и выбрать тот, который облегчает разработку вашего приложения. Перейдите на страницу http://try.mongodb.org, чтобы попробовать MongoDB с помощью простого учебника. Не беспокойтесь о скорости, так как в начале время разработки более ценно, чем время процессора.

Я знаю, что многие пользователи MongoDB смогли протолкнуть их ORM и их слой кеширования. Модель данных Mongo намного ближе к объектам, с которыми вы работаете, чем к реляционным таблицам, поэтому вы можете просто просто хранить свои объекты как есть, даже если они содержат списки вложенных объектов, например, запись в блоге с комментариями. Кроме того, поскольку mongo достаточно быстр для большинства сайтов как есть, вы можете избежать проблем с кешированием и, как правило, доставить сайт в режиме реального времени. Например, Wordnik.com reported 250 000 считываний/сек и 100 000 вставок в секунду с DBT объемом 1,2 ТБ/5 миллиардов.

Есть несколько способов подключения к MongoDB из .Net, но у меня нет достаточно опыта с этой платформой, чтобы знать, что лучше:

• Norm: http://wiki.github.com/atheken/NoRM/
• MongoDB-CSharp: http://github.com/samus/mongodb-csharp
• Простой MongoDB: http://code.google.com/p/simple-mongodb/

Отказ от ответственности: Я работаю 10gen на MongoDB, так что я немного предвзято.