Переход от SQL к NoSQL и к какой базе данных?

Question

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

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

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

Answer 1

на вопросы:

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

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

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

Это зависит от того, как выглядят ваши данные и как вы будете их использовать. Указанный вами noSQL db реализован и ведет себя по-разному , см. Эту ссылку, чтобы получить более подробный обзор, сравнивающий те немногие, о которых вы говорили. Comparisons of noSQL solution

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

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

4 .. Какие могут быть вещи, от которых мы будем проигрывать, переходя от SQL к NoSQL?

Есть два основных соображения NoSQL:

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

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

Answer 2

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

Читайте также OLTP и OLAP.

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

Answer 3

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