архитектура данных и программного обеспечения для расчетов от года 0 до года n

Question

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

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

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

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

Я видел в крупномасштабных системах, таким образом, вид работы разбивается на временные интервалы, например, сводные таблицы за неделю, месяц, год. Мне особенно интересно, есть ли общая схема проектирования для решения этой проблемы.

Answer 1

Существует, вероятно, только один общий подход - сплит работа.

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

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

Первое, что вы должны знать, это ваше отношение чтения: записи и тип запросов, которые вы хотели бы получить.запустить.

Answer 2

Я бы агрегировал в БД, поскольку это, как правило, очень хорошо.

Посмотрите на OLAP (против OLTP ) дизайн базы данных.

Answer 3

Я бы пошел с базой данных SQL (PostgreSQL).СУБД довольно быстро справляются с этими задачами:)

Извлечение всей истории в виде объектов ORM и последующее ее суммирование, приложение может не работать в долгосрочной перспективе.Вам придется работать с SQL-запросами, которые выполняют большую часть статистики внутри СУБД.Вы можете, конечно, по-прежнему использовать ORM для отображения и редактирования объектов.

Я думаю, что решение должно быть вполне безопасным с ожидаемым объемом данных, и СУБД может быть масштабирована с надлежащим индексированием и большим объемом памяти.

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