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

1: Всем привет.

2: Так, ну, собственно говоря, сегодня поговорим о том, какие, на наш взгляд, вообще проблемы есть. На самом деле. Это не секрет. Никому там америку не открою. Я думаю, большинство из вас знают про эти проблемы.

3: Мы сталкивались и, в принципе, наверное, даже кого-то они бесят, как меня, например. Но, в принципе, сегодня цель не просто поговорить, а в принципе, оценить вообще, а что с этим можно было бы?

4: То подделать. Ой, извиняюсь, что-то у нас тут с кликером, а он не работает.

5: А что происходит?

6: Он просто сам переключает.

7: Что происходит?

8: Батарейку надо поменять, да?

9: А вот вроде как-то странно. Да, да, да. Начал говорить про плохой пропор. Видите, сразу карма накрыла. Короче говоря, о чем сегодня мы поговорим, да, мы поговорим про архитектурные проблемы. У нас будет сегодня 2

10: Доклада. Мой доклад, он будет такой более обзорный. Ну то есть там, не переживайте, кишки тоже будут. Технические проблемы тоже будут. Но из за того, что тема достаточно обзорная. Ой, извиняюсь, обзорная, большая и объёмная. У нас будет 2 доклада. Мой доклад.

11: Будет 1. Я немножко, как Алексей у нас говорит, перережу ленточку. Следующий доклад после меня будет алексея Копытова, и Алексей расскажет уже кишки. Внутреннее устройство много будет. В принципе, как мы это

12: Делаем, что у нас происходит внутри там и так далее и так далее. Вот. Поэтому, если что, на 2 доклад очень рекомендую остаться и послушать. В принципе, посгрес достаточно популярная субд.

13: В принципе, из опенсорс. 1 из 2, наверное, да, опенсорс субд, наиболее популярных в мире, и майскюэль, да, по, растёт очень активно. Последние, ну, там, наверное, лет 10 точно, наверное, да. Ну.

14: В принципе, он растёт и больше вот признавался 4 раза за последние годы субд года таким сервисом, как db engine ну и в принципе, с чем это связано, это понятно, что либеральная лицензия.

15: С ним можно делать все, что угодно продавать, перекрашивать, чем пользуются все, в том числе и мы, расширяемость, да, это что сделало постгрес таким популярным и, наверное, 1 из важным, 1 из важных факторов является то, что постгрес сам по себе

16: Является универсальной субд с большим сообществом. То есть сообщество в мире у нас огромное. Фактически. Ну да, посмотрите даже на сегодняшнюю конференцию. У нас там сегодня уже, по моему, перевалило за 500 человек только оффлайн онлайн даже не знаю, сколько нас присутствует. То есть это достаточно популя

17: База данных, особенно у нас в стране, но у неё есть определённые проблемы. Несколько лет назад Александр Коротков, котор да, приводил вот такой вот слайдик, это из его презентации.

18: Про его продукт ролл диби, и он описывал там 10 проблем, которые, на его взгляд, являются, ну, скажем так, застарелыми, да, то есть, вот, в принципе, на тот момент аналитика была вот такая вот. То есть, как видите, некоторые проблемы, там 20 лет.

19: Не решаются, ну, проблемы веранда, да, там фолловер, там, и так далее, и так далее. И, в принципе, какие-то проблемы из этого списка, в том числе сегодня буду поднимать я, ну, не все, конечно, да, но что-то будет тоже пересе.

20: Мы на самом деле будем говорить ещё про много, а хочется вернуться назад, да, раз уж там я так начал немножко с исторической истории. В 17 году я рассказывал про то, как мы

21: Использовали посгрес в такой известной системе платон. Есть у меня такой грешок. Вот когда-то делал плохо нашим уважаемым дальнобойщикам. Ну честно, не хотел так вышло. Вот, но

22: Вопрос не в этом было интересно с точки зрения того, как использовался посгресс и какие нагрузки он на тот момент переваривал. И это было очень интересно. Почему? Потому что сейчас вот нас там много, да, тут 500 человек сидит.

23: И так далее, и посгрес является де факто стандартом в нашей стране, но и кажется, что так было всегда, но так всегда не было всего лишь там, там 8 9 лет назад посгрес воспринимался у нас в стране как нечто, ну такое.

24: Для фриков, да, извиняюсь, там для фриков, не для серьёзных систем, где-то там, для чего то каких-то второстепенных систем и был огромный скепсис и огромная проблема вообще, в принципе, перело.

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

26: Верить в посгрес, как интерпрайз продукт. И в принципе, это этот процесс пошёл. И если помните, то в 2016 году российский офис оракал.

27: Заметил, что что-то там на горизонте появляется, и написал аналитическую записку. Почему я про эту записку вспомнил, когда я в 17 году выступил там

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

29: Мы разрабатывали системы там и так далее. Вот. И он пришёл, говорит, слушай, там прилетело от заказчика по 1 системе, он не хочет погас использовать, он оркл хочет использовать и присылает мне письмо, письмо.

30: Аналитическая записка там тоже была от заказчика. Я читаю и вижу прям вот эту аналитическую записку. Там небольшая преамбула, а дальше копипастом все взято из аналитической записки оракл. И в чем была эта записка? Ну, основная цель её, она называлась почему?

31: Не является аналогом субд oracle, и там было очень много написано про то, что такое оракал, какие ключевые характеристики субд должны быть, по мнению офиса оракл российского да, офиса.

32: Oracle. И вот тут вот этот перечень, я специально его прям оттуда взял, скопипастил. Кому интересно, можете найти эту записку? Она, кстати, даже в хакер с прессом болтается. То есть в целом даже туда это долетело. Какие

33: Проблемы оракл подсвечивал на тот момент в постгресе. Напомню, это 2016 год. Он говорил, что погаси, в принципе, это не интерпрайз. Субд это какая-то ваша там вот подделка и

34: И какие технологии предлагалось ну как бы не то что внедрить в postgres, а какие технологии отсутствуют вообще в принципе в постгресе речь шла вот про your application cluster грид там параллельно.

