Как сделать некоторые отчеты с Rails (с выделенной БД)

Question

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

• Какую СУБД выбрать?
• Когда мне следует хранить данные в базе данных отчетов?
• Должна ли схема базы данных рабочей базы данных и базы данных отчетности быть идентичными?

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

В настоящее время это неопределенный вопрос, но любая подсказка будет высоко оценена.

Спасибо!

Answer 1

Работа в обратном направлении

Начните с того, что конечные пользователи хотят отчитываться или как они хотят / должны визуализировать данные.Если у вас есть некоторые понятия, а затем начать работать в обратном направлении к тому, как достичь этих целей.Исходя из предположения, что это должна быть реплицированная копия в СУРБД, исключаются несколько разумных возможностей.

Создание интерфейса реального времени

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

Помните, что репликация не проста или без ее собственного набора проблем.

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

Пакетирование

С другой стороны, если отчетность подпадает под схему отправки стандартизированных отчетовс небольшим взаимодействием, я не обязательно рекомендовал бы вернуться к RBDMS.В этом случае результаты объединяются, агрегируются, объединяются и т. Д. Один раз.Платить за накладные расходы на индексирование и хранение в RBDMS не стоит.

Пакетные движки, такие как Hadoop , будут масштабироваться горизонтально (много меньших машин вместо нескольких огромных машин), поэтому обрабатывать большие объемыданные экономичны.

Пакетная доставка в RBDMS или K / V Store

Это также полезный путь, если требуется много вычислений, чтобы сделать записи более значимыми для механизма отчетов.Кроме того, записи могут быть денормализованы перед их сохранением в подсистеме хранения отчетов.Затем денормализованные или простые результаты будут отправлены в хранилище ключей / значений или RBDMS, чтобы упростить отчетность и повысить производительность за счет задержки, вычислений и, возможно, хранения.

Персональный совет

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

Answer 2

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

Возможно, вы захотите взглянуть на Таблицу http://www.tableausoftware.com/ и другие доступные.

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

Тип базы данных -> приходится выбирать в зависимости от используемых служб отчетов, хотя я думаю, что mongo не поддерживается ни одной из служб отчетов, предпочтительным является mysql.

Если есть только один или два отчета, вы можете просто построить их на рельсах