Перестроить приложение ASP.NET, заменив SQL Server на NoSQL - PullRequest
2 голосов
/ 28 марта 2011

У нас есть приложение ASP.NET с SQL Server, и это сайт для обмена фотографиями и видео. Подробности фотографий и видео хранятся в таблицах, а файлы находятся в файловой системе.

База данных имеет 75 таблиц и 225 хранимых процедур. Приложение будет готово к развертыванию в течение следующих 6 месяцев.

Из-за более длительных проблем роста мы решили перейти на базу данных NoSQL ( MongoDB ).

У нас есть несколько вопросов о том, как лучше всего подойти к этому:

  • Лучше ли развернуть приложение с бэкэндом SQL Server и позже перейти на NoSQL?

  • ИЛИ измените архитектуру сейчас и перепишите / воссоздайте базу данных, таблицы, процедуры и слой данных

  • Насколько сложно будет пере-архитектура / перекодирование с MongoDB? Какие-нибудь инструменты или БКМ?

EDIT: Наше приложение - сайт типа Youtube + Flickr, где пользователь будет делиться фотографиями и видео с большим количеством комментариев, тегов и оценок (фото \ видео и комментарии).

Является ли NoSQL лучшей базой данных для перехода? Причина перемещения: стоимость + скорость чтения

Пожалуйста, помогите мне с ценным советом.

Большое спасибо.

Ответы [ 5 ]

4 голосов
/ 28 марта 2011

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

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

3 голосов
/ 28 марта 2011

Этот вопрос вызывает больше вопросов, чем ответов.

  1. Вы сравнивали текущую реализацию с точки зрения запросов / ответов?
  2. Почему MongoDB из всех возможных баз данных NoSQL? (Не поймите меня неправильно, я люблю Монго, но любовь и шумиха не должны влиять на выбор технологий)
  3. Вы уверены, что получите большую ожидаемую базу пользователей? Почему ты так уверен?
  4. Использование хранимых процедур означает, что вы не используете ORM? Почему нет?

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

Я бы сказал, что вам, вероятно, следует запустить как есть, исправить часть ORM, если вы ее не используете, сравнить приложение, сравнить прототип приложения с поддержкой Mongo и если преимущества в производительности настолько велики, что оправдывает боль перестройки сделать это.

На ваш последний вопрос, насколько я могу судить, сейчас нет никаких инструментов, которые бы автоматизировали или полуавтоматизировали импорт / экспорт базы данных из SQL Server в Mongo. Для MySQL едва ли есть инструменты для этого.

2 голосов
/ 29 марта 2011

Я сделал такую ​​миграцию несколько месяцев назад, на ранней стадии разработки веб-сайта в ASP.NET.Это было трудное решение, но я мог сосредоточиться на этой миграции.Причиной, по которой я сделал эту миграцию, была ORM, которой я больше не мог доверять, и некоторые очень медленные запросы, которые я не знал, как оптимизировать.

На этапе кодирования я понял, что:Много времени с моделью данных в SQL Server (с использованием Entity) и всего кода.Теперь больше нет хранимых процедур (вместо этого C # и код Linq), нет больше двух уровней для обслуживания (код является моделью)

Мой небольшой опыт говорит: чем раньше, тем лучше, но не поймите меня неправильно, перед миграцией вам действительно нужно думать в Document, а не в RDBMS.Это означает, что вам, возможно, придется частично изменить бизнес-модель DataModel для правильного использования функций MongoDB, в противном случае вы можете получить плохую производительность, а Mongo DB бесполезна для плохих моделей.

Другой момент - это админ.Вы должны быстро научиться администрировать Mongo DB, чтобы быть в курсе.И даже если инструменты хороши, они полностью отличаются от инструментов SQL Server.

В заключение, если вы уверены, что MongoDB будет вашим будущим хранилищем данных и поисковой базой данных (и это было в моем случае), прочитайтедокументацию, найдите время, чтобы сделать некоторые доказательства концепции.Затем вы можете подумать о документах и ​​протестировать новую модель.

0 голосов
/ 28 марта 2011

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

0 голосов
/ 28 марта 2011

Ваш основной вопрос, по-видимому, заключается в том, следует ли сейчас перейти на MongoDB или развернуть на SQL и перейти к MongoDB в следующем выпуске.

Похоже, вы не используете ORM (например, NHibernate, Entity Framework.) Отложив другие проблемы, если вы уверены, что хотите перейти на NoSQL, то я бы сделал это сейчас, а не позже,Если вы не интегрируете модель провайдера для доступа к данным, изменить основную стратегию доступа к данным после того, как она уже установлена, будет трудно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...