Почему токийский тиран замедляется в геометрической прогрессии даже после корректировки bnum?
Кто-нибудь успешно использовал Токийский кабинет / Токийский тиран с большими наборами данных? Я пытаюсь загрузить подграф источника данных Википедии. После попадания около 30 миллионов записей, я получаю экспоненциальное замедление. Это происходит как с базами данных HDB, так и с базами данных BDB. Я настроил bnum на 2-4x ожидаемое количество записей для случая HDB с небольшим ускорением. Я также установил xmsiz на 1 Гб или около того, но в конечном итоге я все же ударил стену.
Похоже, что Tokyo Tyrant - это база данных в памяти, и после того, как вы превысите xmsiz или свою оперативную память, вы получите плохо используемую базу данных. Кто-нибудь еще сталкивался с этой проблемой раньше? Вы смогли решить это?
4 ответа
Я думаю, что, возможно, взломал этот, и я не видел это решение где-либо еще. В Linux, как правило, есть две причины, по которым Токио начинает замедляться. Давайте пройдемся по обычным преступникам. Во-первых, если вы устанавливаете свой bnum слишком низким, вы хотите, чтобы он был как минимум равен половине количества элементов в хэше. (Желательно больше.) Во-вторых, вы хотите установить xmsiz так, чтобы он был близок к размеру массива сегментов. Чтобы получить размер массива сегментов, просто создайте пустую базу данных с правильным значением bnum, и Tokyo инициализирует файл до соответствующего размера. (Например, bnum=200000000 составляет около 1,5 ГБ для пустой базы данных.)
Но теперь вы заметите, что он все еще замедляется, хотя и немного дальше. Мы обнаружили, что хитрость заключалась в том, чтобы отключить журналирование в файловой системе - по некоторым причинам журналирование (на ext3) резко возрастает, когда размер вашего хеш-файла превышает 2-3 ГБ. (То, как мы поняли это, было всплесками ввода-вывода, не соответствующими изменениям файла на диске, наряду с пакетными процессорами демона kjournald)
Для Linux просто размонтируйте и перемонтируйте раздел ext3 как ext2. Создайте свою базу данных и перемонтируйте как ext3. Когда журналирование было отключено, мы могли без проблем создавать 180 МБ ключей размером с ключ.
Токио чудесно масштабируется! Но вы должны правильно настроить bnum и xmsiz. bnum должен быть в 0,025–4 раза больше записей, которые вы планируете хранить. xmsiz должен соответствовать размеру BNUM. Также установите opts=l, если вы планируете хранить более 2 ГБ.
Посмотрите пост Грега Фодора выше о получении значения для размера xmsiz. Обратите внимание, что при установке xmsiz значение указывается в байтах.
Наконец, если вы используете хеш на основе диска, очень, очень, ОЧЕНЬ важно отключить ведение журнала в файловой системе, на которой живут данные Токио. Это верно для Linux, Mac OSX и, вероятно, Windows, хотя я еще не тестировал там.
Если ведение журнала включено, вы увидите серьезные падения производительности при приближении к 30 с лишним миллионам строк. С отключенным ведением журналов и другими параметрами Tokyo - отличный инструмент.
Я начинаю работать над решением по добавлению шардинга в кабинет Токио под названием Шарди.
Магазин ключей в Токийском Кабинете действительно хорош. Я думаю, что люди называют это медленным, потому что они используют магазин, подобный столу в Токийском Кабинете.
Если вы хотите сохранить данные документа, используйте mongodb или другой движок nosql.