Почему токийский тиран замедляется в геометрической прогрессии даже после корректировки bnum? - PullRequest
9 голосов
/ 27 июня 2009

Кто-нибудь успешно использовал Токийский кабинет / Токийский тиран с большими наборами данных? Я пытаюсь загрузить подграф источника данных Википедии. После попадания около 30 миллионов записей, я получаю экспоненциальное замедление. Это происходит как с базами данных HDB, так и с базами данных BDB. Я настроил bnum на 2-4x ожидаемое количество записей для случая HDB с небольшим ускорением. Я также установил xmsiz на 1 ГБ или около того, но в итоге все равно ударил стену.

Похоже, что Tokyo Tyrant - это база данных в памяти, и после того, как вы превысите xmsiz или вашу RAM, вы получите едва используемую базу данных. Кто-нибудь еще сталкивался с этой проблемой раньше? Вы смогли решить это?

Ответы [ 4 ]

8 голосов
/ 07 марта 2010

Я думаю, что, возможно, взломал этот, и я не видел это решение где-либо еще. В Linux, как правило, есть две причины, по которым Токио начинает замедляться. Давайте пройдемся по обычным преступникам. Во-первых, если вы устанавливаете свой bnum слишком низким, вы хотите, чтобы он был как минимум равен половине количества элементов в хэше. (Желательно больше.) Во-вторых, вы хотите установить xmsiz так, чтобы он был близок к размеру массива сегментов. Чтобы получить размер массива корзины, просто создайте пустую базу данных с правильным значением bnum, и Токио инициализирует файл до соответствующего размера. (Например, bnum = 200000000 составляет около 1,5 ГБ для пустой базы данных.)

Но теперь вы заметите, что он все еще замедляется, хотя и немного дальше. Мы обнаружили, что хитрость заключалась в том, чтобы отключить журналирование в файловой системе - по некоторым причинам журналирование (на ext3) резко возрастает, когда размер вашего хеш-файла превышает 2-3 ГБ. (То, как мы это поняли, было всплесками ввода-вывода, не соответствующими изменениям файла на диске, наряду с пакетными процессорами демона kjournald)

Для Linux просто размонтируйте и перемонтируйте раздел ext3 как ext2. Создайте свою базу данных и перемонтируйте как ext3. Когда журналирование было отключено, мы могли без проблем создавать 180 МБ ключей размером с ключ.

5 голосов
/ 20 мая 2010

Токио прекрасно весит !! Но вы должны правильно настроить bnum и xmsiz. bnum должен быть в 0,025–4 раза больше записей, которые вы планируете хранить. xmsiz должен соответствовать размеру BNUM. Также установите opts = l, если вы планируете хранить более 2 ГБ.

См. Пост Грега Фодора выше о получении значения для размера xmsiz. Обратите внимание, что при установке xmsiz значение указывается в байтах.

Наконец, если вы используете хеш на основе диска, очень, очень, ОЧЕНЬ важно отключить ведение журнала в файловой системе, в которой живут данные Токио. Это верно для Linux, Mac OSX и, вероятно, Windows, хотя я еще не тестировал там.

Если включено ведение журнала, при приближении к 30 с лишним миллионам строк вы увидите значительное снижение производительности. С отключенным ведением журналов и другими параметрами Токио - отличный инструмент.

2 голосов
/ 10 августа 2009

Я начинаю работу над решением по добавлению шардинга в кабинет Токио под названием Shardy.

http://github.com/cardmagic/shardy/tree/master

0 голосов
/ 05 мая 2010

Магазин ключей в Токийском Кабинете действительно хорош. Я думаю, что люди называют это медленным, потому что они используют магазин, подобный столу в Токийском Кабинете.

Если вы хотите сохранить данные документа, используйте mongodb или другой движок nosql.

...