35: Обработка запросов, ну и так далее, и так далее. Да, тут очень много букв. Можете это потом в презентации почитать более детально. Вот. Но, опять же, здесь вот есть такой вот блок, я специально его выделил, кото

36: Говорит, что оракл, говори, ну, предлагал, как, в том числе, некую, ну, такую вот не альтернативу даже, да, как некое такое превосходство над посгресом, наличие оракл экзадата и как

37: Некая такая вот синергия вот всех своих технологий он видел вот в этой экзадате, то есть в своей машине баз данных, то есть там есть и grid, и рег, и memory, и там много

38: Много, много всего, то есть все вот, вот, вот в этой машине. Поэтому я зациклился именно на этой истории, потому что это как некая такая синергия. И сегодня мы будем рассматривать проблемы посгреса из концепции вот этого письма и

39: Того, о чем тогда говорил оракл.

40: То есть, в принципе, а можно ли сделать экзадату на постгресе, да, вот если такой вопрос задать, он, может быть, покажется там глупым, да, может быть там неуместным. В принципе, мы его себе задали, я его

41: Тебе задал. Ну и, наверное, как бы получил такой ответ. Можно вопрос, зачем, в принципе, этот ответ, как бы на этот вопрос он лежит.

42: Не в том смысле, что надо вот прям сделать полную копию экзадата или там полную полностью скопировать все технологии оракла, что невозможно в принципе, да, и не нужно действительно, но зерно того, что использует оракл у себя внутри.

43: И какие технологии, какие подходы, какую архитектуру он использует зерно правды и как бы логики в этом есть. Поэтому мы начали отталкиваться именно от экзадате, от

44: Оракла, да, от этого письма и смотреть вообще. А что у нас болит? Ну, на текущий момент? У нас, в принципе, как бы, в pegas много чего болит, да, и опенсорсный погас он, в принцип,

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

46: Изменения, соответственно, возникает проблема обратной совместимости. Возникает множество проблем, связанных с портированием. И вообще, ну, это боль, да, для тех, кто работает с посгресом, он знает, что поменять то

47: Можешь много чего, а потом как, кто это будет поддерживать? И мы, как бы, вот я выделил вот здесь 3 основных таких проблемы. 1 проблема, это масштабируемость большая, да, block такой большой проблем, 2, 2 блок это производительность. Ну и

48: 3, это работа с большими объёмами данных и параллельными большим количеством параллельных пользователей. Если немножко раскрыть, что имеется ввиду под масштабируемостью. Ну, во первых, у нас есть определённые ограничения с горизонтальным масштабированием.

49: Да, у нас есть возможность масштабирования ридонли репликами, но опять же, там, возвращаясь к тому докладу, который я делал в 2017 году, у меня было 8 реплик и каскадная репликация в 1 цоде, во 2 было стольк.

50: Я вам скажу, мне было не очень удобно это все поддерживать. Ну, если откровенно, да, это прям боль. Вот. Поэтому горизонтальное масштабирование является

51: Прям вот как минимум неудобно, да, и как максимум, а как быть в целом с масштабированием, допустим, там редон ли нагрузки при большом количестве этих реплик? 2 проблема, копия данных, то есть опять же, когда у вас 1

52: Replica, 2 реплики. Все вроде нормально, но у вас когда 8 реплик, у вас это все реплицируется, у вас 8 Копий данных в другом соде такая же история. Это дорого, банально, дорого. Да, можно там какие-нибудь дорогие стореджи, дуплика.

53: Какой-нибудь там компрессии использовать, но все равно это дорого и репликация тоже не бесплатная. То есть у нас все-таки есть трафик сетевой, у нас есть ресурсы, которые эта репликация потребляет. Ну в общем это неудобно тоже компьютер.

54: У нас интегрированы, то есть у нас наш позго, это такой из мира, как Зверьков, да, как правильно это назвать то? Ну, то есть, когда у вас все вместе, да, такие продукты, которые у вас все вместе, в принципе, когда позго создавался, ну, об этом, наверное, вообще никто не думал, и

55: И в целом эта проблема, она оттуда ещё из девяностых, там, восьмидесятых годов. Вот. Ну и, соответственно, проблема какая? С компьютер стороджем в том, что вы не можете масштабироваться отдельно, вы не можете компьютер

56: Масштабировать вы не можете, сторс по масштабировать. У вас всегда вот все живёт одними такими большими блоками. Ну и 3, это проблема с терабайтными базами при выпадении какой-то ноды из кластера. Я думаю, кто с хавит кластерами там по 5 терабайт работал, хотя бы примерно представляет

57: Что это такое? Я как-то имел, скажем так, удовольствие 80 терабайтный кластер восстанавливать при выпадении мастера обратно, возвращать его как стенбай. Это было очень неприятно, я вам скажу, он убегал.

58: Ну, новый мастер убегал вперёд, я не успевал наливать, как бы, standby ноду. Вот. И это тоже очень неудобно. Это тоже как бы, проблема, производительность. Ну, отсутствие балансировки, проблема вообще с nvs си. Я немножко дальше рас.

59: ROE, что я имею ввиду. Ну, здесь в 1 очередь проблема инвестси при высокой конкуренции, когда у нас большое количество активных сессий, активных транзакций, мы у нас высокий комере, здесь у нас возникают проблемы, ну и, соответственно, узкое место в виде журнала транзакций, он у нас однопоточный.

60: А мы туда все коммитим с блокировками, вот, и так далее, и тому подобное. Работа с большими данными. Ну, здесь в 1 очередь, что все знают проблему. 1 процесс, 1, 1 коннект, 1 процесс.

61: Соответственно, чем больше коннектов, больше процессов, больше деградация, пуллеры наше все и так далее, и тому подобное. Дальше паралелизации запросов в рамках 1 инстанса, да, о, начиная с 9 6 начал параллелить все внутри 1 инстанса.

62: Но, в принципе, мы можем параллелиться только в рамках 1 ноды. То есть за рамки там нескольких нод мы выходить не можем, соответственно, и отсутствие возможности работы, как та система. То есть, если

