Подходит ли для этого варианта использования БД, ориентированная на документы?

Question

У меня есть большая, сложная, устаревшая реляционная база данных, содержащая наши пользовательские данные. Я хочу создать приложение, которое будет сегментировать группы пользователей по различным критериям ( покажет мне всех, кто весит более 200 фунтов и носит красную рубашку ). Запросы будут состоять из предопределенных параметризованных предикатов (подумайте о пользовательском интерфейсе правил сообщений в outlook или gmail). Полностью специальные запросы будут редкими.

Построение SQL-запросов к исходным данным нецелесообразно из-за сложности устаревшей схемы.

Первой, наивной идеей может быть денормализация данных, которые будут использоваться для сегментации, в очень широкую таблицу в СУРБД:

id  | hat size | shirt color | weight | ....
123 | 7        | blue        | 175    | 
456 | 6        | red         | 205    | 

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

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

Так вот мой вопрос:

Подойдет ли ориентированная на документы база данных, такая как MongoDB или CouchDB, для этого варианта использования?

У меня нет огромных объемов данных (10 миллионов строк, 300 или около того столбцов в гипотетически денормализованной таблице). Пишет довольно редко (10000 в день). Запросы будут выполняться несколько раз в день, а время ответа должно быть в секундах.

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

Бонусный вопрос _ Оправдывают ли преимущества документа db затраты на внедрение новой технологии в наших центрах обработки данных? _

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

Answer 1

Недавно мы начали «встраивать» NoSQL в наш технологический стек, но я начал с использования ограниченных коллекций через Mongo для простой регистрации, чтобы почувствовать технологию и убедиться, что она надежна и, что важно, обеспечитькод приложения имеет смысл при использовании NoSQL в качестве сохранения позже.То, как данные и объекты сохраняются, изменится с этим движением, и это тоже необходимо учитывать.

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

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

Кстати, не задумывались ли вы об использовании индексированных представлений для «нормализации» ваших данных и выбора из них?Просто мысль.

Надеюсь, это поможет!