Какие системы баз данных компания по запуску должна рассмотреть?
Прямо сейчас я разрабатываю прототип веб-приложения, которое агрегировало большое количество вводов текста от большого количества пользователей. Эти данные должны часто отображаться назад и часто обновляться. В данный момент я храню содержание в базе данных MySQL и использую уровень NHibernate ORM для взаимодействия с DB. Мне определили таблицу для пользователей, ролей, представлений, тегов, уведомлений и и т.д. Мне нравится это решение, потому что оно работает хорошо, и мой код выглядит хорошим и нормальным, но я также волнуюсь по поводу того, как MySQL будет работать, после того как размер нашей базы данных достигает значительного количества. Я чувствую, что это может бороться, выполняя операции соединения достаточно быстро.
Это заставило меня думать о несистеме реляционных баз данных, такой как MongoDB, CouchDB, Cassandra или Hadoop. К сожалению, у меня нет опыта с также. Я считал некоторые хорошие обзоры на MongoDB, и это выглядит интересным. Я рад провести время и учиться, оказываетесь ли Вы способом пойти. Я был бы очень признателен за какое-либо предложение точки или проблемы для рассмотрения, не идя ни с одним реляционная DBMS?
5 ответов
Другие ответы здесь были сосредоточены в основном на технических аспектах, но я думаю, что есть важные моменты, которые сосредоточены на стартап-компании:
- Доступность талантов. MySQL очень распространен, и вам, вероятно, будет легче (и, что более важно, дешевле) найти разработчиков для него, по сравнению с более дорогими системами баз данных. Эта большая база разработчиков также означает больше учебников, более активное сообщество поддержки и т.д.
- Простота разработки. Опять же, поскольку MySQL настолько распространена, вы обнаружите, что она является базой данных для очень многих систем/сервисов. Эта общая основа может сделать любую внешнюю интеграцию немного проще.
- Вы готовитесь к ситуации, которая может никогда не возникнуть, а если и возникнет, то с ней можно справиться. Очень немногие компании (не говоря уже о стартапах) приближаются к пределам MySQL, и при всем уважении (и я просто предполагаю здесь), вероятность того, что ваш стартап когда-либо достигнет такой пропускной способности данных, которая искалечит правильно структурированную, хорошо обеспеченную ресурсами базу данных MySQL, практически равна нулю.
В общем, не тратьте свое время (== деньги), беспокоясь о том, какую СУБД использовать, поскольку MySQL может обрабатывать много данных, хорошо зарекомендовала себя и хорошо поддерживается.
Возвращаясь к технической стороне вещей... То, что будет иметь гораздо большее влияние на скорость работы вашего приложения, чем выбор СУБД, - это то, насколько эффективно данные могут быть кэшированы. Эффективный кэш может оказать значительное влияние на снижение нагрузки на БД и ускорение общей отзывчивости приложения. Я бы потратил время на изучение решений для кэширования и убедился, что вы разрабатываете свое приложение таким образом, чтобы оно могло наилучшим образом использовать эти решения.
К вашему сведению, мое решение для кэширования - memcached.
Как вы думаете, какой объем данных является значительным? MySQL и в основном большинство механизмов реляционных баз данных могут обрабатывать довольно большие объемы данных с правильными индексами и разумной схемой базы данных.
Почему бы вам не попробовать, как MySQL ведет себя с большим объемом данных в вашей настройке? Сделайте несколько сценариев, которые генерируют реалистичные данные в тестовой базе данных MySQL и создают некоторую нагрузку на систему, и посмотрите, достаточно ли это быстро.
Только когда это недостаточно быстро, сначала подумайте об оптимизации базы данных и переходе на другой механизм базы данных.
Будьте осторожны с NHibernate , легко создать решение, которое приятно и легко кодируется, но имеет низкую производительность при большом объеме данных. Например, следует тщательно продумать, следует ли использовать ленивую или нетерпеливую выборку с ассоциациями. Я не имею в виду, что вы не должны использовать NHibernate, но убедитесь, что вы понимаете, как работает NHibernate, например, что означает проблема «n + 1 выбирает».
Измеряйте, а не предполагайте.
И реляционные базы данных, и базы данных NoSQL могут значительно масштабироваться, если приложение написано правильно в каждом случае и если система, в которой оно работает, правильно настроена.
Итак, если у вас есть вариант использования NoSQL, напишите его код. Или, если вам удобнее относиться к отношениям, напишите код для этого. Затем измерьте, насколько хорошо он работает и как масштабируется, и если все в порядке, продолжайте, если нет, проанализируйте, почему.
Только после того, как вы поймете свою проблему с производительностью, вам следует искать экзотическую технологию, если вы не знакомы с этой технологией или не хотите попробовать ее по какой-либо другой причине.
До сих пор никто не упомянул PostgreSQL как альтернативу MySQL с реляционной стороны. Имейте в виду, что библиотеки MySQL - это чистая GPL, а не LGPL. Это может заставить вас выпустить свой код, если вы ссылаетесь на них, хотя, возможно, кто-то с большим юридическим опытом мог бы лучше рассказать вам о последствиях. С другой стороны, ссылка на библиотеку MySQL - это не то же самое, что просто подключение к серверу и выдача команд, это можно сделать и с закрытым исходным кодом.
PostreSQL обычно является лучшей бесплатной заменой Oracle, а лицензия BSD должна быть более дружественной для бизнеса.
Поскольку вы предпочитаете нереляционную базу данных, учтите, что переход будет более драматичным. Если вам когда-нибудь понадобится настраивать свою базу данных, вам также следует учитывать фактор типа лицензии.
Есть три вещи, которые действительно оказывают глубокое влияние на выбор лучшей базы данных, о которых вы не упомянули:
- Размер ваших данных или необходимость хранения файлов в базе данных.
- Огромное количество чтений и очень малое количество (даже ограниченное) записей. В этом случае больше, чем база данных, вам нужен каталог, такой как LDAP
- Важность распределения данных и/или репликации. Большинство реляционных баз данных могут быть более или менее хорошо реплицированы, но из-за своей концепции/дизайна не так хорошо справляются с распределением данных... но будете ли вы работать с таким количеством данных, которые не помещаются на одном сервере или имеют права доступа, которые требуют специальных отдельных/дополнительных серверов?
Однако большинство людей выберут нереляционную базу данных только потому, что им не нравится изучать SQL
.Я предлагаю вам опробовать каждую базу данных и выбрать ту, которая упрощает разработку вашего приложения. Перейдите на 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, поэтому я немного предвзято.