63: То аналитика, да, можно там что-то выносить, улодить на ридонли реплику, но это тоже кто работал знает, что там куча ограничений, деградация мастера при при нагрузке реплик и так далее и тому подобное. То есть прелести мног

64: Теперь немножко проговорим про масштабируемость как это выглядит сейчас, да, в принципе то, о чем я говорил, масштабирование сейчас погаса выглядит, есть primary, у нас узел есть standby, узел у нас между ними, репликация ну и

65: Все прелести репликации у нас тоже могут быть, то есть и могут быть задержки, и копятся валы. И время, необходимое для создания стендбая увеличивается, потому что надо с бэкапом наливать или звал джи. Вот.

66: Какого-нибудь, собственно говоря, это все, ну, известные проблемы и, в принципе, всем понятные, почему я не люблю шардинг, это как бы моя вкусовщина.

67: Да, это, это моя вкусовщина из опять же прошлой жизни вот и я не люблю шардинг и считаю, что шардинг для посгреса, для otp нагрузки не рабочая схема для аналитики да, можно.

68: Использовать сайтус в принципе тот же самый да, который показывает, что это можно для alltpms действительно настоящий шардинг, а не просто роутинг допустим в какой-то shared на уровне какого-то прокси это на мой?

69: Мой взгляд, большая проблема. У тебя любая распределённая система имеет ряд дополнительных сложностей. То есть, во первых, это сразу же вопросы с транзакциями. Как, как нам быть с транзакциями? И вообще с глобал консистенси в рамках всего кластера дальше

70: У нас, соответственно, кросс джойн шарды. Ой, извиняюсь, кросс шард джоины возникают, да, и, соответственно, тоже не добавляет какого-то, какой-то простоты, эксплуатации. Дальше у нас сюда добавьте изменение модели.

71: Данных. Любое шардирование потребует изменения модели данных, изменения работы приложения и, соответственно, у нас возникают перекосы, потому что мы можем даже хорошо распределить по первичному ключу. К примеру, размазав все по нодам. Но если

72: У нас какой-то тостик уехало немножечко больше данных на какой-то, на какую-то ноду. Ну вы это уже вряд ли отследите, и там это отловить будет очень сложно. Дальше. Ну что можно ещё про это сказать? В принципе понятные форки, которые сущест.

73: На российском ой, извиняюсь на международном рынке это сайтус гигабайт как roach диби да, вы можете посмотреть и в принципе убедиться то, что все это ломает совместимость с посгресом, то есть вы не можете использовать этот, этот work.

74: Например, под 1 с вот, или там под какое-то ещё приложение, которое на российском рынке популярно, у вас возникнут куча проблем, потому что это все требует дополнительных каких-то доработок, усилий в приложении. Мы же хотели сохранить полностью

75: Совместимость и пошли, в принципе, проторённой дорожкой. Я сегодня буду говорить, мы, но вы должны понимать, что я буду говорить, в том числе про опенсорс, потому что все, о чем я буду сегодня говорить, ну, большинство того, о чем я буду говорить, доступно в опенсорсе, вы можете это все

76: Смотреть, пощупать, потрогать и так далее и тому подобное. Это не пропретарщину, да, поэтому

77: Речь пойдёт про компьютер 100 сепарейшен в 1 очередь. То есть, что это нам даёт. Во первых, у нас разделение. Ну, во первых, компьютер 100 сепарейшен бывает разный, и в том числе в пон бывает разный. И сегодня Алексей расскажет про

78: Это более подробно. Какие есть варианты? Компьютер, сепарейшен? Мы пошли по пути разделения компьютер сторожа на уровне стороджа. Ну то есть стороджа хранения, я имею ввиду, на уровне самого послеса. Во первых, это нам дало отделить вычисления и хране.

79: И масштабировать 1 от другого отдельно. Это позволило снизить в принципе, стоимость 1 кластера. Ну потому что при таком подходе вы не копируете данные реплик у вас они как бы вы работаете с 1 единой базой данных.

80: Простота использования, ну, в том плане, что мы сохранили полностью работу стандартного по кластера, то есть primary реплика, все тоже самое, все репликационные ваши стат вьюхи будут работать все вот то, с чего, чем привык.

81: Работать дибиэй, все остаётся. То есть ничего в этом плане не меняется. Ну и данные, в принципе, хранятся у нас в 3 экземплярах на уровне стороджа. Ну то есть любая блочка, любая пропритарный, угодно, все, что касается.

82: Хранение данных мы отдаём на этот уровень. Ну то есть это уже проблема стороджа.

83: Вот мы сделали новую редакцию у себя в компании, но мы её делали на основе опенсорсной опенсорсного форка, который сделала компания alibaba Алибаба, и это все называется по.

84: И, соответственно, наша редакция называется thunder полер. Но здесь, как говорится, дьявол, дьявол в деталях. Это не просто опенсорсная сборка, но общая архитектура наследуется нами, но мы много чего переписали, поэтому я сегодня буду говорить и про

85: Про тантер, полар, но вы можете думать, что я говорю про в целом, то, что сделала Алибаба, там, где будут какие-то нюансы. Я буду раскрывать, говорить конкретно, что мы доработали, и, немножко забегая вперёд. Я хочу сказать, что мы планируем выложить все, о чем я сегодня буду говорить, ну, большую часть того, о чем

86: Сегодня буду говорить в open source, поэтому в целом все эти наработки обратно будут отданы в open source что такое компьютер стори сепарейшен в нашем понимании, то есть, во первых, компьютел не содержит данные, ну, в принципе.

87: Это понятно, но есть у него локальные свои буферы, он там может хранить временные таблицы, данные временных таблиц. Ну то есть какие-то данные он хранит, но это не персистентные данные, которые требуются для работы, там вашей субд 1 д.

88: Узел, то есть мы сохраняем классическую схему работы посгреса. То есть нет мультимастера, нет нескольких пишущих нот. Это является, да, неким узким местом, но там есть ряд оптимизаций, которые эту проблему тоже решают.

