1. ИРБИС 64 вер. 2014.1
2. Желательно отладить синхронизацию в серверной части ИРБИС на современных многопроцессорных и 64-битных системах, где количество процессорных ядер намного больше двух. Обновления серверной части, которые мы получили, улучшили стабильность её работы, но всё равно иногда приходится её перезапускать.
3. Запросы на web-irbis у нас идут через mod-proxy с внешнего сервера под linux+apache на внутреннюю систему под windows+apache+webirbis. В этих запросах реальный адрес клиента находится в поле x-forwarded-for, если webirbis сам считает статистику своего использования, в нём должна быть возможность указать, из какого поля брать реальный адрес.
4. По сетевой части. ИРБИС-сервер по умолчанию принимает запросы на порту 6666. Каждый запрос - это довольно короткоживущее tcp-соединение, которое открывается и закрывается с каждого клиента на каждый запрос, было бы полезно, если бы по одному tcp-соединению клиента с сервером проходило несколько (много) запросов, а повторное соединение клиента с сервером делалось бы только при тайм-аутах или других сетевых проблемах.
5. Желательно, чтобы клиентская и серверная часть имели собственную диагностику производительности, хотя бы регистрацию долго обрабатываемых запросов, а лучше всего - для каждого запроса знать, сколько данных было отправлено-принято по сети, и сколько времени клиентская часть ожидала ответа серверной.
6. Желательно иметь возможность инкрементального бэкапа баз, т.е. начальный полный бэкап, и несколько (много) добавочных бэкапов к нему, с перечнем удалённых/изменённых/добавленных записей с момента предыдущего бэкапа, наподобие журнала изменений. Сейчас приходится делать полный бэкап каждой базы, чтобы сохранить её состояние на каждый момент времени, а базы у нас большие.
7. Статистика работы пользователей в АРМ «Читатель». У нас ЛВС библиотеки работает с прокси и учет статистики работы читателей только с сайта не получается полноценной. Желательно иметь возможность учета числа запросов с разделением по БД, число вошедших по номеру своего читательского билета без привязки к книговыдаче, число обращений (открытий) к внешним объектам (полным текстам) в БД «привязанных» к полю 951, число запросов, число автоматизированных заказов. Данные вопросы возникли, т.к. поисковый функционал АРМ «Читатель», по нашему мнению, более удобен читателю, в отличии функционала ОРАС/ВЭБ ИРБИС. Может быть, если этот функционал, можно было максимально полно реализовать в среде ОРАС/ВЭБ ИРБИС, тогда наших вопросов могло и не возникнуть.

Цитата:

3. Запросы на web-irbis у нас идут через mod-proxy с внешнего сервера под linux+apache на внутреннюю систему под windows+apache+webirbis. В этих запросах реальный адрес клиента находится в поле x-forwarded-for, если webirbis сам считает статистику своего использования, в нём должна быть возможность указать, из какого поля брать реальный адрес.

Это исправляется корректной настройкой web-сервера и сервера в целом. См. модуль remoteip_module

> 6. Желательно иметь возможность инкрементального
> бэкапа баз, т.е. начальный полный бэкап, и
> несколько (много) добавочных бэкапов к нему, с
> перечнем удалённых/изменённых/добавленных записей
> с момента предыдущего бэкапа, наподобие журнала
> изменений. Сейчас приходится делать полный бэкап
> каждой базы, чтобы сохранить её состояние на
> каждый момент времени, а базы у нас большие.

Из теории. В основе ИРБИС - не реляционная СУБД, а иерархическая. Либо используйте для резервирования утилиты, наподобие rsync. Либо у Вас есть возможность создать свое научное направление и сделать в нем открытие, решив эту задачу, вначале создав, а затем написав самостоятельно систему журналирования с возможностями резервирования (синхронизации и еще много чего пожелаете) ;)

Здравствуйте

в первоначальном сообщении от levr пункты 2..6 были от меня
теперь меня самого призвали поучаствовать в этом обсуждении.

по пункту 3 - спасибо за совет, попробую. не было времени углубляться в эту тему.

также у меня есть некоторые замечания по пункту 6 :

