Search
Write a publication
Pull to refresh
15
6
Nexign team @Nexign

User

Send message

Сам по себе insert миллиона новых строк с созданием партиций, конечно же, будет медленнее, чем insert миллиона строк в существующие партиции.

По нашим тестам замедление составит около 50 % на первый инсерт, в котором создается партиция.

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

Что касается поведения БД с большим количеством партиций, то тут оно ничем не будет отличаться от ванильного PostgeSQL.

В документации есть предостережение об этом:

https://www.postgresql.org/docs/17/ddl-partitioning.html

All constraints on all children of the parent table are examined during constraint exclusion, so large numbers of children are likely to increase query planning time considerably.

So the legacy inheritance based partitioning will work well with up to perhaps a hundred child tables; don't try to use many thousands of children.

В статье идет речь о доработках Nexign Nord на базе PostgreSQL, поэтому опыт будет релевантен и тем, кто самостоятельно работает с БД на этой основе.

Размер блока у нас 8 килобайт, дефолтное значение.

У производства было сравнение на этапе аналитики по ТТХ разных альтернативных решений. Кроме ТТХ также рассматривался вопрос текущей доступности лицензирования. В статье затронули сравнение тестовых проговнов с Redis. Невозможно было включить все сравнения в 1 статью, не в этом задача была. Про то, что в чистом виде Postgres не везде подойдет в предлагаемой роли - безусловно, факт. Там есть какие вопросы порешать. Приведенный опыт больше подходит на успешный proof of concept. Если концепт подходящий, то дальше уже можно углубляться в поиски или реализацию движков хранения и прочие вопросы.

Эти решения в начале были в группах кандидатов, но отсеялись по ходу:

  • Aerospike не подошел по лицензионной политике.

  • KeyDB и RocksDB не использовали ранее, но варианты интересные. Но так как скорость не стояла во главе угла, надо было удержаться в рамках "не хуже CB" и желательно без экспериментов (критичный узел критичного продукта, короткие сроки).

  • Tarantool хорош, мы его даже успешно тестировали. Но его выбор будет означать хоть и незначительный, но vendor-lock (все же это сервер приложений и под него нужна отдельная реализация серверной логики на стороне кластера TNT). Нам же хотелось получить абстрактный источник key-value данных, который на стороне приложения можно менять малой кровью через адаптеры.

Нет, за основу мы взяли логику pg_cron и переработали его под запуск на неограниченном количестве БД.

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

К примеру:
- Администратор может задавать и контролировать сложность паролей пользователей;
- Доступно хранение истории паролей с настраиваемой глубиной;
- Планировщик заданий с гибким расписанием и возможностью запуска в нескольких БД.

В новых продуктах стараемся сразу всё писать по уму :)

1.       Цель данной статьи — рассказать в целом о разработке новой платформы Nexign Mediation, о возможностях ее использования в разных сферах, об общих принципах настройки и поддержки, не акцентируя внимания на обработке определенных типов данных.

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

Кроме всего прочего, Nexign Mediation собирает и обрабатывает данные по NetFlow.

Что касается IDR — то это записи регистрации абонентских данных, которые приходят в запросе по DIAMETER с оборудования. Для этого у нас есть другой продукт, который занимается онлайн-сбором данных по DIAMETER, в этой статье мы его не упоминаем.

 

2.       Платформа Nexign Mediation спроектирована в "открытом" виде, биллингистам не составит труда быстро научиться с ней работать: отслеживать её состояние, модифицировать сценарии и добавлять новые, поддерживать НСИ и расписание запусков сценариев, проводить аналитику по отчетам о принятых данных, работать с ошибками, делать сверку и т.д. Все действия разграничены разными правами и фиксируются аудитом.

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

 

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

Под "быстрым запуском" имеется ввиду время без миграции. Продукт можно запустить за несколько часов или даже минут с предустановленными настройками (бекап), например, если речь о новой площадке. Обновление продукта также проходит достаточно быстро — за несколько минут.

 

4.       Мы разобрали несколько протоколов, к которым у нас был доступ (Alcatel, Ericsson, Nokia, ZTE…), и нашли, что их можно описать в общем виде следующим образом:

·       Присутствует или нет «не-ASN1» заголовок, и длина заголовка задана фиксировано или внутри самого заголовка.

·       Весь файл — единая ASN1-структура, или последовательный их список.

·       Если единая ASN1-структура, то искомый список xDR надо искать либо по указанному тегу, либо просто сместиться на указанное число тегов внутрь.

