Исходное сообщение
"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.10..." Отправлено erthink, 12-Окт-21 08:40
> Ясно. > Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать > с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль > перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему > прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить? > Как там вообще с созданием собственных схем, а так же их > изменением "на лету"? > Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно > в форме файлов, обычно XMLек (но чем меньше работы с этим > чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать). Схемы в LDAP достаточно просты - по сути два списка: что может быть и что должно быть. Менять их "на лету", если где-то и можно, то только так, чтобы не было конфликтов с уже записанными данными (т.е. примерно только добавлять список необязательных атрибутов). Во всех LDAP-ах внутри линейная схема хранения, т.е. для каждого элемента формируется ключ по его пути в иерархии. Если вы представляете как эффективно сделать такой маппинг в вашем случае, то вероятно сможете реализовать необходимое поверх любого более-менее приличного key-value (я бы взял libfpta, либо тарантул).

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Ясно. >> Вопрос - если хочется хранить накопляемые данные в иерархическом виде, лучше делать >> с "нуля" на каком-нибудь тарантуле, редисе и тд (а в скуль >> перекачивать и использовать только для отчетов)? Или ЛДАП имеющий уже систему >> прав доступа, апи для язычков, прочий обвес можно/нужно под это приспособить? >> Как там вообще с созданием собственных схем, а так же их >> изменением "на лету"? >> Объем (и частота прибытия) данных не столь велИк (не биллинг). Приходят обычно >> в форме файлов, обычно XMLек (но чем меньше работы с этим >> чудесным форматом тем лучше, поэтому лучше уж парсить и запихивать). > Схемы в LDAP достаточно просты - по сути два списка: что может > быть и что должно быть. > Менять их "на лету", если где-то и можно, то только так, чтобы > не было конфликтов с уже записанными данными (т.е. примерно только добавлять > список необязательных атрибутов). > Во всех LDAP-ах внутри линейная схема хранения, т.е. для каждого элемента формируется > ключ по его пути в иерархии. > Если вы представляете как эффективно сделать такой маппинг в вашем случае, то > вероятно сможете реализовать необходимое поверх любого более-менее приличного key-value > (я бы взял libfpta, либо тарантул).
	Введите код, изображенный на картинке: