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

Question

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

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

Answer 1

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

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

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

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

К вашему сведению, мое решение для кэширования - memcached .

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

• Норма: http://wiki.github.com/atheken/NoRM/
• MongoDB-CSharp: http://github.com/samus/mongodb-csharp
• Simple-MongoDB: http://code.google.com/p/simple-mongodb/

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

Answer 4

Мера, не предполагайте.

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

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

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

Answer 5

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

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

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

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