Если каждая модификация базы может быть упорядочена относительно другой (по времени или по порядковому номеру), то и каждое состояние базы может быть упорядочено (по времени или номеру/версии), причём между каждыми двумя состояниями базы будет находиться совершенно определённая последовательность модификаций, приводящих её из более раннего состояния к более позднему. Это свойство журналируемости не зависит от структуры БД (иерархической, реляционной/табличной или сетевой). Обратный откат журнала в прошлое не требуется, хотя это тоже было бы полезно. Для восстановления базы нужны функции: "взять старое состояние базы" (полный бэкап) и "добавить ноль или более сегментов журнала" (инкрементальных бэкапов), чтобы в итоге получить состояние базы в более поздний момент времени. Для создания бэкапов нужны функции: "создать полный бэкап" и "создать инкрементальный бэкап" (сегмент журнала модификаций с момента предыдущего полного или инкрементального бэкапа).

В широко известных и достаточно развитых СУБД, хранящих наборы данных размером 1 ГБайт и более (mysql, postgresql, ms sql, oracle и т.п), такая функциональность предоставляется по крайней мере из соображений конкуренции и привлекательности для потребителя. Также предоставляются средства репликации, чтобы при отказе хоста с главной копией базы можно было доступиться к её копиям на запасных хостах хотя бы для чтения.
Ирбис64 предоставляет только собственный уникальный формат БД и собственный уникальный механизм [полного] резервного копирования или экспорта в текст, что не очень удобно.

При обсуждении этих пунктов у меня возникло ещё несколько пожеланий :

8. Предусмотреть хранение данных Ирбис во внешней SQL-базе (mysql/postgresql/mssql/oracle/etc). Из университетского курса СУБД [мне] известно, что любую иерархическую или сетевую БД можно представить в реляционном/табличном виде. Я также знаю, что записи Ирбис достаточно динамичны и полиморфны по своим атрибутам, поэтому в качестве системы хранения можно попробовать использовать и более современные non-SQL/document-oriented/key-value/tuple DB типа CouchDB/MongoDB/etc.

Самое главное пожелание - это чтобы применяемая система хранения была открытой [по крайней мере не требующей лицензионных отчислений за её использование], хорошо известной, клиент-серверной и предоставляла достаточно удобный интерфейс доступа и программирования для интеграции её с другими приложениями и системами (.IBF-файлы Ирбис-Администратора я бы так не назвал).

9. было бы просто идеально, если бы сетевой обмен между клиентами и серверами Ирбиса происходил по протоколу, напоминающему http (заголовки и тело запроса, заголовки и тело ответа). И чтобы тела запросов-ответов передавались в каком-то общепринятом на данный момент формате. Например, JSON. И чтобы символы кириллицы или других не-латинских языков тоже передавались в unicode-формате типа UTF8 (вижу вопросы на этом форуме про казахский язык).

дальнейшие пожелания по совершенствованию Ирбиса у меня могут возникнуть легко и свободно, дайте только время с ним попрактиковаться

-- с уважением -- Владимир Мутель -- системный администратор ДОУНБ -- www.libr.dp.ua



Редактировано 1 раз. Последний раз 17.07.2015 20:03 пользователем muwlgr.

Добрый день, Владимир!
Так я ровным счётом про это и писал.
Реализации журналирования в ИРБИС64 нет, поскольку некому заняться. Не паханое поле. Идей журналирования много, особенно, если использовать xml.

По п.8. долгие дебаты шли еще в конце 90-х - начале 2000-х, когда старались подобрать СУБД под ряд проектов автоматизированных библиотечных систем. Если использовать SQL-модель, то хранить всю MARC запись нужно в blob. Если использовать xml модель из того-же berkeleyDB, mongo etc, то просто нужно сделать (создать) адекватную модель, в которой бы нормально были прописаны логика конвертации Rusmarc, unimarc, marc21 и пр. в формат xml и правила xslt преобразования. Но никто из энтузиазма не берется. Хоть и тема эта вполне потягивает на кандидатскую.

Я в своё время пытался делать систему репликации но на модели ИРБИС32 (CDS/ISIS). Посмотрите историю по ссылке: [www.karaush.ru]

А есть ли в этом прямо уж такая критическая необходимость? Я о журналировании. Думаю, что команда разработчиков не будет этим заниматься в ближайшее ХХ-ндесят лет. И тут дело вот в чем: САБ предназначена для библиотечных сотрудников и читателей. На данный момент сделано уже очень многое, но, как показала презентация САБ ИРБИС64+, есть еще куда дальше копать. Причем, серьезно и основательно. И копать по основному руслу. То бишь, создавать новый библиотечный функционал. Отсутствие журналирования не является критической проблемой для работы САБ, не сказывается на ее функциональности в решении повседневных задач и не влияет на удобства работы читателей. Так зачем оно библиотекарям?

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

