Можно ли использовать NoSql для отчетности в этой ситуации?

Question

Ситуация

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

1. Основные исходные данные (CSV-файлы) поступают из другого приложения и фактически представляют собой отчеты о текущих транзакциях и связанных с ними оценочных расчетах на основе движений рынка. Это фиксированный источник и не изменится. Число строк отчетов может варьироваться от скудных 1,5 тыс. Строк до более 65 тыс. Строк. Не очень большие объемы данных, но это довольно линейный рост. Есть несколько других вспомогательных источников данных.
2. Форматы отчетов достаточно согласованы, однако содержимое отчета может быть динамичным. то есть большинство отчетов позволяет бизнесу решать, какие дополнительные столбчатые данные они хотели бы видеть, основываясь на бизнес-требованиях.
3. Отчетность, как это происходит в данный момент, включает в себя объединение и нарезание кубиками вышеупомянутых отчетов; в этом случае подумайте о точках, графиках, агрегациях, дополнительных вычислениях и т. д. Здесь есть некоторые сложные вещи, о которых я мало что знаю.
4. Это не транзакционная система, а скорее система управления рисками, поэтому существует предполагаемая и ожидаемая задержка с использованием исходных данных. Это будет в первую очередь для чтения.
5. Отчетность, как правило, относится только к текущему дню (наиболее важно), и необходимо вести историю предыдущих прогонов для каждого изменения в исходных данных (перечисленных в № 1) для дальнейшего анализа.
6. Это не простое приложение, но я чувствую, что Excel недостаточно хорошо и быстро масштабируется (шесть месяцев назад это была мечта, и она была). Есть слишком много скрытых бизнес-правил, которые известны немногим, и прохождение этого упражнения / перезаписи заставит всю эту поверхность. У нас слишком много автобусных факторов с точки зрения бизнеса и развития.
7. В целом решение должно обслуживать динамические отчеты или, скорее, динамическое представление данных. По сравнению с Excel, я думаю, что скорость на самом деле не является проблемой (я предполагаю, что мое решение будет быстрее) - однако, если нужно использовать действительно динамические запросы, их нужно выполнить за разумное время (<1 минута).

Почему я решил использовать NoSQL?

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

Основной причиной, по которой я рассматривал NoSQL, были исходные данные. Хотя фактический формат (файлы csv) не имеет значения, динамическая природа данных в терминах динамических столбцов может показаться, что подход на основе SQL будет строго ограничен и негибок, поскольку структуры таблиц довольно статичны. Документы NoSQL, однако, могли бы справиться с этим.

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

Последняя причина, и несколько эгоистичная, я хочу попробовать что-то другое.

Я полностью согласен с тем, что я не думал об этом во всех деталях, поэтому я и задал вопрос, поскольку знаю, что упускаю некоторые очень важные аспекты для рассмотрения. Если решение на основе SQL является более подходящим, можете ли вы разработать на основе 6 перечисленных пунктов.

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

Answer 1

Ключевой вопрос - как будут определены отчеты.

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

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

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