Я тестировал ZODB, создав огромный объект, зафиксированный, затем он дал предупреждение. Далее я начал удаление объекта из root, commit. Файл .fs был по-прежнему 1 ГБ в пространстве. Затем я убил REPL. Я снова открыл python, установил соединение, но теперь я не могу избавиться от этого 1 ГБ файла (кроме попытки удалить его с самого диска).ZODB не освобождает место на жестком диске
код что-то вроде:
storage = FileStorage('Data.fs')
db = DB(storage)
connection = db.open()
root = connection.root()
Вслед за созданием какой-то огромный объект и сначала я на самом деле сделал
root['bigObj'] = 'small_str',
transaction.commit()
, чтобы попытаться переписать. После этого я просто удалил ключ/значение.
Какую часть мне не хватает?
Btw, я поддерживаю список, который я разделяю между потоками. Это очень просто с ZODB, но этот список сильно меняется. Учитывая эту ситуацию, связанную только с приложением, вы, возможно, знаете какой-то совет (возможно, это не очень хорошая идея)? – PascalVKooten
ZODB не должен быть проблемой для большинства случаев использования - если вы используете собственные списки ZODB, тогда он должен писать только дельта базы данных для каждого обновления (хотя мне нужно это подтвердить). См. Http://zodborg.readthedocs.org/en/latest/documentation/guide/modules.html#persistent-list-persistentlist - используйте PersistentList вместо []. Так работает ZODB - вы действительно не можете изменить природу зверя. Если вам нужно иметь дело с большими, изменчивыми блоками, я предлагаю вам рассмотреть альтернативные базы данных. Ниже приведен один подход для поведения ZODB на PostgreSQL. Https://github.com/Shoobx/pjpersist –
@PascalvKooten: существуют бэкэнды ZODB, которые могут быть настроены для отказа от исторических изменений; 'RelStorage' может это сделать. Байт-файл по умолчанию «FileStorage», однако, не может. –