Мы планируем обслуживать аналитику для нашей платформы.На данный момент данные находятся в реляционной базе данных, и текущая мелкомасштабная аналитика работает поверх этих реляционных данных.Большинство данных аналитики предварительно рассчитаны для уменьшения задержки.
По мере роста мы наблюдаем увеличение объемов данных с экспоненциальной скоростью, и аналитика также становится более динамичной (что затрудняет предварительные вычисления).
Проблема, с которой мы сталкиваемся, заключается в том, как эффективно масштабировать без обновления архитектуры.Чтобы добавить больше контекста, у нас есть ~ 30 таблиц, из которых 10 таблиц имеют строки ~ 50M и ~ 50 столбцов, а остальные меньше по количеству столбцов и количеству строк.Наши аналитические запросы выполняются на этих больших таблицах и объединяют 2-3 таблицы в случаях.В настоящее время из-за небольшого объема данных все находится в пределах, но не будет масштабироваться в будущем.
Наши мысли решить эту проблему,
Свести данные в 10 больших таблицах в1-2 таблицы, в которых наши объединения будут исключены
- Это увеличит количество строк и столбцов в сплюснутых таблицах, а задержка запроса также будет высокой
- Будут сгенерированы ненужные данные
- Обновления в этих таблицах будут очень медленными
Использование шардинга с подходом 1
- Может помочь в задержке запроса
- Наше распределение данных даже не приводит к большой загрузке некоторых разделов / сегментов и может составлять ~ 40% от полного объема данных.
Поместить данные в NoSQL /Колоночное решение и опираться на его сильные стороны эффективного поиска на уровне столбцов
Я знаю, что без контекста и дополнительной информации, это может показаться неопределенным или общим вопросом, но я предоставляю сутьтвоя проблема.Я надеюсь получить указания или указатели от сообщества, которые являются экспертами в управлении базами данных или сталкивались с подобными ситуациями.