SQL Server против NoSQL

Итак, у меня есть веб-сайт, который может в конечном итоге получить довольно высокий трафик. Реализация моей БД в SQL Server 2008 на данный момент. У меня действительно есть только 2 таблицы и несколько хранимых процедур. Большинство БД могут быть переработаны без работы (хотя это не имеет смысла, когда я могу так легко присоединиться к SQL Server).

Я слышал, что сайты, такие как Digg и Facebook, используют базы данных NoSQL для большого доступа к их основным данным. Это что-то стоит посмотреть, или SQL Server действительно не замедлит меня так плохо?

Я использую пейджинг на своем сайте (хотя это может измениться и в будущем), и я также использую доступ к данным AJAX'd для большинства "живых" материалов, поэтому на самом деле это не является препятствием для производительности на в данный момент, но я боюсь, что это произойдет, когда данные начнут экспоненциально расширяться.

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

Спасибо, ребята.

Ответ 1

Фактически Facebook использует реляционную базу данных по своему ядру, см. Основной доклад SOCC: создание Facebook: производительность в массовом масштабе. Так же, как и многие другие веб-сайты, см. Почему Quora использует MySQL как хранилище данных вместо NoSQL, таких как Cassandra, MongoDB, CouchDB и т.д.. Существует также обсуждение того, как масштабировать SQL Server до размера веб-масштаба, см. Каким образом крупномасштабные сайты и приложения остаются на базе SQL? который основан на архитектуре MySpace (подробнее см. Отметьте SQL Server с помощью надежных сообщений). Я не говорю, что у NoSQL нет прецедентов, я просто хочу указать, что между белым и черным есть много оттенков серого.

Если вы боитесь, что ваше текущее решение не будет масштабироваться, возможно, вам стоит взглянуть на то, что является фактором, препятствующим масштабируемости с вашим текущим решением. Тестовые данные дешевы для производства, загрузки "экспоненциально увеличенного" объема данных и запуска тестового жгута, см., Где он трескается. Ни один из решений NoSQL не обеспечит масштабируемость магии, все они требуют, чтобы вы поняли, как эффективно их использовать и правильно их развернуть. И они также требуют, чтобы вы тестировали большие объемы, если хотите добиться успеха в масштабе. То же самое для традиционных реляционных решений.

Ответ 2

Сервер Sql очень хорошо масштабируется. Например, Qaru использовал его, чтобы обслуживать вас на этой самой странице. Facebook и Google могут использовать форму nosql, но даже если вы сделаете ее действительно большой, вы вряд ли достигнете этого уровня.

Ответ 3

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

Масштабирование данных - SQL работает лучше всего, когда все данные подходят на одном сервере (до нескольких TB). Причина, по которой у многих магазинов NoSQL нет соединения, заключается в том, что они были предназначены для того, чтобы не требовать, чтобы все объекты находились на одном сервере.
Масштабирование производительности - магазины NoSQL, как правило, быстрее работают с высоким трафиком, но не обязательно достаточно, чтобы иметь значение. Вы можете значительно повысить производительность SQL при репликации и кешировании, пока вы не сталкиваетесь с проблемами размера данных. Обычно записи должны выполняться на одном сервере, но в большинстве случаев вам необходимо улучшить производительность чтения задолго до того, как производительность записи станет проблемой.
Комплексный доступ к данным - некоторые типы запросов просто не вписываются в реляционную модель. Графики и настройки хранилищ работают совсем не так, как в реляционных базах данных, поэтому лучше подходят для некоторых приложений.
Простая разработка. Если у вас еще нет базы данных SQL и всего кода для ее поддержки, использование хранилища данных schemaless может значительно сократить время разработки.

Ответ 4

Я не думаю, что вам нужно переместить базу данных из SQL в NoSQL, если только вы не будете обслуживать тысячи данных о ТБ. Если вы правильно нормализуете свои таблицы и обслуживаете данные, а также должны установить надлежащий механизм архива, он должен работать.

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

Ответ 5

Собираюсь ли я повысить производительность при переходе на NoSQL?

Это зависит.

Ознакомьтесь с этой статьей по 7 причинам, когда вы не хотите использовать NoSQL. Если это не ваш случай, тогда читайте дальше.

Основным преимуществом NoSQL на основе документов для традиционных корпоративных потребностей является более дешевый хостинг в больших масштабах из-за более низкой загрузки ЦП при запросе денормализованных данных (наиболее часто запрашиваемый). Ключевые моменты:

ЦП сходит с ума по JOIN и GROUP BY в запросах SQL, когда денормализованная структура данных подразумевает не более/менее JOIN с, следовательно, меньше нагрузки на ЦП.
Процессор - самый дорогой ресурс в облаке, тогда хранение - самый дешевый. И денормализованные данные обмениваются большим объемом памяти на более низкий процессор.

Как туда добраться?

Освойте DDD (доменно-управляемый дизайн).
Получите хорошее понимание CQRS (сегрегация ответственности за командные запросы) и окончательной согласованности.
Понять свой домен и бизнес-процессы.
Модель дизайна, которая настроена на шаблоны доступа.
Обзор.
Повторите шаги 3 - 5.