Приветствую, @SabMakc! Спасибо за вопросы и замечания.
Про SQLite. SQLite - отличный инструмент, который хорошо себя зарекомендовал и часто используется там, где нужна встраиваемая бд. Но он также имеет известные ограничения на конкурентную запись. При использовании LDAP-каталогов такие ситуации возможны. Соглашусь с вами, тема репликации действиелно не затрагивалась, она заслуживает отдельной публикации. Попробую немного ее затронуть. В зависимости от масштабов организации, ее географического распределения и требований к отказоустойчивости и производительности, в одном предприятии могут быть десятки (иногда сотни) контроллеров доменов (отдельных инстансов LDAP-каталога). Каждое предприятие строит свою собственную топологию репликации, в которой отдельные контроллеры доменов объединяются в сайты (например, в рамках одного офиса). Существует как репликация в пределах сайта, так и репликация между сайтами. Как уже отмечалось, данные в основном читаются чаще, чем пишутся, но сами данные обновляются достаточно регулярно. Это может включать добавление пользователей, их включение или исключение из групп, обновление паролей, доступов и разрешений (ACL), а также обновление атрибутов записей, таких как фиксация неудачных попыток входа или последнего времени входа и др.. Репликация и обновления данных на контроллере домена могут приводить к возникновению конфликтов при одновременной записи. Использование очередей для предотвращения подобных ситуаций возможно, но не всегда является оптимальным решением. В таких случаях проще выбрать готовое специализированное решение.
Про хранение LDAP-каталога в памяти. Объем данных в LDAP-каталоге растет пропорционально числу объектов, таких как пользователи, группы, рабочие станции, DNS-записи и ACL, и может варьироваться от сотен мегабайт для небольших организаций до десятков гигабайт для крупных предприятий. Эти значения актуальны как для MSAD (NTDS.DIT), так и для нашего каталога. Хранение такого объема данных в памяти сталкивается с ограничениями аппаратных средств и проблемами отказоустойчивости в случае аварийного завершения работы или переполнения памяти. BadgerDB как раз в этом плане хорошо подходит, он разделяет ключи и значения, храня ключи в оперативной памяти, что ускоряет поиск по ним, а сами данные сохраняет на диске. Для отказоустойчивости у него есть WAL, куда сначала попадают данные при записи, а после этого уже в LSM-tree что дает ему больше устойчивости к сбоям.
Приветствую, @SabMakc!
Спасибо за вопросы и замечания.
Про SQLite.
SQLite - отличный инструмент, который хорошо себя зарекомендовал и часто используется там, где нужна встраиваемая бд. Но он также имеет известные ограничения на конкурентную запись. При использовании LDAP-каталогов такие ситуации возможны.
Соглашусь с вами, тема репликации действиелно не затрагивалась, она заслуживает отдельной публикации. Попробую немного ее затронуть. В зависимости от масштабов организации, ее географического распределения и требований к отказоустойчивости и производительности, в одном предприятии могут быть десятки (иногда сотни) контроллеров доменов (отдельных инстансов LDAP-каталога). Каждое предприятие строит свою собственную топологию репликации, в которой отдельные контроллеры доменов объединяются в сайты (например, в рамках одного офиса). Существует как репликация в пределах сайта, так и репликация между сайтами.
Как уже отмечалось, данные в основном читаются чаще, чем пишутся, но сами данные обновляются достаточно регулярно. Это может включать добавление пользователей, их включение или исключение из групп, обновление паролей, доступов и разрешений (ACL), а также обновление атрибутов записей, таких как фиксация неудачных попыток входа или последнего времени входа и др..
Репликация и обновления данных на контроллере домена могут приводить к возникновению конфликтов при одновременной записи. Использование очередей для предотвращения подобных ситуаций возможно, но не всегда является оптимальным решением. В таких случаях проще выбрать готовое специализированное решение.
Про хранение LDAP-каталога в памяти.
Объем данных в LDAP-каталоге растет пропорционально числу объектов, таких как пользователи, группы, рабочие станции, DNS-записи и ACL, и может варьироваться от сотен мегабайт для небольших организаций до десятков гигабайт для крупных предприятий. Эти значения актуальны как для MSAD (NTDS.DIT), так и для нашего каталога. Хранение такого объема данных в памяти сталкивается с ограничениями аппаратных средств и проблемами отказоустойчивости в случае аварийного завершения работы или переполнения памяти.
BadgerDB как раз в этом плане хорошо подходит, он разделяет ключи и значения, храня ключи в оперативной памяти, что ускоряет поиск по ним, а сами данные сохраняет на диске. Для отказоустойчивости у него есть WAL, куда сначала попадают данные при записи, а после этого уже в LSM-tree что дает ему больше устойчивости к сбоям.