База данных для хранения большой таблицы журналов

Question

У нас есть сервер API, который обслуживает около 500 000 запросов в день. Мы хотим сохранить все эти правила в базе данных, чтобы иметь возможность анализировать данные. Мы регистрируем такие вещи, как:

• Кто сделал запрос
• Сколько времени это займет
• Дата и время
• Http код ответа
• Что апи ресурс просил (URL)
• кэширования данных ответа или нет (BOOL)
• +++

Мы хотим сохранить эти журналы в течение 3 месяцев, что приведет к примерно 45 000 000 записей в этой базе данных. Когда записи старше 3 месяцев, они удаляются.

Хранение этих 45 миллионов записей в базе данных sql возможно, но тогда очень медленно выполнять любой анализ этих данных. Мы хотели бы провести обширный анализ, например: сколько запросов сделал пользователь сегодня, по сравнению с тем же днем ​​на прошлой неделе? Сколько процентов запросов провалилось сегодня по сравнению с каким-либо другим днем? См. Диаграмму тенденций, показывающую, идет ли число запросов вверх или вниз. См. 10 лучших ресурсов, запрашиваемых в данный момент времени. Вы понимаете это - мы хотим иметь возможность делать все подобные анализы.

Можете ли вы дать какие-либо рекомендации относительно того, где хранить эти журналы, чтобы иметь возможность делать такой анализ в реальном времени (или в режиме реального времени)? Любая база данных nosql, которая может быть хороша для этого? Azure? Я вижу, что есть что-то, называемое azure sql datawarehouse, может ли это быть использовано для этого? Я рассмотрел Microsoft Power Bi, который, вероятно, будет полезен для анализа этих данных, но где я храню данные.

Я бы очень признателен, если у кого-то есть предложения для меня.

Answer 1

Power BI потенциально является хорошим решением для вас. Он фактически закручивает экземпляр служб SQL Server Analysis Services в памяти, который фактически является «хранилищем данных OLAP». Требования к инфраструктуре минимальны по мере разработки в бесплатном инструменте PBI Desktop и публикуются в облаке Microsoft для пользователей веб-сайтов PBI.

Есть лимиты для данных, которые могут быть опубликованы - см. Ссылку ниже. Обратите внимание, что PBI использует очень эффективное сжатие Vertipac, поэтому наборы данных, как правило, намного меньше, чем ваши необработанные данные.Я часто вижу 10k - 50k строк на MB, так что 45m должны быть достижимы с одной лицензией Pro. Безжалостно отфильтруйте список столбцов в PBI Desktop, чтобы оптимизировать это.

https://powerbi.microsoft.com/en-us/documentation/powerbi-admin-manage-your-data-storage-in-power-bi/

С PBI Pro лицензии вы можете обновить ежечасно, до 8 раз в день:

https://powerbi.microsoft.com/en-us/documentation/powerbi-refresh-data/

базы данных Строительство SQL и/SSAS решений OLAP была хорошая карьера для меня более последние 20 лет. Это решение «Rolls Royce», если у вас есть время и деньги. Но через 20 лет я все еще учусь, поскольку это технически сложная область. Если у вас еще нет этих навыков, я предлагаю Power BI стать более продуктивным путем.

Answer 2

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

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

only Способ получения отчетов в режиме реального времени заключается в создании отчетов поверх базы данных OLTP. Если вы можете жить с небольшой задержкой, большинство мест предпочитают перестраивать свои кубы на ночь, что обеспечит почти мгновенные отчеты о 24-часовой задержке.

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