Evgen Kostenko "How to process 80 million events per day and build relational graphs with Postgres"
Download as PPTX, PDF0 likes263 views
The document discusses processing 80 million events per day and building relational graphs using PostgreSQL. It covers the necessity of processing events, different storage models for hierarchical data, and architectural considerations including optimistic concurrency control. Key lessons include the importance of aligning database support with data models, recognizing scalability limits, and the need for careful data analysis.
Evgen Kostenko "How to process 80 million events per day and build relational graphs with Postgres"
- 1. How to process 80 million events per day and build relational graphs With POSTGRES Evgen Kostenko SPS Commerce
- 2. 2 AGENDA • Why we need process events • Storing graphs • Models for hierarchical data • Building Architecture 1 • Building Architecture 2 • Lessons learned
- 4. 4
- 5. DESIGN 5
- 6. REAL LIFE 6
- 8. EVENTS 8
- 9. • Monitoring distributed systems • Route individual call across different services EVENTS VALUE 9
- 10. ROUTE INDIVIDUAL CALL ACROSS DIFFERENT SERVICES 10
- 11. DESIGN 11
- 12. EVENT 12
- 15. STORING GRAPHS IN AWS 15
- 16. STORING GRAPHS IN AWS 16
- 17. MODELS FOR HIERARCHICAL DATA 17
- 19. • Adjacency List • Path Enumeration • Nested Sets • Closure Table SOLUTIONS 21
- 20. • Naive solution nearly everyone uses • Each entry knows its immediate parent ADJACENCY LIST 22
- 21. • Store chain of ancestors in each node PATH ENUMERATION 23
- 22. • A comment’s left number is less than all numbers used by the comment’s descendants. • A comment’s right number is greater than all numbers used by the comment’s descendants. NESTED SETS 24
- 23. CLOSURE TABLE 25
- 24. CHOOSING THE RIGHT DESIGN 26
- 25. CHOOSING THE RIGHT DESIGN 27
- 26. 28 Joe Celko’s Trees and Hierarchies in SQL for Smarties 2012
- 29. EVENTS STREAM 31
- 30. EVENTS STREAM 32
- 33. OPTIMISTIC WRITES 35 Optimistic concurrency control (OCC) is a concurrency control method applied to transactional systems such as relational database management systems and software transactional memory. OCC assumes that multiple transactions can frequently complete without interfering with each other. While running, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read. If the check reveals conflicting modifications, the committing transaction rolls back and can be restarted
- 37. CHOOSING THE RIGHT DESIGN FOR CONCURRENT WRITES 39
- 38. 40
- 41. LESSONS LEARNED 43 • If database support you data model it’s not means that it optimized for you case. • Old approaches still work • Scalability limit exist and sometimes the are less than number of instances/cores that you have • Analyze you data • Sometimes react faster means process slowly
Editor's Notes
- #3: Сегодня мы с вами рассмотрим историю создания одного сервиса от зарождения идеи, зачем это было придумана и какая проблему мы пытались решить, до того как этот сервис стал приносить нам пользу и закрепился в нашей инфраструктуре как незаменимая часть.
- #4: В современном мире одна из важных и сложных проблем построения больших, распределенных систем это организовать правильно коммуникацию между сервисами. Что только люди не придумывали для того чтобы это упростить. Давайте не будем углубляться в древнейшие времена и не будем говорить про те эпохи когда не было сети или изобретали TCP и TPC IP и даже не будем говорить о том когда был SOAP (хотя он наверно до сих пор где то есть). Вспомним сразу REST API. Сначала все передавали по JSON потом появились более оптимальные форматы данных Protobuf, Tref где можно было указывать типы, делать базовый RPC. Вариантов здесь много но я хочу лишь сказать что это довольно не простая задача даже в современном мире
- #5: Масла в огонь еще подливают микросерввисы, которыми уже никого не удивишь они давно укоренились и каждый уважающий себя архитектор проектирует новые системы с использованием микросервисов и задача становиться еще сложнее в результате мы получаем сложности в понимании как взаимодействуют микросервисы друг с другом. А иногда границы начинают стираться и внутри огромной системы микросервисы которые были частью больших сервисов выходят за рамки своего сервиса и начинают взаимодействовать друг с другом.
- #6: Вот так приблизительно выглядит дизайн приложения как мы его проектируем и разобраться в подобной схеме не очень то и сложно. У кого есть такие схемы на проектах? У кого есть такие схемы которые показывают взаимодействие всех сервисов внутри систем компании и внешних систем?
- #7: Схемы это круто, но в реальности все становиться намного сложнее и схема взаимодействия выглядит приблизительно так. Как же решить эту проблему как распутать этот клубок?
- #8: Одно из самых очевидных решений это заставить каждый сервис слать события о том что у них происходит и построить систему которая на основе этих событий будет нам собирать, валидировать, очищать, делать трансформацию и агрегацию в удобный для нас формат где мы всегда можем знать что у нас происходит в системе в целом так же и отдельно для каждой цепочке коммуникации которая произошла внутри всей системы.
- #9: т.е. грубо говоря будет распутывать для нас эту паутину и превращать в ту самую удобную и понимаемую схему взаимодействий внутри системы.
- #10: Вот 2 главные проблемы которые мы попытались решить с помощью ивентов Мониторинг распределенных систем И возможность проследить каждый запрос который происходит внутри системы от его начала до его завершения
- #11: И с мотниторингом все более ли менее понятно, а вот с тем чтобы проследить цепочки запросов, эта задача становиться немного сложнее. Потому как на теперь нужно заставить все сервисы договориться друг с другом каким образом они будут сообщать нам в ивентах о том кто кого вызывает.
- #12: Мы решили что каждый новый сервис будет присылать ссылку на предыдущий и предыдущий должен при запросу к каждому новому сервису сообщить о том что именно он его вызывает. Проблему можно было решить с помощью введения уникального id внутри цепочки вызовов, но в таком случае мы бы могли восстановить цепочку вызовов только отсортировав события по времени но в таком случае мы бы теряли информацию о тех случаях когда процесс распадается на нескольно, а потом объединяться снова что было для нас очень важно
- #13: Ивенты в нашем случае это обычные JSON документы в которых есть список ссылок откуда данный запрос пришел. Например если это очередь и сервис делает некоторую агрегацию сообщений он укажет несколько ссылок. В поле метаданных сервисы могут писать любую свою внутреннюю информацию, статусы и на основе нее мы строим наши отчеты
- #14: В итоге все эти данные в ивентах сама по себе стали очень похожи на граф потому мы задались а как же мы будем хранить и собирать этот граф
- #18: Когда мы говорим про граф то всегда представляем что то такое это огромное количество связей которые так или иначе связаны друг с другом. Но когда мы попытались записать наши данные в графовую базу данных так вышло что у нас получилось очень много маленьких не связанных друг с другом графов которые были достаточно глубокими 10-50 вершин но в среднем не достаточно большими в ширину, хотя были и исключения и большинство графовых баз данных показали достаточно низкую производительность на этапе чтения этих графов
- #21: Мы решили сделать сделать что свое