Про архивы больших баз

[Gandliar]

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

Есть база, в ней более миллиона доков. Шевелится медленно. Возник вопрос, что часть документов необходимо перекинуть в архивную базу или в несколько архивных баз, например по годам.
Подскажите пожалуйста идеологию, как лучше решить эту задачу, раньше не сталкивался.

Основные пожелания заказчика - чтобы рабочая база шевелилась побыстрее, и было потом удобно искать в архиве.

Навскидку приходит мысль сделать так:
1. В рабочей базе отметить архивные документы признаком в каком нибудь поле doc.replaceItemValue("isArchive","1")
2. Настроить реплику в одну сторону на архивный сервер из рабочей бд -> в архивную все документы, без ACL
3. В рабочей бд сделать агент, который по документам isArchive="1", проверяет наличие документа в архивной БД, и если он там есть, делает хард удаление документа в рабочей бд.
По идее ссылки в почте у пользователей продолжат работать.

Что думаете о таком подходе, или что посоветуете.
Заранее благодарю.

 

[lmike]

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

Есть база, в ней более миллиона доков. Шевелится медленно. Возник вопрос, что часть документов необходимо перекинуть в архивную базу или в несколько архивных баз, например по годам.
Подскажите пожалуйста идеологию, как лучше решить эту задачу, раньше не сталкивался.

Основные пожелания заказчика - чтобы рабочая база шевелилась побыстрее, и было потом удобно искать в архиве.

Навскидку приходит мысль сделать так:
1. В рабочей базе отметить архивные документы признаком в каком нибудь поле doc.replaceItemValue("isArchive","1")
2. Настроить реплику в одну сторону на архивный сервер из рабочей бд -> в архивную все документы, без ACL
3. В рабочей бд сделать агент, который по документам isArchive="1", проверяет наличие документа в архивной БД, и если он там есть, делает хард удаление документа в рабочей бд.
По идее ссылки в почте у пользователей продолжат работать.

Что думаете о таком подходе, или что посоветуете.
Заранее благодарю.

делать с учётом бизнес-логики...
копировать доки и связанные с ними
я делаю так:
- получаю список юнидов основных доков
- формирую чайлды
- копирую всё с чайлдами
- если всё норм - по этому списку всё удаляю из основной БД
- есть проверка необходимости копировать - время изменения в осн. БД
т.о. вё упирается в получение первоначальной коллекции (по к-л принципу)

Function CopyNDC2DB(NDC As NotesDocumentCollection, db As NotesDatabase)
    Dim routineName As String
    routineName="CopyNDC2DB"
    On Error GoTo ErrH
'your code here
    Dim v, doc As NotesDocument
    v=Split("","")
    Set doc=NDC.Getfirstdocument()
    Do While Not doc Is Nothing
        Dim tmp As NotesDocument
        'check destination db for doc unid
        Set tmp=GetDocumentByUNIDSilent(db, doc.Universalid)
        Dim isNew As Boolean, bCopied As Boolean
        isNew=False:bCopied=False
        'если док не копировали
        If  tmp Is Nothing Then
            Set tmp=db.Createdocument()
            isNew=True
            tmp.Universalid=doc.Universalid
        End If
        'если док новый или изменился с момента копирования
        'Print {orig/copy:} doc.Lastmodified "/" tmp.Lastmodified
        Dim dt As New NotesDateTime({}), dt1 As New NotesDateTime({})
        dt.Lslocaltime=doc.Lastmodified
        dt1.Lslocaltime=tmp.Lastmodified
        'doc is newer to tmp
        If isNew Or (dt.Timedifference(dt1)>0) Then
            Call doc.Copyallitems(tmp, True)
            Call tmp.Save(True,False)
            bCopied=True
        End If
        If bCopied Then
            If IsEmpty(v) Then
                v(0)=doc.Universalid
            Else
                v=ArrayAppend(v,doc.Universalid)
            End If
        End If
        Set doc=NDC.Getnextdocument(doc)
    Loop
    CopyNDC2DB=v
Quit:
    Exit Function
ErrH:
    Error Err, RaiseError
    Resume Quit
End Function

 

[VladSh]

Что думаете о таком подходе, или что посоветуете.

