PostgreSql и получение бизнес-статистики в режиме реального времени приводит к слишком длинным запросам: решение?

Question

У нас есть национальное приложение, и пользователи хотели бы иметь точную статистику по некоторым таблицам.

Мы используем tomcat, Spring Ws и Hibernate.

Мы думали о многих решениях:

1. простой старый запрос для каждого пользовательского запроса.Проблема в том, что эти таблицы содержат миллионы записей.Каждый запрос займет как минимум много секунд.Решение никогда не использовалось.

2. фактическое используемое решение: создать триггер.Но это больно создавать и трудно поддерживать (без OO, без крутого EDI, без реальной отладки).Единственная вспомогательная часть - это возможность создать Junit Test на более высоком уровне, чтобы проверить ожидаемый результат.И для каждой отдельной статистики в таблице мы должны создать другой триггер для этой таблицы.

3. Использование кварцевого каркаса для консолидации данных через X минут.

Я узнал, что базы данных не предназначены для этих сложных и сложных запросов.

Лучше будет отдельное хранилище данных, оптимизированное для чтения только запросов.(OLAP ??) Но я понятия не имею, с чего начать с postGresql.(Pentaho - это решение или просто часть?)

1. Как мы можем извлечь данные из производственной базы данных?Используете экстрактор?
2. А когда? Каждую ночь?
3. Если это происходит периодически - Как нам удастся вести статистику почти в реальном времени, если данные просто сбрасываются в наше хранилище данных один раз в день?

Answer 1

«Я узнал, что базы данных НЕ предназначены для этих сложных и сложных запросов». Ну, тебе нужно отучиться от этого. База данных была разработана только для таких запросов. Я бы обвинял плохой дизайн программного обеспечения, которое вы используете, прежде чем обвинять основную технологию.

Answer 2

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

1. Массовая загрузка новых данных
2. Рассчитать новый статус [дельта], используя новые данные и существующий статус
3. Слияние / обновление статуса
4. Вставить новые данные в постоянную таблицу (при необходимости)
5. УВЕДОМЛЕНИЕ wegotsnewdata
6. Commit

StarShip3000 правильный, кстати.

Answer 3

Кажется, меня неправильно поняли.

Для тех, кто думает, что классическая база данных предназначена даже для обработки статистики в реальном времени с запросами на миллиарды данных, им, возможно, придется прочитать статьи о происхождении OLAP и почему некоторые люди пытаются разрабатывать продукты, еслиответ на вопрос о производительности был просто вопросом разработки.

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

Для тех, кто думает, что это просто проблема проектирования, я рад услышать их умныеОтвет (без триггера я знаю это) на простую проблему: представьте, что у вас есть 2 таблицы: сотрудники и телефоны.Сотрудник может иметь от 0 до N телефонов.Теперь предположим, что у вас есть 10 000 000 сотрудников и 30 000 000 телефонов.

Вы, конечные пользователи, хотите знать в режиме реального времени:
1 - среднее количество телефонов на пользователя
2-theсредний возраст пользователей, у которых более 3 телефонов
3 - среднее число телефонов для сотрудников, которые работают в компании более 10 лет

У вас есть потенциально 100 пользователей, которым нужна эта статистика в реальном времени нав любое время.

Конечно, любые запросы не должны занимать более 1/4 сек.