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

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

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

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - process out of memory

и мой сервер Deepstream отключился. Я смог исправить это, добавив больше памяти в процесс узла сервера с этим флагом.

--max-old-space-size=5120

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

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

RangeError: Maximum call stack size exceeded

Я смог исправить это с другим флагом:

--stack-size=20000

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


deepstream.io
person Vasiliy Sadokhin    schedule 19.03.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

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

Сказав это, есть две открытые проблемы Github для повышения производительности очень длинных списков за счет отправки более эффективной дельты и введение опции разбиения на страницы

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

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 );
person wolframhempel    schedule 19.03.2016
comment
Мой случай заключается в том, что я не могу выполнять массовое обновление, так как, например, пользователь будет регистрироваться один за другим, поэтому я буду получать новый адрес электронной почты в списке для каждой регистрации. Давайте остановимся на примере уникальной электронной почты, так как это очевидно, но учтите, что у нас есть другие записи с уникальными значениями, о которых мне нужно позаботиться, чтобы у нас не было дубликатов. Интересно, не является ли список правильным архитектурным решением для обработки этой бизнес-логики. На ум приходят два других решения: deepstream.io-provider-search-rethinkdb и просмотр rethinkdb напрямую для поиска по фильтру или вторичному индексу. Любые другие идеи? - person Vasiliy Sadokhin; 20.03.2016
comment
Имена пользователей и адреса электронной почты неизменны — они на самом деле не меняются. Я думаю, что было бы разумно хранить их в БД, используя традиционный подход, основанный на запросе/ответе, через RPC. Задача deepstream.io (и любой другой среды реального времени в этом отношении) состоит в том, чтобы эффективно использовать данные в реальном времени. Это означает идентификацию данных, которые а) отображаются в текущем представлении б) подвержены (достаточно частым) изменениям, что для имен пользователей может не обязательно иметь место. Вот почему Deepstream предлагает сочетание RPC, событий и записей. - person wolframhempel; 21.03.2016
comment
Да, спасибо за ответ. Я согласен с тем, что имя пользователя и другие поля, которые у меня будут уникальными, не будут часто меняться, поэтому я придерживаюсь прямого поиска в базе данных. - person Vasiliy Sadokhin; 22.03.2016