Использование списка глубокого потока для десятков тысяч уникальных значений

Question

Интересно, использовать хорошую/плохую идею для использования deepstream record.getList для хранения множества уникальных значений, например, электронных писем или любых других уникальных идентификаторов. Основная цель заключается в том, чтобы иметь возможность быстро ответить на вопрос, есть ли у нас, скажем, пользователь с таким электронным письмом (используемым электронной почтой) или другой записью по определенному уникальному полю.

Я сделал несколько экспериментов сегодня и получил две проблемы: 1), когда я попытался заполнить список с несколько тысяч значений я получил

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory 

и мой deepstream сервер ушел. Я был в состоянии исправить это, добавив больше памяти процесса узла сервера с этим флагом

--max-old-space-size=5120 

это не выглядит хорошо, но позволило мне составить список с более чем 5000 наименований.

2) Это не было достаточно для моих тестов, так что я precreated список с 50000 пунктов и поместить данные непосредственно в таблицу rethinkdb и получил еще один вопрос о получении списка или модификации его:

RangeError: Maximum call stack size exceeded 

I был в состоянии исправить это с другим флагом:

--stack-size=20000 

это помогает, но я считаю, что это только вопрос времени, когда одна из этих ошибок появляются в производстве, когда размер списка достигает должное значение. Я не знаю, действительно ли это проблема nodejs, javascript, deepstream или rethinkdb. Все это в целом заставило меня подумать, что я пытаюсь использовать неверный путь в списке. Пожалуйста, дайте мне знать. Заранее спасибо!

Answer 1

Хотя вы можете использовать списки для хранения массивов строк, они на самом деле предназначены как коллекции записей - фактические данные будут храниться в самой записи, список будет управлять только порядком записей.

Сказав, что есть два открытые вопросы GitHub для повышения производительности для очень длинных списков по sending more efficient deltas и по introducing a pagination option

Интересных результатов в отношении памяти, хотя, безусловно, то, что должно быть обработано более изящно. В то же время вы могли бы значительно повысить производительность за счет объединения обновлений в одно:

var myList = ds.record.getList('super-long-list'); 

// Sends 10.000 messages 
for(var i = 0; i < 10000; i++) { 
    myList.addEntry('something-' + i); 
} 

// Sends 1 message 
var entries = []; 
for(var i = 0; i < 10000; i++) { 
    entries.push('something-' + i); 
} 

myList.setEntries(entries);