Переход от реляционной базы данных к большим данным

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

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

Изучая способы решения этой проблемы, мы рассмотрели инструменты, доступные в облачной платформе Google, такие как Dataproc и Dataflow, а также решения NoSQL. Однако мне трудно понять, как мы можем применить наше текущее решение для любых этих решений.

В настоящее время приблизительная идея нашей схемы данных выглядит следующим образом:

User table
- id
- name
- email

Profile table (web browser/device)
- id
- user id
- user agent string

Session table
- id
- profile id
- session string

Action table
- id
- session id
- action type
- action details
- timestamp

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

Мой вопрос в том, насколько я правильно понимаю, как правильно применять эти инструменты? Или есть лучшие решения? Стоит ли даже рассматривать возможность перехода от MySQL? И если нет, то какие решения доступны, которые позволят нам, возможно, предварительно обработать/сформировать отчетные данные в фоновом режиме?

Ответ 1

Предполагая, что значения таблиц sessions и actions не обновляются и только вставляются. Лучшим способом было бы разделить базы данных на две части. Храните MySQL DB для таблиц user и profile и используйте BigQuery для actions и sessions.

Таким образом, вы следуете:

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

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

Ответ 2

Несколько вопросов/потенциальных решений:

Профиль! Если при этом одни и те же запросы обрабатывают базу данных, то оптимизация ваших запросов или кэширование некоторых результатов для ваших наиболее частых страниц может помочь разгрузить обработку. Тоже для настроек базы данных, ОЗУ и т.д.
Насколько велика ваша база данных? Если он меньше 64 ГБ, масштабирование до более крупного сервера, где база данных может вписываться в ОЗУ, может быть быстрой победой.
Как используются ваши данные? Если это чисто для исторических данных, вы можете потенциально уменьшить свои клики в таблицу поиска, например. действия за сеанс в неделю или на пользователя в неделю. Если данные сопоставляются за 5 минут/час, загрузка исходных данных и обработка их, как это, может также работать.
Вы можете денормализовать, например. объединить пользовательский агент | session | action type | details | timestamp в одну строку, но вы потенциально увеличиваете требования к хранилищу и время поиска.
Альтернативно, большая нормализация также может помочь. Прерывание строки пользовательского агента в собственной таблице уменьшит требования к табличным данным и может ускорить процесс.
Кажется, что ваши данные могут быть разделены/отложены пользователем, так что это может быть другой вариант.

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

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

Ответ 3

Если это практично, не храните огромное количество данных вообще!

Вместо этого суммируйте (агрегированные) фрагменты данных по мере их поступления, затем сохраните сводки.

Преимущества:

Возможно, потребуется на одну десятую столько свободного места на диске;
Отчеты, возможно, в 10 раз быстрее,
Может быть сделано в существующих РСУБД.

Недостатки:

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

Обсуждение сводных таблиц.