Старый вопрос, но это касается файлов журналов. Вы не хотите копировать миллиард записей при каждом удалении. Это может быть решено путем регистрации всех «транзакций» или обновлений нового и отдельного файла. Эти файлы должны быть разбиты на разумные размеры.
Чтобы прочитать кортеж, вы начинаете с самого нового файла журнала, пока не найдете свой ключ, а затем остановитесь. Чтобы обновить или вставить, просто добавьте новую запись в самый последний файл журнала. Удаление по-прежнему является записью в журнале.
Необходимо периодически запускать процесс объединения, который будет сканировать каждый файл журнала и записывать другого мастера. По мере чтения каждый НОВЫЙ ключ записывается в новый мастер, а повторяющиеся (старые) ключи пропускаются до тех пор, пока вы не выполните его полностью. Если вы обнаружили удаляемую запись, отметьте ее в отдельном списке удаления, пропустите эту запись и проигнорируйте последующие записи с этим ключом.
Это показалось вам простым, но помните, что вы можете заблокировать / портировать ваш файл, так как вы, скорее всего, сканируете указанные файлы журнала в обратном порядке, или вы по крайней мере seek() достигнете максимального размера и будете писать в обратном порядке вместо чтения .
Я сделал это точно с миллиардами строк данных. Вы просто заново изобретаете базы данных с последовательным доступом.