89: Ну, частично, скажем так, решает не полностью репликация. У нас отсутствует классическая репликация, в классическом понимании присутствует новая репликация с точки зрения только метаданных. Ну, по сути, это та же самая репликация, только реплицируется не весь вал.

90: Только его метаданные на основе этих метаданных создаётся специальная структура, которая называется loc index, она нужна для того, чтобы синхронизировать буферные кэши, ну, то есть у нас из за того, что, как вы понимаете, сторож общий и данные то вроде

91: Как бы общие, но буферы то не общие. Поэтому здесь необходимо необходим механизм, который будет позволять вот эти вот проблемы решать. Ну то есть там есть 2 проблемы, о них сегодня тоже Алексей поговорит более подробно. Вы, если что, не думайте, что

92: Мы это все опустим просто я ну рассказываю немножко так более обзорно там 2 проблемы 1 называется future пейджес другая называется all pages ну устаревшие страницы да, соответственно тоже про это все поговорим добавляется специальная распределённая файловая сис.

93: Система по фс. То есть это система, которая нужна для того, чтобы, как минимум эмулировать посикс, ну и, соответственно, позволять нашему пососу работать в привычной среде. Вот, ну и, соответственно, там ряд выпол.

94: Ещё функции операции, которые тоже сегодня мы раскроем, требуется сторож. Сторож должен быть быстрый. Ну, потому что, в принципе, любая база данных хочет, чтобы сторож был быстрый. Ну и есть важный нюанс. Это все работает.

95: По сети димй, то есть без сети диэмэй. Ну мы получим огромные сетевые задержки, так как у нас все компоненты кластера фактически сторож работают по da. Ну в этом случае для нас это критично сле.

96: Следующий момент это рерайт splitting вообще rewrite splitting в кластере это очень интересная вещь, то есть, грубо говоря, rewrite splitting нужен для того, чтобы в целом ну, решить проблему горизонтального масштабирования, ну настолько наскольк.

97: Сколько можно это решить, но решать проблему расплитина можно, в принципе, сейчас, да, вы можете какой-нибудь там хапрокси поставить и, в принципе, сказать, что вы решили проблему балансировки, ну или, не знаю, там, pg pool какой-нибудь или ещё что-то, но

98: Проблема в том, что прокси не просто должен балансировать данные между нодами, он должен обеспечивать консистентность в рамках всего кластера. То есть, представьте, у вас вы открываете транзакцию, пишите

99: Что-то в этой транзакции закрываете транзакцию потом делаете select того что вы что вы закомитили в этом случае прокси должен обеспечивать вот эту консистентность то что называется редай да, и соответственно обеспечивать ещё и

100: И так называемую стронг ну консистентность уровня strong сериал serializable извините, опирается все это на расширение серверного протокола, то есть это не просто проксик поверх базы данных.

101: А ещё дополнительные наработки внутри базы данных, которые обеспечивают определённый ипиай для работы, ну, скажем так, для коммуникации, прокси и базы данных. Все это дело необходимо для того, чтобы следить за

102: Снами. То есть, ну кто знает, что такое лсн?

103: Супер почти процентов 5 зала. Ну, в общем, есть такая штука лсм, она находится в Вале Андрею любит про это все рассказывать. Бородин вот про вал и вообще про

104: Лсн. Собственно говоря, это нужно для того, чтобы понимать, какая транзакция была закоммичена, и видеть вообще, что, что закоммичено, на каком узле, что туда приехало. Вот, соответственно, понимая, какой лсн закоммичен, в какую ноду мы можем

105: Как бы обеспечивает ту самую транзакционную, не извиняюсь, не транзакционную, а глобальную консистентность. То есть в целом мы можем консистентно читать и быть уверенным, что мы читаем реально то, что мы записали. Ну и есть ещё ряд проблем.

106: Которые эта штука решает. Ну, во первых, есть такая вещь, как cisco, Иван намбер, мы про это тоже поговорим. У него есть функция, в том числе обеспечения транзакционной консистентности, да, сессионной консистентности, извиняюс.

107: Вот, но помимо этого он ещё решает ряд там побочных эффектов имеет это мы сегодня тоже обсудим. Ну и важный компонент. Важное, точнее, умение прокси это добавлять ноды и убирать их на лету, то есть без рестарта. То есть достаточно релода, мы можем добавить новую

108: Сделать io e произойдёт ребалансинг, то есть прокси умеет перебалансировать мы на самом деле проводили ряд исследований перед тем, как вообще выбрать насчёт, на основе чего делать прокси, то есть прокси в опенсорсе отсутствует, да ну как таковой.

109: Баба не поделилась с нами, этими наработками, то есть есть какой-то прокси в их клауде, как он работает. Ну, примерно знаем, из документации. Документация у китайцев, да, простят меня китайцы, такая себе. Вот. И здесь

110: Есть как бы, ряд нюансов. Вот, поэтому мы выбирали, выбирали, выбирали, смотрели на pg, кэт, на одиссей, смотрели на pg, док, там ещё на что-то. И в целом нам это ничего не подошло, в 1 очередь по причине.

111: Низкая, низкого перфоманса. То есть что значит низкий перфоманс. Нам нужны были сотни тысяч типсов.

112: Одиссей не справился, Андрей, вот мы к тебе не пришли. Ну, прости, но не справился. В общем, мы взяли прокси, и, собственно говоря, прокси скил, и в целом он нас устроил. То есть его доработали, есть ряд изменений в нём, но

113: Proxy скел, в принципе, он хорошо известен в мире my скел, и он оттуда, в принципе, то и был взят. Вот, но он имеет ряд классного функционала, который нам очень пригодился. Вот. В общем, это вот то, что касается

114: Proxy, если как бы, ну так немножко резюмировать, да, в принципе, то решение проблемы масштабируемости мы смотрим на это, как вот во первых, разделение компьютора, ну то, о чем я говорил с a splitting это некие

115: Аналог, да, ну, в кавычках аналог аппликейшн кластера в том контексте, что у нас 1 пишущая Нода, но реплик у нас может быть сколько угодно. Да, соответственно, у нас есть возможность писать, используя наш прокси, который гарантирует нам

