Комментарии 6
Много воды, мало цифр. Во сколько "немного замедляет доступ к данным"? У вас наверняка есть бенчмарки раз продукт появился. Брокер сообщений это не то что обычно ожидают от реляционной базы данных. Не поделитесь хотя бы синтетикой?
Привет, спасибо за вопрос! Мы пишем серию статей про Neon, детальные бенчмарки по производительности и работе под разными профилями нагрузки мы представим в следующей статье. По поводу брокеров, для распределенных систем подобная реализация скорее необходимость которую можно встретить в том или ином виде и в других реляционных базах (пр. AWS Aurora, CockroachDB, YugabyteDB)
Хороший структурированный материал. Интересно узнать про ограничения. Если у меня сейчас работает 'классический' Postgres в K8s, насколько сложно и рискованно будет мигрировать на Neon? Какие самые большие подводные камни?
Привет, очень рад, что статья оказалась полезной. Сложность и риски миграции с классического PostgreSQL на Neon зависят от выбранной версии. Если речь идет об Open Source Neon, то придется преисполниться и потратить время на разработку недостающих компонентов (там правда не хватает многих сервисов, а некоторые os приходится патчить). В остальном миграцию можно осуществлять любыми стандартными инструментами Postgres.
Kubernetes используется overlay-сеть, которая в больших кластерах со множеством узлов может вносить дополнительную задержку
Во-первых, это не так. Можно (и нужно для таких случаев) блоки адресов аннонсировать прямо с ноды, тогда поды будут доступны по сети напрямую, что минимизирует задержки. И из всех перечисленных проблем это имхо наименьшая.
Другая большая проблема постгреса в кубере, это жирные поды с огромными реквестами и лимитами, что в принципе затрудняет равномерное использование капаситета на нодах.
А почему s3 а не RBD? RBD точно быстрее.
Добрый день. По сетям, дополнительно изучил вопрос и если мы говорим про on-prem инсталляции и некоторые облака (не все дают установить свой CNI) ваше уточнение верно, спасибо.
По жирным POD:
Да, при очень жирных POD-ах возможна фрагментация ресурсов, но в случае с Neon это частично нивелируется:
Подходом к вертикальному масштабированию - через CU, все ресурсы в линейной зависимости от CPU;
Возможностью шардирования на уровне Storage;
Наличием Autoscaler с собственным планировщиком;
В целом за счёт разделения Compute/Storage фрагментация ресурсов в Neon не такая уж проблема по сравнению с классическим PostgreSQL в k8s;
По S3 vs RBD:
Продукту важно быть универсальным (on-prem и облака) и чаще в инфраструктуре клиента есть S3, а не блочные устройства;
RBD сложнее использовать в сценариях с Multi-RW доступом - потребуется использовать какую-то параллельную ФС отдельным слоем, что вносит существенную сложность в поддержке;
Архитектура Neon: как устроен cloud-native PostgreSQL в Kubernetes