Комментарии 4
Интересно читать об опыте создания российского аналога AD.
Также хотелось бы узнать на каком этапе внедрения находится ваш продукт? С какими проблемами сталкивались при внедрении и как их решали?
Думаю этот опыт будет полезен многим разработчикам-импортозаместителям
Я бы сказал, что тема отказа от реляционной БД не раскрыта.
Например, SQLite мог бы заменить BadgerDB, если нужна встроенная БД.
Графы не так хорошо ложатся в реляционную БД - и это так (особенно если говорить о производительности). Но на Key/Value ложатся ничуть не лучше.
В целом в выборе Key/Value не вижу ничего плохого, но обоснование "почему не реляционная БД", на мой взгляд, очень слабое. Было бы достаточно и "Key/Value работает быстрее, а данные ложатся без особых проблем".
P.S. а о каких объемах данных идет речь? Может проще было в памяти хранить, а на диск выгружать только текущий срез или изменения для загрузки при рестарте?
P.P.S. не раскрыта реализация репликации - а это было бы даже интереснее )
Может блокчейн организовали, например, на базе CometBFT (если нет особых требований к мгновенному подтверждению записи, да объемы на запись не на сотни-тысячи строк в секунду - то почему бы и нет). Может алгоритм консенсуса Raft задействовали (к слову, хорошо масштабируется на чтение).
Приветствую, @SabMakc!
Спасибо за вопросы и замечания.
Про SQLite.
SQLite - отличный инструмент, который хорошо себя зарекомендовал и часто используется там, где нужна встраиваемая бд. Но он также имеет известные ограничения на конкурентную запись. При использовании LDAP-каталогов такие ситуации возможны.
Соглашусь с вами, тема репликации действиелно не затрагивалась, она заслуживает отдельной публикации. Попробую немного ее затронуть. В зависимости от масштабов организации, ее географического распределения и требований к отказоустойчивости и производительности, в одном предприятии могут быть десятки (иногда сотни) контроллеров доменов (отдельных инстансов LDAP-каталога). Каждое предприятие строит свою собственную топологию репликации, в которой отдельные контроллеры доменов объединяются в сайты (например, в рамках одного офиса). Существует как репликация в пределах сайта, так и репликация между сайтами.
Как уже отмечалось, данные в основном читаются чаще, чем пишутся, но сами данные обновляются достаточно регулярно. Это может включать добавление пользователей, их включение или исключение из групп, обновление паролей, доступов и разрешений (ACL), а также обновление атрибутов записей, таких как фиксация неудачных попыток входа или последнего времени входа и др..
Репликация и обновления данных на контроллере домена могут приводить к возникновению конфликтов при одновременной записи. Использование очередей для предотвращения подобных ситуаций возможно, но не всегда является оптимальным решением. В таких случаях проще выбрать готовое специализированное решение.
Про хранение LDAP-каталога в памяти.
Объем данных в LDAP-каталоге растет пропорционально числу объектов, таких как пользователи, группы, рабочие станции, DNS-записи и ACL, и может варьироваться от сотен мегабайт для небольших организаций до десятков гигабайт для крупных предприятий. Эти значения актуальны как для MSAD (NTDS.DIT), так и для нашего каталога. Хранение такого объема данных в памяти сталкивается с ограничениями аппаратных средств и проблемами отказоустойчивости в случае аварийного завершения работы или переполнения памяти.
BadgerDB как раз в этом плане хорошо подходит, он разделяет ключи и значения, храня ключи в оперативной памяти, что ускоряет поиск по ним, а сами данные сохраняет на диске. Для отказоустойчивости у него есть WAL, куда сначала попадают данные при записи, а после этого уже в LSM-tree что дает ему больше устойчивости к сбоям.
BadgerDB как бэкенд для LDAP-каталога