116: Сессионно консистентность позволяет читать то, что мы записали. И, соответственно, у нас сохраняется простота эксплуатации в том плане, что primary стенбай схема, то есть то, к чему привык обычный дибиэй, да, соответственно, который обычным исполь.

117: Все это сохраняется. И эта простота эксплуатации, она тоже в нашем случае сохранена. Самый важный момент, что вот это все позволяет сохранить стопроцентную совместимость с поведе.

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

119: Как бы, этот work, он очень, ну, совместим с обычным посгресом. Ну, поговорим немножко дальше, про то вообще. А, да, извиняюсь, надо что-то ещё рассказать, то про кишочки, то бенчмарки, то, что мы

120: На самом деле у нас есть несколько Тестов, просто я сегодня буду показывать не все мы проводили ряд Тестов плитино с ридонли просто с a splitting там есть определённые моменты, мы все думали как их пока.

121: Сказать, потому что есть очень, ну, много нюансов, вот с точки зрения того, какой тест, как его показывать, там и так далее. Вот. Поэтому мы, честно, немножко, я тут, я конкретно немножко схалтурил и показываю вам только ридонли, потому что он очен.

122: Показательный, и он в целом описывает то, что было сделано. Ну то есть здесь трехузловой кластер, это в принципе, 3 компьют ноды, 3 стороджа, в принципе, все характеристики. Видите, это мд, серверы здесь

123: База порядка 2 терабайт, это скил фактор, по моему, 100000 пиджи бэнч и используется 2000 параллельных коннекшенов, которые там работают с 512, ну, этих средах, если работаем только с primary, у нас получается 190, там, ну, почти 2.

124: 200000 типсов. Добавляем следующую реплику. У нас получается там 120, да, по моему, там и ещё следующая, там 140, 150. То есть цифр на цифры не смотрите. Ну в целом они как бы здесь не, это задача этого слайда.

125: Показать вам максимальную производительность это, скорее, демонстрация того, как добавление новых реплик может скелить нагрузку с rewrite splitting там, может быть, могут быть нюансы, но с ридонли все достаточно просто в этом плане и.

126: И самое главное, что нагрузка то идёт через прокси, не через там просто, да, какой-то роутинг, там, не знаю, через драйвер или через что-то ещё. То есть прям через прокси гоняется это все дальше поговорим про

127: Производительность, наверное, да, производительность. Я не буду говорить здесь про все. Я скорее поговорю про то, с чем мы столкнулись. Ну, во первых, коммит, сиквенс, намбер, зачем он нужен? Да, и, в принципе, у нас, соответственно,

128: Извиняюсь, тут что-то у нас со слайдом произошло ну ладно, коммент сиквенс, намбер во аплайн, поговорим про параллель биджит и про pf, соответственно коммент сиквенс, намбер да что это такое?

129: У нас не так давно мы проводили нагрузочное тестирование на нашей исдате ген 2. Там у нас обычный тантер, се тантер, спешл эдишн, ну, который является фактически форком коммерческим её, то есть вот это поведении

130: Оно характерно для обычного опенсорсного посгреса. Я даже скажу, что в опенсорсном посре будет хуже, потому что там нет ряд оптимизаций, но даже это все не решает фундаментальную проблему. В чем проблема? Здесь вот, наверное, мелко вы ещё и качество.

131: Плохое, да, я вот не знаю, сейчас попробую как-то вот, вот тут вот написано, поверьте мне, get snapshot, дата, соответственно, кто-нибудь сталкивался с проблемами, которые

132: Называется проко рей в постгресе, а точнее, локах на этих проко реях. Вот Виктор знает эту боль. В чем эта боль выражается, когда у вас высокий коммит рейт начинается. Да, у вас происходит

133: Будет деградация, соответственно, и конкуренция за то, чтобы взять get shot дата, то есть блокировку на get shot дата. То есть это прям боль, боль, потому что чем больше у вас этого всего

134: Возникает, тем больше деградирует ваш посгресс. И, соответственно, это почему происходит? Потому что у нас есть такая структура, которая называется прокре и как бы когда мы сиды засовываем

135: Вот в этот проко рей, у нас там есть, во первых, 64, сколько там, да, 64, по моему, да, глубина у нас этого прокоря, он бывает, он ещё может переполняться. И вообще, в целом, эта структура, её нужно линейно обходить для того, что

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

137: Самое, ну, плохое, что эту проблему решить какими-то патчами в текущий механизм виси си, ну, фактически невозможно, там есть патчи, в community даже лежат, но это все косметика, она не решает.

138: Проблему эту проблему, как оказалось, решает сисн коммит, сиквенс намбер вообще предназначение коммит сиквенс намбер не в том, чтобы решать эту проблему. Изначально была для того, чтобы иметь решить другую проблему. Эта проблема тоже известная.

139: Когда у нас есть несколько нот и сейчас я про неё тоже расскажу вообще в целом cs and решает эту проблему следующим образом. Во первых, он заменяет подход вообще с сисси обычного погаса да, вот.

140: Сидами заменяют просто обычным 64 битным числом, которое присваивается при коммите каждой транзакции, то есть, по сути все вся все cc в дальнейшем сводится к тому, чтобы сравнить транзакцию, а с транзакцией б. Ну точнее сравнить их.

141: Number и понять вообще какая где видна. Соответственно, ну это я прям очень упрощаю соответственно, как бы вот переходя к такой модели мы по сути перестаём ходить в наш замечательный этот силок да, кто знает что такое силок.

142: Супер скала. Ну, scala. Ты должна знать, конечно. Вот. Поэтому в этом случае у нас, соответственно, отсутствует работа с селого, и у нас как бы появляются там свои структуры.

143: Sn самое главное, что сисн является отключаемым, то есть в принципе сисн вы можете либо его использовать, либо можете не использовать, есть обратная, скажем так, плата за csm она заключается в том, что его лучше не использовать при длительных транзакциях, ну то есть, когда у вас, я не знаю, там транзакция, вы хотите часам?

