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

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

Я знаю, что многие пользователи MongoDB смогли протолкнуть их ORM и их слой кеширования. Модель данных Mongo намного ближе к объектам, с которыми вы работаете, чем к реляционным таблицам, поэтому вы можете просто просто хранить свои объекты как есть, даже если они содержат списки вложенных объектов, например, сообщение в блоге с комментариями. Кроме того, поскольку mongo достаточно быстр для большинства сайтов как есть, вы можете избежать проблем с кешированием и, как правило, доставить сайт в режиме реального времени. Например, Word12.com сообщил 250 000 чтений/сек и 100 000 вставок/сек с DBT объемом 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, поэтому я немного предвзятый.