Вопрос по – Почему токийский тиран замедляется в геометрической прогрессии даже после корректировки bnum?

9

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

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

Эта ссылка больше не работает, теперь она наmod.erni.st/2009/08/nosql-if-only-it-was-that-easy BJ Clark
& quot; кто-нибудь сталкивался с этой проблемой до & quot; эти парни, видимоbjclark.me/2009/08/04/nosql-if-only-it-was-that-easy Jeff Atwood

Ваш Ответ

4   ответа
2

под названием Shardy.

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

-1

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

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

Error: User Rate Limit Exceeded
5

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

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

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

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

8

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

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

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

Похожие вопросы