Интересно. Необычно) Но негибко. Агент со своей логикой лучше.

И ещё надо учитывать, что каждое сохранение документа в базе ведёт к тому, что количества "заглушек" (не тех, что от удаления остаются, но похожих) в базе увеличивается, что никак не способствует скорости работы базы. То есть при сохранении вновь созданного документа в базе он в количестве одна штука. При повторном сохранении - две штуки (видимый всеми и кодом + предыдущая "версия", которая недоступна никому), и т.д.. И эти огрызки уходят только после компакта.
В предлагаемом Вами варианте в результате будет добавлена ещё одна "заглушка" от сохранения поля, а потом останется заглушка от удаления. Если делать агентом, то только заглушка от удаления.

 

[Gandliar]

Интересно. Необычно) Но негибко. Агент со своей логикой лучше.

И ещё надо учитывать, что каждое сохранение документа в базе ведёт к тому, что количества "заглушек" (не тех, что от удаления остаются, но похожих) в базе увеличивается, что никак не способствует скорости работы базы. То есть при сохранении вновь созданного документа в базе он в количестве одна штука. При повторном сохранении - две штуки (видимый всеми и кодом + предыдущая "версия", которая недоступна никому), и т.д.. И эти огрызки уходят только после компакта.
В предлагаемом Вами варианте в результате будет добавлена ещё одна "заглушка" от сохранения поля, а потом останется заглушка от удаления. Если делать агентом, то только заглушка от удаления.

Про заглушки второго вида для меня новость

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

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

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

А что думаете базы по годам или все в одну?

 

[garrick]

А ещё в Domino есть штатный механизм архивации, где можно настроить правило с формулой отбора.

 

[VladSh]

А что думаете базы по годам или все в одну?

По годам конечно хорошо, но возможно у вас за год не наберётся нужное количество документов для архива. Вроде бы удобно искать, но как показывает практика, невозможно переместить в архив документы одного года. И какой год брать в качестве отсчёта? Дату создания документа, дату последнего изменения или может быть какую-нибудь дату из полей документа? А потом окажется, что одним подразделениям подходит одна дата, а другим нет... И потом возникнут вопросы типа "Я искала в этом годовом архиве, а документа там нет, почему? Я потеряла кучу времени!.."
Я бы отталкивался от количества документов в одном томе. Из нашего опыта и наших условий (железо) архивная база неплохо шевелится, если в ней около 1 млн. документов (меньше - нет смысла создавать отдельную базу). Примите какое-нибудь число, исходя из своих условий, и от него отталкивайтесь. Надо написать агент в архивной базе, который будет уведомлять о приближении этого порогового значения документов. Ну и сразу же создать 2-й том. И быть готовым переключить поток туда.
И лучше сразу нумеровать тома, типа achive_1.nsf и т.д. Это потом реально поможет - можно в настройках будет указать перечень активных томов 1-12, и массив путей к архивным базам быстро получить в цикле, иначе объем настроечного профайла будет постоянно увеличиваться (у нас просто ещё масса тематических архивов по томам), и можно дойти до предела (смотря какая версия LND конечно).

А в плане агента архивации... Ну, например, у нас на каждом этапе работы с документом (при отправке кому-то) создаётся отдельный документик с параметрами отправки, и где делаются отметки. Так вот эту инфу при архивировании нужно куда-то девать. В одном проекте я просто брал всю эту инфу из пользовательского RichText-отчёта и вкладывал отдельным nonsummary-полем в документ, а все эти десятки доков по каждому документу просто удалял. При открытии истории по документу просто отображается значение этого поля и всё Максимально быстро и просто, и пользователь визуально не видит разницы, - то ли он сгенерировал отчёт в рабочей базе, то ли открыл в архивной. Только в архивной не будет тратиться время на генерацию отчёта.
Можно эти же данные собирать, к примеру в json (в случае если их могут читать другие системы, они же и будут сами выводить пользователю эту инфу в нужном им визуальном представлении).
Это я всё к тому, что при наличии серьёзной функциональности простое решение с репликацией доков в архив не подойдёт, потому и важна логика. Лучше к этому вопросу подходить комплексно.

 

[Gandliar]

Большое спасибо всем, кто ответил!