·       Если это список готовых xDR, то: а. они могут быть разделены на блоки указанной длины и с указанным разделителем (0x00, 0xFF); b. может быть несколько байт, которые надо пропускать; c. может быть сложная структура, для которой следует спуститься вниз на несколько элементов или брать только элементы внутри заданного тега.

В целом, таких правил оказалось достаточно, чтобы описать все встретившиеся нам типы ASN1-кодирования. Ну а после декодирования, получив уже просто список деревьев с параметрами, можно их мапить на результирующий плоский список. Нюансов в CSV мы не встретили (кроме разного вида разделителей), а с BinaryOffset были аналогичные вопросы, как и с ASN1, и решались аналогично.

 

5.       Это, конечно, не сущность БД и не протокол. Это некая программная реализация, состоящая из объектов пакетов с метаданными, шины данных для их передачи, и потоковой реализации, вызывающей интерфейсы акторов в нужный момент.

 

6.       Да, можно запустить на нужном количестве серверов, в том числе виртуальных.

 

7.       В разных ЦОД’х один кластер запустить не получится. Это по большей части ограничение используемого PostgreSQL, так что если его выйдет запустить Active-Active в нескольких ЦОД’х — то можно попробовать.

 

8.       Конфигурация хранится в служебной БД (postgres, oracle), прозрачно экспортируется/импортируется через XML-ки. Каждый оператор (актор) — одна строка таблицы. При редактировании мы пишем в БД новые данные и в исторические таблицы — изменения. Бэкап выполняется как на уровне БД, так и, для удобства работы на нескольких площадках (ПРОМ/тестовые зоны), через автоматический экспорт через файловую систему: измененные сценарии сбрасываются на диск и там попадают под контроль git. Соответственно, поставка сценариев тоже идет через xml-ки, которые автоматически читаются с диска в БД.

Nexign Nord — это система управления базами данных (СУБД) на платформе PostgreSQL. Nexign Nord отличается улучшенными характеристиками безопасности и удобства эксплуатации. Чуть подробнее о продукте расскажем в статье через несколько недель.

Если вы хотите составить собственное мнение о Nexign Nord, то рекомендуем попробовать продукт бесплатно.

Запись опубликована на youtube-канале Nexign team.
Добрый день! Занятия рассчитаны в основном на 2-2,5 часа каждое.
Форматов, которые требуют больше времени, пока не будет.
Часть ребят выполнили тестовое, потому что им было интересно получить фидбек по нему, а на собеседование не были готовы прийти.
Вместе с тем, у нас действительно довольно высокие требования к навыкам и общему инженерному уровню кандидатов.
У разных команд разные подходы, соответственно, и задания отличаются. Это могут быть как задания на логику, так и связанные с написанием кода.
Зависит от команды, но обычно в ходе собеседования обсуждаем вопросы технического характера, даем небольшие задания. И, конечно, рассказываем о компании, о проекте, о задачах, команде, отвечаем на все вопросы.
Мы поделились опытом, может, кому-то это будет интересно.
Заголовок взяли яркий, т.к. и проект сам по себе яркий)
Подробностей сейчас не так много, но в перспективе сможем рассказать механику более детально и разобрать тестовые.
Да, это верно: мы ищем людей которым интересно работать, решать задачи. В ответ мы предлагаем комфортные условия, работу в команде с профессионалами, достойную оплату, перспективы развития, расширенный соцпакет и прочие «плюшки».
RnD занимается продуктовой (не сервисной!) разработкой на основе анализа потребностей рынка. Т.е. мы знаем какой продукт будет нужен нашем клиентам завтра и уже сегодня его создаем. Мы отрабатываем наиболее актуальные тенденций и используем современные методологии и технологии в разработке. Работа над новыми продуктами отвязывает от какого-то определённого шаблона разработки. Инициативность и креатив поощряются, разработчики свободны в выборе конкретных паттернов и механизмов реализации требуемого функционала, к их мнению прислушиваются, оно важно. Каждый потенциально способен подать идею, которая пойдёт в разработку и будет использована для создания продукта, которым будут пользоваться миллионы.
Нашим инженерам должно быть важно не просто написать некий код по тех.заданию и получить за это деньги (хотя это безусловно важно), но мы хотим чтобы каждому человеку в нашей команде было интересно работать над продуктом. Что может мотивировать сильнее, чем интересная задача?
1

Information

Rating
1,859-th
Registered
Activity