144: Держать. Вот это не про сисн. В этом случае сисн выстрелит в ногу, но он в принципе не для этого придумывался. Он придумывался как раз-таки для мелких транзакций и большого количества параллельных сессий, 2 проблему, которую

145: Решает это он гарантирует единый порядок, единый порядок видимости транзакции в кластере важно не в рамках 1 ноды, а в кластере, соответственно, есть такая штука, которая называется long for оно.

146: Вот известная особенность, это не баг, это особенность посгреса, она известна, она обсуждается, активно, обсуждалась активно в комьюнити, вот, в принципе, вот об этом пишет amazon.

147: И Алексей нам любезно тоже эту тему подсветил. Вот, что есть такая тоже проблема. Вот. Соответственно, в чем проблема, то, что есть 2 порядка, есть коммит ордер, а есть визибилити ордер, и они не совпадают. То есть вы можете, грубо говоря, закоммитить транзакцию на мастер.

148: Ну то есть условно транзакция б, которая была закоммичена на мастере позже транзакции, а увидится на реплике в обратном порядке. То есть вы сначала на реплике видите транзакцию б, а потом увидите транзакцию, а, и это не баг, это фича, то есть

149: Вот эту проблему, как вы понимаете, в кластере, когда нам нужно гарантировать сны, вот это вот все. Ну, в общем, короче говоря, для нас это проблема, поэтому мы, собственно, используем сисн.

150: Эту проблему он тоже решает. Есть ещё вот как раз та проблема, где сейчас я вернусь назад.

151: Ага, сейчас вот победил я. То самое главное, не сказал, что вот эта штука, она происходит, когда приходит какое-нибудь java приложение, и оно любит создавать сейф, поинты, сейфон.

152: Pg, скил процедуры. Ну, в общем, это все пришло к нам из оракла нашего любимого. Вот про который мы сегодня много говорим, собственно, как это работало. То есть когда-то было написано какое-то приложение на джаве.

153: Оно, естественно, работало с ораклом, даже с экзадата, а потом все это дело успешно поехало на постгрес, оно поехало на постгрес, но при этом логика вся была сохранена, переписана, по сути, только там обвязка и используется под транзакции.

154: Соответственно, когда у нас этих сейф поинтов становится очень много, а как это делает обычно java приложение, оно открывает транзакцию чик сделала сейф поинт, там ещё чик сделала сейф поинт, ещё чик сделала сейф поинт и получается, что этих сейф поинтов становится очен.

155: Много, а для посгреса вообще sub транзакция это дорого и вся модель мисис построена таким образом, что ну как бы sub транзакции надо как-то там достаточно дорого хранить и у нас получается, что мы начали гонять

156: Синтетические тесты вообще понять, насколько все плохо, а на самом деле все плохо. Если safe поинты использовать в больших объёмах. Вот у нас есть такой простенький тест, пиджи, бэнч, мы по сути берём, открываем транзакцию, делаем сейф, поинты, потом че то апдейтим, потом ещё.

157: Ну и поехали вот при 256 тредах на 60 секундах. Ну, персо поинт каунт, да, у нас получается, что мы деградируем примерно вот так, то есть.

158: Я извиняюсь, я, наверное, отойду подальше. Вот так, в принципе, здесь, что на вот этом, это, по сути, 2 одинаковых теста, просто разное отображение в этом случае вот этот верхний, это csm вот этот нижний, это

159: Обычное поведение с bcc пососа, то есть чем больше у нас тредов, тем больше мы деградируем ну и видите вот такие замечательные провалы, когда мы по сути падаем чуть ли не в 0 и это по сути просто пиджин тест.

160: Это не там какие-то сложные процедуры, это не какие-то сложные там, не знаю, логика какая-то просто даже на обычном пиджи бенче все становится очень плохо. Следующая проблема это вал, ну опять же там проблем много, можно об этом

161: Там долго говорить, но как бы о чем сегодня я хочу рассказать я хочу, во первых, рассказать про конкуренцию за блокировки lock contention, ну то есть в чем смысл, то есть бэкенды конкурируют за винсерт лог в 1 очередь, да, за write log.

162: И при определённом продвижении, ну, white и flesh позиции, это происходит стерилизация, то есть только 1 бэкенд может управлять записью, сбросом вала на диск, то есть, соответственно, мы получаем узкое бутылочное горлышко и все остальные бэкенды.

163: Ждут и пробуют повторить это ещё раз. Ну и стерилизация ввода вывода. Ну то есть каждый коммит пас может запускать собственную операцию, записи и всинк. Ну, соответственно, тоже это все уменьшает возможности пакетной обработки. То есть мы все

164: Вот в 1 поток едем, паровозик едет, мы потихонечку коммитим соответственно что предлагается предлагается сделать конвейерную обработку вала. То есть эта вообще идея взята из muscle и

165: Вообще оригинальная команда полар диби, которая писала вот это все, она вообще, по моему, майске, да, Алексей, да, то есть эта команда была масквелл, и, соответственно, вообще вот это все пришло из muscle, соответственно, что

166: Подразумевает под собой конвертная обработка. У нас выделяются отдельные рабочие потоки, которые каждый занимается своим делом. То есть у нас есть выделенные рабочие потоки, они отвечают за адвенс, ну то есть за продвижение записи в рай.

167: Спрос, сброс, точнее flash и уведомление на тифа, то есть бэкенды, осуществляющие транзакцию они не выполняют запись или сброс, то есть они только ставят свой лсн в очередь конвейера и все и ждут ну?

168: То есть, когда уже все сигнал придёт о завершении, ну и, соответственно, есть ряд режимов, которые эмулируют, ну, не эмулируют. Точнее, извиняюсь, ряд режимов, которые позволяют работать вал конвейеру, и, ну, их там 5, все.

169: Они, по сути разбиваются на, ну разные этапы, то есть в 1 случае это все вместе, да, как в обычном варианте 2, когда у нас адвенс white flash и на тифа разделены, то есть 2 потока рабочих трей.

170: Соответственно, у нас эдвенс 1 поток write и flesh, другой поток и на тифа выполняет 3 поток в 4 варианте. Ну эдвенс райт флэш нотифай, ну и соответственно в 5, когда все 5 потоков, каждый занимается своей отдельной работой, то есть

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

