Comments 7
Спасибо за статью! Как решаете вопрос с мониторингом такого пайплайна?
Читая статью, постоянно вспоминал анекдот:
Идет научная конференция. На ней присутствуют делегации из Америки, Англии
и России. Выстпают американцы:
- Мы можем заменить человеку палец.
- Браво! Браво!
Англичане:
- А мы можем заменить человеку глаз.
- Браво! Браво!
Русские:
- А мы гланды вырезаем.
- У-у-у-у-у
Проходит десять лет.
Выступают американцы:
- Мы можем заменить человеку руку.
- Браво! Браво!
Англичане:
- Мы можем заменить человеу голову.
- Браво! Браво!
Русские:
- А мы гланды вырезаем...
- У-у-у-у-у
- ...через жопу
- Браво! Браво!
Проходит еще десять лет.
Выступают американцы:
- Мы можем заменить человеку сердце.
- Браво! Браво!
Англичане:
- Мы можем заменить человека полностью.
- Браво! Браво!
Русские:
- А мы гланды вырезаем...
- У-у-у-у-
- ...через жопу...
- У-у-у-у-
- ... автогеном
- Браво! Браво!
Вот что вы сказали про бизнес:
У нас есть заказы (orders), которые создаются в лабораториях. У этих заказов есть различные этапы (statuses) их обработки, бизнесу интересно понимать скорость обработки этих заказов, т.е. время перехода из одного статуса в другой, соотношение количества результатов заказов к общему количеству.
То есть речь не идёт о больших данных. Скорее всего, общее количество заказов за все время деятельности компании меньше 100 миллионов. Вероятно - сильно меньше. ))) И в ближайшие годы количество данных не вырастет в 100 раз.
А на таком объёме данных такие отчёты можно делать с помощью Aurora (https://aws.amazon.com/ru/rds/aurora/), которая как раз прекрасно подходит для записи отдельных транзакций. Появился новый заказ / изменился статус - сразу записали в базу. То есть можно выкинуть большую часть промежуточных элементов, в результате чего вся система в целом станет намного проще и стабильнее.
Ну и маленький бонус для бизнеса - обновления данных в отчётах он увидит спустя секунды, а не часы.
Заказы это не единственные данные, которые хранятся у нас. Здесь это приведено лишь для примера. Сущностей в Redshift гораздо больше и, если заказов действительно меньше 100кк, то вот всех связей с ними, которые тоже нужны для аналитики, уже как раз превышают это количество.
Бизнесу не нужно сиюминутное обновление данных. Именно поэтому мы можем позволить себе задержу в период времени, который составляет один час в текущий момент и вряд ли поднимется выше на текущем решение.
всех связей с ними, которые тоже нужны для аналитики, уже как раз превышают это количество
О каких "связях" вы говорите? Справочники (клиент, лаборатория, исполнитель и т.д.)?
А про время обновления - я и не говорил, что бизнесу сильно нужно обновление за секунды. Это - просто "бесплатное приложение". Но, поверьте, им все равно будет приятно, если данные обновляются быстро. )))
Заказы в нашей системе это сложная структура, которая содержит множество различных связей, кроме банальных: клиент, исполнитель и т.д. Я, к сожалению, не могу вам описать все из-за NDA идеологических соображений. Но, поверьте, их достаточно, чтобы не использовать Mysql, Postgres.
Но, поверьте, им все равно будет приятно, если данные обновляются быстро. )))
Не могу вам поверить, потому что бизнес говорит нам другое.
Анекдот, кстати, классный.
Заказы в нашей системе это сложная структура, которая содержит множество различных связей, кроме банальных: клиент, исполнитель и т.д. Я, к сожалению, не могу вам описать все из-за
NDAидеологическихсоображений
Сильно сложнее, чем вот это?
https://dynamicsdocs.com/nav/2017/w1/table/sales-line
Это таблица строк заказов в MS NAV / Business Central, с которым я работаю последние годы и, к счастью, структуру которого я могу свободно описать. :)))
Но, поверьте, их достаточно, чтобы не и спользовать Mysql, Postgres.
Montgomeryg сама по себе сложность структуры данных не влияет на выбор - колоночная или строковая база данных. Колоночные базы имеют как свои достоинства, так и недостатки. И в вашей статье как раз хорошо описаны недостатки. :)))
Если же мы говорим о размере данных... Redshift на небольших объемах данных (миллионы - десятки миллионов строк) может обрабатывать запросы медленнее, чем обычная база с построчным хранением на одиночном сервере. MPP (много нод) вносит свои оверхеды.
А лимиты на просто объем хранимых данных обычно достаточные.
An Aurora cluster volume can grow to a maximum size of 128 tebibytes (TiB)
...
For Aurora MySQL, the maximum table size is 64 tebibytes (TiB). For an Aurora PostgreSQL DB cluster, the maximum table size is 32 tebibytes (TiB).
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Limits.html
BI с Redshift от ETL до бордов