RocksDB: каждый открытый / закрытый db создает новый файл SST / LOG? - PullRequest
0 голосов
/ 05 декабря 2018

Я пытаюсь разработать код на языке C, используя простой API, предоставляемый в дистрибутиве.Моя цель - записать короткие строки в БД, чтобы другой процесс мог прочитать их как можно скорее.Поэтому я закрываю БД, как только запись любой строки завершена, чтобы разблокировать БД, чтобы другой процесс мог прочитать эту строку.Задание будет считаться выполненным, когда я получу работающий код, но ... скорость вставки строк очень скоро замедляется.Мы начинаем с ~ 50 вставок в секунду, и через минуту максимум будет не более 10 вставок в секунду.Я попытался выяснить причину, и я обнаружил, что каждая вставка создаст свой собственный маленький файл SST, всего с одной строкой, и если я включу WAL и затем избежу сброса, будет слишком много файлов журнала wal, также столько один ряд.Было бы также ~ 2000 файлов «LOG.old» в секунду, каждый удваивал и удваивал список опций - и это то, что я думаю, заставляло все работать так медленно.Сначала я пытался избежать промывки, затем пытался вызвать периодическую промывку, но это было бесполезно.Интересно, есть ли варианты, чтобы иметь возможность многократно закрывать и открывать БД для записи, но все же не создавать файл SST или WAL каждый раз, когда мы это делаем?

1 Ответ

0 голосов
/ 12 декабря 2018

Не похоже, что вы должны использовать rockdb для этого, как вы делаете это сейчас.Если у вас есть БД, открытая в течение такого короткого времени, она не может выполнять уплотнения, и все ваши данные останутся в WAL или на уровне 0. Только накладные расходы на открытие всех файлов, содержащих несжатые SST, высоки ивсе SST уровня 0 должны быть проверены на чтение, потому что они внутренне упорядочены, но не имеют порядка на уровне, что замедлит чтение rockdb.

Возможно, вам следует использовать базу данных / хранилище на основе демона(memcached?) и просто обмениваться данными через IPC (unix-socket?) из процессов, потому что открытие базы данных всегда происходит медленно для одной операции чтения / записи.

...