172: Этом польза, а польза огромная, потому что даже на наших тестах, опять же синтетических примерно вот такая картина, то есть зелёненькая, это wall пайплайн включён. Синеньк какой фиолетовый

173: Просто искажает это во пайплайн выключен, то есть база 2 терабайта Драйт, соответственно у нас plus ролл реплики, ну и pj бэнч у нас типиси би редрайдер и 56.

174: Клиентов 256 тредов 240 секунд. Ну и при квери у нас включены. То есть, в принципе, по нашим оценкам, во аплайн даёт там 30, иногда даже больше процентов.

175: Прироста к перфомансу просто на 1 и той же даже нагрузке. Вот. Соответственно, это было бы неплохо иметь и в опенсорсном постгресе, но, к сожалению, коммит большой, поэтому тащить туда его будет очень долго.

176: Дальше полларс распределённая файловая система. Я про неё немножко говорил. Как она выглядит. Я на ней останавливаться не буду. Опять же повторюсь, что я останавливаюсь только на тех моментах, глубоко разбираю, которые не будут глубоко разобраны.

177: В докладе алексея пос будет разобран, поэтому тут просто только обзор. Собственно, что такое по распределённая файловая система, в ней есть, по сути, ну, скажем так, сама по фс.

178: Сама ну субд, да и сами диски, то есть api ли psd на каждом вычислительном узле для хранения и извлечения данных ну демон ps ли psd он как раз с psd взаимодействует.

179: Вот, и, соответственно, лип пифс тоже есть такая штука здесь вот я уже даже, да, как бы называя это, понимаю, насколько можно в этом всем запутаться для понимания. Вот все, что здесь сегодня будет рассказано алексеем, потом и вот то, чт

180: Я рассказываю, этого нет вообще нигде. Это просто reverse инженеринг и написание документации, огромный труд, который делала команда, в 1 очередь алексея, для того, чтобы это все разобрать, как это работает. Ну и работа с большим.

181: Данными и вообще объём объёмом пользователей что тут предлагается предлагается такая штука которая называется немножко странно на мой взгляд она называется shared server на самом деле это пулер это встроенный пулер коннектов внутри непосредственно базы данных.

182: Он на самом деле очень интересный, и он работает не так, как работают, допустим, внешние пуллеры или какие-то пропритарный пуллеры. Я на самом деле до того, как с этой штукой не столкнулся, я не видел вообще нигде.

183: Даже в пропитанных продуктах такой реализации, чтобы она обеспечивала такое нативное поведение, посгреса, поддерживала приметы сессионные, там, гуки всякие, переменные и так далее, и так далее. В чем смысл и как это все работает у него?

184: У этого пуллера есть трешхолд, во первых, да, который регулирует момент срабатывания пулера. То есть, например, вы можете сказать через Гук, что включайся, когда мы достигли 5000 коннектов, и только в этом случае пулер будет пулить до этого.

185: Мы будем работать просто как обычный постгрес, не создавая некий оверхед на то, чтобы у нас вот эта вся машинерия работала. Следующий момент у нас архитектура выглядит следующим образом. У нас есть session context, ну, по сути там, где

186: Живёт, где у нас живёт её план, кэши, гуки, переменные, все остальное. И это все хранится в шд мемори. Есть процессы, которые называются диспетчерами. Ну, они, по сути, принимают подключение от клиентов, есть сами, непосредственно

187: Shared бэкенды вот эти шард бэкенд пулы, да, по сути они занимаются непосредственно обработкой запросов и они вот шарятся между разными клиентами, все это позволяет в целом работать в нескольких режимах.

188: 1 режим ну нейтив понятно, когда у нас используется просто format обычный посгрес, ну то есть в этом случае мы просто либо выключаем наш red server, либо у нас пользователь который установился установил такой коннект, он находится в

189: Блеклисте. Ну такое тоже можно сделать и сказать, что вот этот конкретный пользователь работает вот в обычном режиме, есть режим шеред это, ну, как раз-таки то, ради чего пулер затевался, и он даёт максимальный как раз-таки выигрыш на большом количестве коннектов. То есть мы в это

190: Случае не деградируем, как деградирует обычный по, но сохраняем нормальный перфоманс, нормальный рейд и дидике. Режим это самый плохой режим, в него сваливается пуллер в тот момент, когда

191: Происходит 1 из негативных событий. Ну то есть там есть ряд негативных событий, которые могут произойти. Во первых, это могут быть изменены гуки какие-то в конфигурации непосредственно могут быть запрещённые какие-то расширения, ну какие-то кастомные расширения, которым это нельзя.

192: Использовать курсоры тоже не поддерживаются, не поддерживаются. Операция, коммит, делит роуз, пользовательские гуки тоже и всякие динамические библиотеки. Ну то есть в целом не так уж большой список.

193: Да не такой уж большой список по сравнению с тем, что делают другие пуллеры. А вот и другие пуллеры, собственно говоря. Ну, это сравнение с pg баунсером, в принципе. Ну, здесь, по сути, можно сказать, все в 1 калитку, то есть

194: Ну, презентация будет выложена, потом просто можно посмотреть. Поэтому, если кто фотографирует, не бойтесь, мы это все выложим. Я не буду здесь все перечислять. Здесь в целом. Смысл в том, что встроенный пуллер, он позво.

195: Делать много и позволяет, в том числе использовать при стейтменты. Ну то, что там в других пулерах не очень хорошо работает. Теперь поговорим про такую вещь, как аналитика.

196: Возвращаемся к нашему любимому письму оракла там было написано, что посос не работает как tab система и действительно постганглионарное, а даже если туда прикрутить пиджи, дак диби или там сделать какие-то

197: Колоночные методы хранения движки прикрутить, ну как бы это с большим натягом можно назвать чтаб системой, потому что все-таки для того, чтобы быть tab системой, надо решать там много других проблем. То есть, во первых,