А вот про идеи использовать в Ирбис другие базы данных - это почти что не реально. И упирается в имеющуюся технологию, лежащую в основе системы. Я о форматах. Тут база данных и система вывода и управления информацией взаимосвязаны. Если менять базы данных, то придется делать или костыли, в которых информация будет извлекаться из новой базы и помещаться перед использованием в виртуальное подобие старой базы, или переделывать вообще всю систему целиком. А это значит писать новую библиотечную систему.

вот ещё одно добавочное требование, возникшее при живой эксплуатации Ирбис64 :

10. Иметь средство для проверки целостности указанного .mst или .bkp-файла (чтобы не нужно было конфигурить базу в Ирбис-сервере, ссылающуюся на этот файл). Иметь средство для текстового экспорта из .mst/.bkp-файла (тоже без необходимости обращаться к базе через сервер).

также мне было бы интересно услышать ответы разработчиков по п 2..5 и 9.
(возможно, по п.2 всё уже решено)

Цитата:

Иметь средство для текстового экспорта из .mst/.bkp-файла

А смысл?! Сделайте экспорт в TXT-формат непосредственно из БД.

После экспорта - импорта txt на большие базы много времени уходит на создание словарей.

muwlgr написал(а):
-------------------------------------------------------
> вот ещё одно добавочное требование, возникшее при
> живой эксплуатации Ирбис64 :
>
> 10. Иметь средство для проверки целостности
> указанного .mst или .bkp-файла (чтобы не нужно
> было конфигурить базу в Ирбис-сервере, ссылающуюся
> на этот файл). Иметь средство для текстового
> экспорта из .mst/.bkp-файла (тоже без
> необходимости обращаться к базе через сервер).
>
> также мне было бы интересно услышать ответы
> разработчиков по п 2..5 и 9.
> (возможно, по п.2 всё уже решено)

Разработчиков интересуют (во всяком случае, здесь, на форуме) ТОЛЬКО пожелания и замечания, касающиеся ФУНКЦИОНАЛА ИРБИС как системы автоматизации библиотек. Т.е. пожелания, связанные с ИРБИС как СУБД, здесь не обсуждаются.

muwlgr написал(а):
-------------------------------------------------------
> вот ещё одно добавочное требование, возникшее при
> живой эксплуатации Ирбис64 :
>
> 10. Иметь средство для проверки целостности
> указанного .mst или .bkp-файла (чтобы не нужно
> было конфигурить базу в Ирбис-сервере, ссылающуюся
> на этот файл). Иметь средство для текстового
> экспорта из .mst/.bkp-файла (тоже без
> необходимости обращаться к базе через сервер).
>
> также мне было бы интересно услышать ответы
> разработчиков по п 2..5 и 9.
> (возможно, по п.2 всё уже решено)


Проверка целостности МСТ файла производится в АРМе Администратор, вне этого АРМа работа с файлом МСТ как-бы особого смысла не имеет. В связи с чем появляется такой острый интерес к диагностики файлов? У вас такие частые проблемы с базами? Какого порядка размера у вас базы?

размеры наших баз:
MARS.mst - 3.7 ГБ, 1.8 млн. записей
ALLP.mst - 2.7 ГБ, 800 тыс. записей
также есть довольно большие BOOKN и KRPER

хочется иметь вспомогательные/служебные/диагностические программы, запускаемые из командной строки, чтобы в своих скриптах реагировать на выводимую ими информацию или код завершения (выхода). Как это обычно сделано даже в самых Микрософтовских СУБД. Потому что когда всё доступно только через GUI, это не слишком удобно. И даже с помощью .ibf-файлов эти задачи решаются лишь частично.

Потерь данных из-за повреждения файлов Ирбиса у нас не было. Но это же не означает, что мы от них застрахованы навсегда в будущем.

Что-то у вас великоваты базы. При таком количестве записей они обычно меньше. Вы реорганизацию баз давно делали?

Нет, делали недавно. И к слову, у нас еще есть Имидж-каталог, который содержит графические образы каталожных карточек. Спасибо за помощь.



Редактировано 1 раз. Последний раз 27.07.2015 12:46 пользователем Anna.