Доброго времени суток, уважаемые коллеги. Нужна консультация по удалению данных из GlobalsDb.

Операционка Windows 7 x64, база GlobalsDb, доступ через java-интерфейс. Приведу упрощенное описание структуры базы данных.
В базе есть два основных глобала:
1. objects - содержит перечень номеров объектов от 1 и далее как минимум до 50 млн. Под каждым объектом лежит набор ключей и значений. Набор ключей - это ограниченное множество строк (порядка 30). Обычно у каждого объекта есть порядка 20 ключей. Каждый конкретный ключ конкретного объекта содержит одно значение.
objects
=1
==k1=v1
==k2=v2
=2
==k2=v6
==k3=v4
=3
==k1=v5
=4
==k1=v1
...
2. indices - содержит инвертированный индекс всех ключей и их значений, чтобы по заданному наименованию ключа (по сути характеристика) и конкретному значению получить перечень объектов, соответсвующих данному критерию поиска
indices
=k1
==v1
===1
===4
==v5
===3
=k2
==v2
===1
==v6
===2
=k3
==v4
===2
...
Думаю, что идея понятна. Поиск выполняется относительно быстро, а вот с производительностью удаления есть проблема: если удалить всю базу - все удаляется быстро (порядка нескольких секунд), т.к. удаляются глобалы целиком. А вот если нужно удалить, например, 90% объектов (по идентификаторам), то все начинает сильно тормозить (операция не завершается и за несколько часов). Т.е. я беру, например, массив из 40 млн. идентификаторов объектов и в цикле начинаю бежать по нему:
1. сначала достаю из глобала objects ключи и значения
2. для каждого ключа и значения метаданных иду в глобал indices, выполняю навигацию по ключу, затем значению, затем номеру object и делаю kill этого узла.
3. пункт 2 делаю, пока не удалю все индексы для текущего объекта.
4. удаляю сам текущий объект с помощью kill.
5. перехожу к следующему объекту и опять к пункту 2.

Если я правильно понимаю причины подтормаживаний, то дело в дисковой подсистеме, для которой достаточно тяжело дается эта операция постоянного "метания" по диску (обычный, не твердотельный), поскольку в таком режиме данные не могут быть расположены смежно на диске.

Инвертированный индекс нужен, т.к. одно из требований - поиск по произвольным ключам объектов.

Какие варианты рассматривал:
1. Есть вариант с самописным экспортом базы в другой файл, а затем удалить базу целиком и загрузить самописным экспортом данные в чистую базу. Это может работать в сценарии, когда удаляется бОльшая часть данных (например, 90%).
2. Разбить базу на тома (добавив еще один узел в древовидную иерархию), и тогда появляется возможность удалять данные целыми томами, но это не решит задачу произвольного удаления объекта по его номеру (зато можно удалять целыми диапазонами, если все номера попадают в диапазон тома). Еще один минус в том, что индекс тоже придется делать для отдельного тома.

Вопросы:
1. Можно ли как-то ускорить (уменьшить время удаления хотя бы до десятков минут-часа) данную операцию с использованием GlobalsDb? Реорганизовать данные наподобие томов, может что-то еще?
2. Что может дать переход на Cache?

UPD: s ^objects(1,"k1")="v1"
 s ^objects(1,"k2")="v2"
 s ^objects(2,"k2")="v6"
 s ^objects(2,"k3")="v4"
 s ^objects(3,"k1")="v5"
 s ^objects(4,"k1")="v1"
 
 s ^indices("k1","v1",1)=""
 s ^indices("k1","v1",4)=""
 s ^indices("k1","v5",3)=""
 s ^indices("k2","v2",1)=""
 s ^indices("k2","v6",2)=""
 s ^indices("k3","v4",2)="" Модератор: Добавил структуру глобалов

krvsa servit , спасибо...

TryCache , в качестве эксперимента...
Попробуй следующее. Создай еще один индекс, такого типа. Т.о. удаление будешь вести по новому индексу... А потом просто прибьешь два узла с ИДишником...
Возможно будет быстрее.




Это


будет соответствовать


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

П.С.М.TryCacheсначала достаю из глобала objects ключи и значения
т.е. на это шаге вы знаете значение kx, vx и номер объекта?

автордля каждого ключа и значения метаданных иду в глобал indices, выполняю навигацию по ключу, затем значению, затем номеру object и делаю kill этого узла.
Правильно ли я понял, что на этом шаге вы запускаете цыклы по "миллионам ваших записей" в глобале ^indices и на каждой итерации проверяете совпадает ли значение текущих узлов с "kx, vx и номер объекта" найденными на предыдущем шаге, вместо простого:


Так?
на первый вопрос да , когда считан объект, то я знаю ключи и значения.
На второй вопрос скорее нет , т.к. делается appendSubscript(key), затем appendSubscript(value), затем appendSubscript(objId), затем kill для NodeReference. Думаю, это соответствует kill ^indices(kx,vx,"номер объекта"), правда не прямо, но с глобалс по другому и не получится.

Кстати, а насколько быстро работает kill ^indices(kx,vx,"номер объекта")? при таких данных там таких записей более миллиарда и они удаляются в общем случае в произвольном порядке. Т.е. нужно удалять порядка 300000 записей в секунду в течение часа. Это возможно физически?

servitЕщё данные можно не удалять физически, а лишь помечать как удалённые; реально же удалять потом в фоне и в несколько потоков.
А как это сделать в GlobalsDb? Принимая во внимание, что есть два глобала и удалить нужно из двух мест?