SQL Server против NoSQL
Так что у меня есть сайт, который со временем может получить довольно высокий трафик. Моя реализация БД на данный момент находится в SQL Server 2008. На самом деле у меня есть только 2 таблицы и несколько хранимых профилей. Большая часть БД может быть перепроектирована для работы без присоединения (хотя это не имеет смысла, когда я так легко могу присоединиться к SQL Server)
Я слышал, что такие сайты, как Digg и Facebook используют базы данных NoSQL для доступа к большому количеству своих основных данных. Стоит ли на это смотреть, или SQL Server не замедлит меня настолько сильно?
Я использую пейджинг на своем сайте (хотя в будущем это может измениться), а также использую AJAX-доступ к данным для большинства "живых" вещей, так что на данный момент это не кажется помехой производительности, но боюсь, что так и будет, поскольку данные начинают расширяться в геометрической прогрессии.
Смогу ли я получить большую производительность при переходе на NoSQL? Честно говоря, сейчас я даже не до конца понимаю NoSQL, так что любые советы , как это поможет мне улучшить ситуацию.
Спасибо ребята.
3 ответа
На самом деле Facebook использует реляционную базу данных в своей основе, см. Основной доклад SOCC: Создание Facebook: производительность в массовом масштабе . Как и многие другие веб-сайты, см. . Почему Quora использует MySQL в качестве хранилища данных вместо NoSQL, таких как Cassandra, MongoDB, CouchDB и т. Д.? . Также обсуждается, как масштабировать SQL Server до размера веб-масштаба, см. Как крупномасштабные сайты и приложения остаются основанными на SQL? , который основан на архитектуре MySpace (более подробно на Уменьшите масштаб SQL Server с помощью надежного обмена сообщениями ). Я не говорю, что NoSQL не имеет своих вариантов использования, я просто хочу отметить, что существует много оттенков серого между белым и черным.
Если вы боитесь, что ваше текущее решение не будет масштабироваться, то, возможно, вам следует посмотреть, какие факторы препятствуют масштабируемости вашего текущего решения. Тестовые данные дешевы в производстве, загрузите «экспоненциально увеличенный» объем данных и запустите свой тестовый жгут, посмотрите, где он треснет. Ни одно из решений NoSQL не принесет волшебную готовность к масштабированию, все они требуют от вас понимания того, как эффективно их использовать и правильно их развертывать. И они также требуют от вас тестирования с большими объемами, если вы хотите добиться успеха в масштабе. То же самое для традиционных реляционных решений.
я собирающийся получать большую производительность мое перемещение в NoSQL?
Это зависит.
Выезд эта статья по 7 причинам, когда Вы не хотите использовать NoSQL. Если ни один не Ваш случай, то считанный далее.
основное преимущество Основанный на документе NoSQL для традиционных потребностей предприятия более дешевый хостинг в высоком масштабе должен понизить использование ЦП на запросы денормализованных данных (чаще всего запрос). Ключевые пункты:
- ЦП сходит с ума на
JOINс иGROUP BYс в SQL-запросах, когда denormilised структура данных подразумевает нет/меньшеJOINс, следовательно меньше напряжения на ЦП. - ЦП является самым дорогим ресурсом в облаке, затем устройство хранения данных является самым дешевым. И денормализованные данные обменивают более высокое устройство хранения данных на более низкий ЦП.
, Как добраться там?
- Осваивают DDD (Управляемый Доменом Дизайн).
- Усиление хорошее понимание CQRS (Сегрегация Ответственности за Запрос Команды) и Возможная непротиворечивость .
- Понимают Ваш домен и бизнес-процессы.
- модель Design, которая настраивается на схемы доступа.
- Обзор.
- Повторные шаги 3 - 5.
С простой структурой таблиц и данными, которые умещаются на одном сервере, не имеет большого значения, какую платформу вы используете. Существует несколько возможных причин перехода на NoSQL:
-
Масштабирование данных - SQL работает лучше всего, когда все данные помещаются на одном сервере (до нескольких ТБ). Причина, по которой многие хранилища NoSQL не имеют объединения, заключается в том, что они были разработаны так, чтобы не требовать, чтобы все объекты находились на одном сервере.
-
Масштабирование производительности - хранилища NoSQL, как правило, быстрее справляются с большим трафиком, но не обязательно в достаточной степени. Вы можете значительно улучшить производительность SQL с помощью репликации и кэширования, если у вас нет проблем с размером данных. Обычно записи должны выполняться на одном сервере, но в большинстве случаев вам нужно улучшить производительность чтения задолго до того, как производительность записи станет проблемой.
-
Сложный доступ к данным - некоторые типы запросов просто не вписываются в реляционную модель. Хранилища графиков и множеств работают совершенно иначе, чем реляционные базы данных, поэтому лучше подходят для некоторых приложений.
-
Упрощенная разработка - если у вас еще нет базы данных SQL и всего кода для ее поддержки, использование хранилища данных без схемы может сэкономить немало времени на разработку.