Переход от SQL к NoSQL и к какой БД?

недавно у нас возникли серьезные проблемы с производительностью в нашей текущей БД SQL Server. Наше приложение довольно тяжело на одной таблице мы сделали некоторый анализ, и около 90% наших данных БД находится в одной таблице. Мы запускаем много запросов в этой таблице, а также для целей analyticall мы испытываем серьезные проблемы с производительностью теперь даже с добавлением одного столбца иногда замедляет наш текущий Sp. Большинство наших команд являются разработчиками, и у нас нет доступа к dba, который может помочь в перенастройка нашей текущей БД и сделать вещи работать быстрее.

причина этих ограничений мы думаем о перемещении этой части приложения в NoSQL db. Мои вопросы:

  1. если это правильное направление мы направляемся ? Поскольку мы ожидаем экспоненциального роста на этой таблице. С нагрузками аналитика работает на нем.
  2. что было бы лучшим вариантом для нас CouchDB, Кассандра, MongoDB ? С акцентом на масштабируемость и производительность
  3. для настоящих анализ времени и поддержка аналогичны SQL как вещи работают в NoSQL есть ли средство, с помощью которого мы можем просматривать текущие данные хранятся? Я где-то читал о Hadoop HIVE, который можно использовать для записи и восстановления данных как SQL из NoSQL db, я прав?
  4. какие вещи мы могли бы потерять при переходе с SQL на NoSQL ?
7
nosql

3 ответов

на ваши вопросы:

1.. Если мы идем в правильном направлении ? Поскольку мы ожидаем экспоненциального роста на этой таблице. С нагрузками аналитика работает на нем.

Да, большинство систем noSQL разработаны специально для решения проблемы масштабируемости и доступности, если вы используете их должным образом.

2.. Какой был бы лучший вариант для нас CouchDB, Cassandra, MongoDB ? С усилием на масштабируемости и производительность

Это полностью зависит от того, как выглядят ваши данные и как вы их будете использовать. Упомянутая вами NoSQL db реализована и ведет себя очень отличаются друг от друга, см. эту ссылку для более подробного обзора, сравнивая несколько упомянутых вами. сравнение решения noSQL

3.. Для анализа в реальном времени и поддержки, подобной SQL, как все работает в NoSQL, есть ли средство, через которое мы можем просмотр текущих данных? Я где-то читал о Hadoop HIVE, который можно использовать для записи и восстановления данных как SQL из NoSQL db, я прав?

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

4.. Что может быть, что мы потеряем при переходе с SQL на NoSQL?

есть два основные соображения для noSQL:

Запроса/Структуру: NoSQL означает отсутствие SQL. Если ваша система действительно требует структурированных и сложных запросов, но вы пошли с одним из этих классных новых решений (особенно хранилище ключевых значений, которое в основном является гигантской хэш-таблицей), вы можете скоро оказаться в середине повторной реализации дилетантской, плохо спроектированной СУБД со всеми вашими оригинальными проблемами.

последовательность: если вы выбираете возможное согласованная система для горизонтального масштабирования, тогда вам придется признать, что ваши данные устарели, что может быть безвредно для некоторых приложений (форумов?) или ужасно в некоторых других системах (банк).

7

Я думаю, вы должны оставаться реляционными и настраивать таблицу, ее индексы и таблицы, к которым она присоединяется. Следует также рассмотреть вопрос об использовании агрегированных (суммированных данных). Возможно, более денормализованный дизайн поможет или даже перепроектировать данные в более звездную структуру. Кроме того, анализ оперативной обработки и поддержки принятия решений (или отчетности) не должен проводиться в одних и тех же таблицах.

2

возможно, можно улучшить подход SQL, проверив отсутствующие индексы и т. д., а также посмотреть, является ли уровень изоляции, который вы используете, оптимальным. Для повышения производительности можно использовать изоляцию моментальных снимков и т. д. MSDN link

читайте на OLTP против OLAP также.

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

1