198: Тип, нагрузка должна работать и не аффектится лап нагрузкой. Ну и наоборот, соответственно, мы должны работать с теми же самыми данными, с той же самой копией данных. Это в принципе тоже желательно без всяких копирований, перекладываний и так далее.

199: Далее и тому подобное. Ну и, соответственно, есть ещё такая вещь, как параллелизация, да, в рамках, скажем так, не 1 машины, не 1, точнее ноды, а в рамках нескольких нод. Это тоже важная вещь. И здесь тоже

200: Предложить как бы особо нет, нечего. То есть есть опять же, внешние всякие сайтус там и так далее. Но там есть проблемы с консистентностью, с глобальной, что предлагает полар и вообще, что

201: Предлагает наш форк мы предлагаем такую вещь, как gp орка кто знает, что такое gp орка?

202: Супер класс. G пиорка это планировщик из гринплана. Ну он там сейчас как-то расползся, там всякие появились грин гейджи, там че то там какая-то клаудберри. Да, че то в общем, много всякого появилось на основе гринплана.

203: Но gp орка классная вещь в том плане, что она умеет работать с postgres базами лайк, да и в целом делает это неплохо проблема в том, что джипика работает с шардингом, ну то есть.

204: Plum это про шардинг, про pypi движки, а у нас нет шардинга, у нас сторедж общий, вот. И поэтому тут пришлось немножко поизгаляться, то есть это

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

206: Прос планируется, мы делаем, по сути, шардирование на лету, то есть разделяем блоки, ну, не блоки, извиняюсь, мы разделяем как бы данные и делаем некий виртуальный шардинг для того, чтобы выделить каждому

207: Воркеру свой кусок. А что такое воркер? Да, то есть, возвращаясь к терминологии гринплана, у нас есть координатор, у нас есть воркеры и вообще многое, что вам известно из гринплана, слайсы, ганги, там вот это все, это все.

208: Применимо здесь, то есть для тех людей, которые работают с гринпламом, вообще все будет просто как вот как привыкли практически, но будут плюсы. Вот из за того, что мы используем шардинг на лету в момент планирования у нас

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

210: Как решардинг перекосы исчезают такие проблемы, как работа со скоростью самой медленной ноды и так далее. То есть здесь есть огромное количество плюсов. Плюс есть такая штука, которая называет

211: Pq эластик, параллел квери, который может на лету управлять и пере пере, по сути, шардировать, ну то есть перенаправлять ресурсы на ту ноду, где возник перекос. То есть в целом такой функционал тоже есть в принципе.

212: Каждый, ну, стендбай может выполнять роль либо координатора, либо воркера. То есть просто обычная реплика, на которой, замечу, данных нет. То есть вы можете, в принципе, создавать нужное вам количество реплик и скейлиться только за счёт.

213: По сути, компьютер, то есть, создавая новые реплики, вы можете скелиться и как бы работать с общим шар стореджем. Вот, соответственно, каждый скилл оператор может запустить нужное количество потоков и, соответственно, ну,

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

215: Вот это вот описание, но смысл в том, что вы можете параллелить и в целом запускать нужное количество параллельных воркеров. Ну, на каждой из этих нот. Здесь я, наверное, попрошу включить Демо и показать вам живьём. Я извиняю.

216: Мы, честно, не думали, что этот экран будет не такой качественный, просто с ним есть явно проблемы. Вот на экране у меня выглядит совсем совершенно по другому. Мы сейчас включим видео, я буду его комментировать и рассказывать.

217: Что здесь происходит? Это реальная машина x дата ген 3, состоящая из 6 серверов супермикро на мд. Ну, часть. Вы её там видели, собственно, 3 компьютера, 3 стороджа вверху.

218: Видите, 3 компьютера слева мастер реплика. Ещё 1 реплика. Здесь будет запускаться отипи, нагрузка, и вы увидите через прокси. Вот это сейчас то, что выполняется. Жёлтенькое такое беленькое, это нагрузка.

219: Джи, опять же, поверьте мне на слово, там 204000 типиэс сейчас на текущий момент выполняется в нижнем правом углу. Это типиси эйч тест, который запускается в параллель на этих же нодах и в принципе,

220: По утилизации вверху процессора вы можете понять, что он там делает. Внизу очень плохо видно, но здесь вот куэрри 1, я буду просто вам комментировать. Куэрри 1 выполнился с парализацией 128 потоков.

221: Извиняюсь. 11 секунд. Квери 2, 3 секунды. Квери 3, 10 секунд. Квери 4, 4 секунды. 9. Дальше 1 10, 5. У нас используется в Большин.

222: Запросов 128 допов так называемых, где-то их сам планировщик режет до там 80 90 и так далее используется здесь используется пикс энджайн, то есть это gp орка и

223: В принципе, используются 2 ноды. То есть мастер выступает как в Роли координатора. 2 реплики выступают в Роли воркеров. То есть сейчас у нас, по сути, типиси эйч тест закончится, ну, где-то за 100.

224: Секунд. Вот, то есть это, в принципе, реальный тест, ну, видео потом тоже выложим, чтобы вы могли более детально посмотреть, как это выглядит и что там есть нагрузка в этом случае, в том числе балансир.

225: Otp нагрузка на 2 ноды реплики то есть вот эти синяя и красная это это редрайдер прокси балансирует отипи, перекидывая на реплики то есть здесь выполняются одновременно на 3 нодах и otp лап запросы.

226: Вроде да, все. То есть диписи эйч закончился за 118 секунд тест.

227: Ну, на этом, наверное, можно вернуть, да, презентацию. Я бы хотел, наверное, закончить свой доклад таким немножко. Я не хочу отвечать на вопрос. Я просто хочу задать его вам, то есть работа.

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

229: Ли сделать машину баз данных уровня экзадата на базе postgres. Наверное это на ну ответ на этот вопрос можем обсудить в кулуарах кто-то согласен, кто-то не согласен, кто-то может быть что-то подскажет на этом.

230: Все, я бы хотел вас поблагодарить за время. Ещё раз извиняюсь за качество видеокартинки. Честно, как-то мы не ожидали, что оно такое будет. Вот. Но я готов всем, если что, показать его, это