Как увеличить скорость чтения rethinkdb?

Question

[Виталий]

Всем добрый день. Собственно сабж, в функции генераторе получаю курсор, через курсор некст получаю данные, последовательное чтение на мой взгляд выглядит каким - то тормозом, кто может что подсказать по поводу ускорения производительности? может буфер какой нужно настроить при конфигурировании. БД исполняется на вин64.

Comments

[napa3um]

Не, всё нормально.

[Виталий]

napa3um: я ждал более конструктивных ответов. Ваш же без аргументов и альтернативных путей....

[napa3um]

Виталий: каков вопрос - таков ответ.

[Виталий]

napa3um: вопрос адекватный, читать 600 тыс записей два часа на мой взгляд крайне не производительно. Я уже молчу про попытки получить distincct по индексу на этот объем.

[napa3um]

Виталий: да, согласен.

[Виталий]

napa3um: отсюда и мой вопрос, возможно я не понял архитектуру сие решения и делаю что-то не так, или в моейм случае это просто совсем не тот инструмент, которым надо пользоваться.
Меня подкупил стрим изменений бд..

[napa3um]

Виталий: да, скорее всего.

Answer 1

[Дмитрий Беляев]

Курсор у любой БД будет медленнее получения всех данных одним пакетом, банальные издержки на транспортный слой, сравните внутренние механизмы:
1. БД, вот тебе запрос, дай мне все данные которые ему удовлетворяют.
2. БД, вот тебе запрос, запомни его, я позже буду спрашивать по нему данные. БД, дай мне данных по тому запросу. БД, дай мне еще данных по тому запросу. БД, дай мне еще...

2й вариант - как раз таки курсор

Comments

[Виталий]

Дмитрий, вы как бы в теме той бд, о которой я спрашиваю? Там в принципе после запроса всей бд возвращается курсор.... t.table('table').run(...).then(cursor=>{...})

[Дмитрий Беляев]

Виталий: да, в теме, за последний год у меня гдето 70% проектов бегают на рефинке, некоторые из них раньше были на монге и благодаря переходу на рефинк удалось увеличить отклик

[Виталий]

Дмитрий Беляев: тогда есть смысл обсудить сабж. я думаю, что ретфинк больше нацелен на стримы и событийность, чем на обработку бигдата (хотя рука не сильно подымается называть 600к бигдатой), по этому моя затея вынимать массивы данных видимо мало хорошая затея, не для того базу создавали. Если по конкретике, есть ли какой другой вариант запроса , я пробовал получить данные на курсор через r.table и r.table.getAll('filtername', {index: 'indexname'}) в обоих случаях отдает через курсор долго, как получить данные сразу массивом я не понимаю, на сколько я вижу, оно всегда селекты отдает как курсор, а далее селект.тоаррей до 100к документов, или через некст, получай свой массив сам. Короче если есть идеи , я был бы признателен услышать. Думаю еще попробовать eachAsinc или как там оно пишется, но в моейм воображении этот процесс просто завалится по нехватке скорости диска....

[Дмитрий Беляев]

Виталий: Документарки как правильно не преднозначены для большого количества документов в одной коллекции, но до 1 млн документов как правило работают стабильно
У Вас запрос без сложных агрегаций, просто фильтр, должен хорошо кэшироваться в памяти, поэтому имеет смысл дергать по 1-2к документов через skip и offset

[Виталий]

Дмитрий Беляев: да в том то и дело, 600к доков, таблица весит около 2 гб, до финального ее состояния в нее много записывалось и удалялось, но думаю ускориться не смогу в этой ситуации никак.

[Виталий]

Дмитрий Беляев: проверю скип сегодня