Как перейти от полного SQL-запроса к чему-то вроде NoSQL?

Question

В одном из моих процессов у меня есть этот SQL-запрос, который занимает 10-20% от общего времени выполнения. Этот запрос SQL выполняет фильтрацию в моей базе данных и загружает список объекта PricingGrid. Поэтому я хочу улучшить эти показатели. Пока я угадал 2 решения:

Используйте решение NoSQL, AFAIK, это хорошие решения для улучшения процесса чтения.

• Но миграция кажется сложной и требует большой работы (например, регулярный импорт данных с сервера sql на nosql)
• У меня нет никаких знаний, я даже не знаю, какой из них использовать (первое, что я бы использовал, это Ravendb, потому что я следую за ayende, и это делается сообществом .net).
• У меня может быть кое-что, что нужно изменить в моей модели, чтобы мой объект нормально работал с базой данных nosql

Загрузить все мои объекты PricingGrid в память (в статическом IEnumerable)

• Это может быть проблемой, когда моему серверу не хватит памяти для загрузки всего
• Я мог бы изобрести колесо (индексы ...), изобретенное провайдерами NoSQL

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

.net 3.5, SQL Server 2005, Windows Server 2005

Answer 1

Перенос ваших данных из SQL - это только первый шаг. Переход к хранилищу документов (например, RavenDB или MongoDB) также означает, что вам необходимо:

• Денормализация ваших данных
• Выполните проверку схемы в вашем коде
• Обработка параллелизма сложных операций в вашем коде, поскольку у вас больше нет транзакций (по крайней мере, не так)
• Выполнять откат в случае частичной фиксации (изменения)
• В зависимости от ваших обновлений, операций чтения и сетевой модели вам также может потребоваться обработка конфликтов

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

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

Нереляционные базы данных - это инструменты для конкретной работы (независимо от того, как они их продают), если они вам нужны, обычно это происходит потому, что ваши данные плохо вписываются в реляционную модель или если вам нужно распространять свои данные. данные на нескольких машинах (размер или доступность). Например, я использую MongoDB для приложения для управления заданиями с высокой пропускной способностью и интенсивной записью. Он централизован, а данные очень временные, поэтому приемлема «стоимость» низкой долговечности. Это не похоже на ваш случай.

Если вы предпочитаете использовать решение NoSQL, возможно, вам следует попробовать использовать Memcached + MySQL (InnoDB), это позволит вам получить преимущества в скорости кеша в памяти (в виде демона memcached). плагин) с базовой защитой и возможностями СУБД (MySQL). Это также должно облегчить миграцию данных и несколько уменьшить количество изменений, необходимых в вашем коде. Я сам никогда этим не пользовался, обнаружил, что мне нужен NoSQL по причинам, которые я изложил выше, или я могу оптимизировать СУБД с использованием хранимых процедур, индексов и табличных представлений способом, достаточным для моих нужд.

Answer 2

Asaf предоставил отличную информацию о том, как использовать NoSQL и когда это наиболее уместно. Учитывая, что вашей главной заботой была производительность, я склонен согласиться с его мнением - вам потребуется гораздо больше времени и усилий для принятия совершенно новой (и совсем другой) платформы хранения данных, чем для того, чтобы обмануть ваш кластер SQL Server. Тем не менее, мой ответ в основном касается части «как» вашего вопроса.

Устранение недоразумений:

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

2. Параллельность / транзакции - Транзакции возможны как в Монго, так и в Равене, они просто выполняются по-разному. Один из присущих Raven способов это делает, используя ORM-подобный шаблон «единицы работы» со своими RavenSession объектами. Да, ваша проверка данных должна выполняться в коде, но вы все равно должны делать это там. По моему опыту, это слишком раздутый мошенник.

Как:

1. Установите Raven или Mongo на основной сервер, запустите его как службу.

2. Создание или расширение существующего приложения, использующего базу данных, которую вы собираетесь портировать. Это приложение нуждается во всех модельных классах / библиотеках, для которых база данных SQL обеспечивает постоянство.

   а. В вашем «слое данных» у вас, скорее всего, есть класс репозитория. Извлеките интерфейс из этого и используйте его для создания другого класса репозитория для вашего постоянства Raven / Mongo. Обе базы данных имеют много хорошей документации для использования их API для проталкивания / извлечения / обновления изменений в графиках документов. Это чертовски просто.

   б. Загрузите ваши данные SQL в объекты C # в памяти. Вытяните ваши объекты верхнего уровня (только сущности) и загрузите их внутренние коллекции и связанные данные в память. Ваш репозиторий, вероятно, уже делает это (например, при извлечении объекта Order убедитесь, что в память загружены не только его свойства, но и связанные коллекции, такие как Items.

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

3. Как только ваши данные перенесены, поиграйте с ними и убедитесь, что вы довольны. Возможно, вы захотите немного изменить свои модели приложений, чтобы настроить способ их сохранения в Raven / Mongo - например, вы можете создавать документы верхнего уровня Orders и Items и просто использовать ссылочные значения (во многом как отношения в системах RDBMS). Однако, обратите внимание, что это противоречит принципам и производительности NoSQL, поскольку теперь вам нужно дважды нажать на БД, чтобы получить Order и Items.

4. Если все устраивает, осколите / скопируйте ваши серверы mongo / raven через оставшиеся доступные серверные блоки.

Очевидно, что есть тонны мелких деталей, которые я не объяснил, но это общий процесс, и большая его часть зависит от приложений, уже использующих базу данных, и может быть непростой, если с ней разговаривают несколько приложений / систем.

Наконец, просто чтобы повторить сказанное Асафом ... узнайте как можно больше о NoSQL и его лучших вариантах использования. Это удивительный инструмент, но не идеальное решение для всей сохранности данных. В вашем случае постарайтесь действительно найти узкие места в вашем текущем решении и посмотреть, можно ли их решить. Как говорит один из моих системных парней, «технология ради технологии - это чушь собачья»