Meteor, mongodb - оптимизация столовой

Question

TL; Я делаю приложение для столовой. У меня есть коллекция с людьми и коллекцией, где я «регистрирую» каждое мясо. Мне нужно знать тех, кто НЕ принимал еду.

Длинная версия:

Я делаю приложение для моего местного отделения Красного Креста.

Я пытаюсь оптимизировать эту ситуацию:

• есть столовая на Wich то помогли люди могут принимать пищу на завтрак, обед и ужин. Нам нужно знать, сколько из них приняло еду (и это легко).

• Если они присутствуют, им нужно принять еду и поесть, поэтому нам нужно знать, сколько (и кто) НЕ ЕЩЕ (это та часть, которую мне нужно оптимизировать).

• Когда они берут еду, «кассир» вставляет свой штрих-код, программа регистрирует «транзакцию» в коллекции журнала.

На самом деле, на создание шаблона «столовке» создать местную коллекцию «обедов» и заполнить его с данными всех людей в БД, (так ID, имя, пост/сытым), затем я использую эту коллекцию для своих прилавков и показываю, кто взял еду, а кто нет. (переменный «mealKind» является = «завтраком» ИЛИ «обед» или «обед» в зависимости от фактической сервировки.)

Template.canteen.created = function(){ 
    Meals=new Mongo.Collection(null); 
    var today= new Date();today.setHours(0,0,1); 
    var pers=Persons.find({"status":"present"},{fields:{"Name":1,"Surname":1,"barcode":1}}).fetch(); 
    pers.forEach(function(uno){ 
    var vediamo=Log.findOne({"dest":uno.codice,"what":mealKind, "when":{"$gte": today}}); 
    if(typeof vediamo=="object"){ 
     uno['eat']="satiated"; 
    }else{ 
     uno['eat']="fasting"; 
    } 
    Meals.insert(uno); 
    }); 
}; 

Template.canteen.destroyed = function(){ 
    meals.remove({}); 
}; 

Из коллекции еды я estrapolate два colums людей сытых (с именем, фамилия и штрих-код) и пост, и я также использую два помощника:

fasting:function(){ 
    return Meals.find({"eat":"fasting"}); 
    } 
    "countFasting":function(){ 
    return Meals.find({"eat":"fasting"}).count(); 
    } 
//same for satiated 

Это было хорошо, но сейчас количество людей действительно растет (мы arount 1000 и подсчета голосов), а также создание страницы очень очень медленно, и обычно он останавливается с ошибками, поэтому я могу прочитать, что «100 голода, 400 сыты», но у меня около 1000 человек в БД.

Я не могу понять, как оптимизировать рабочий процесс, каждый другой метод, который я пытался вовлечь (тем или иным способом) больше запросов к БД; Я думаю, что я пропустил этот момент, и теперь я не вижу его. Я не уверен в агрегации на этом уровне и внутри метеор из-за minimongo.

Несмотря на то, что эта сторона сервера, а не клиентская, умна, проблема здесь заключается в том, что «голодание» отличается от «насыщенного» без использования всей коллекции людей.

+1, если раствор совместим с aleed: табличной

Answer 1

EDIT

Я до сих пор не уверен, что является причиной вашей проблемы производительности (слишком много вещей, в клиентской памяти/minimongo, слишком много звонков?), но вы могли бы по крайней мере попробовать разные подходы, более традиционно основанные на вашем сервере.

Кстати, вы не упомянули ни о том, как вы отображаете свои данные, так и о том, как вы получаете неправильное чтение для вашего количества уже поданных/отсутствующих Persons?

Если вы строите классический HTML table, обратите внимание на то, что браузеру удается выделить более нескольких сотен строк. Если вы в этом случае, вы можете реализовать постраничную разбивку страниц/бесконечную прокрутку. Посмотрите, например, на jQuery DataTables плагин (на котором находится aldeed:tabular). Пропустите шаг создания фактического HTML table и заполните его напрямую, используя $table.rows.add(myArrayOfData).draw(), чтобы избежать ограничения браузера.

---

Оригинальный ответ

Я не совсем понимаю, почему вы должны дублировать Persons коллекцию в стороне клиента Meals местного сбора?

Это требует, чтобы у вас есть первые всех документов Persons посланных от сервера к клиенту (это может быть проблематичным, если ваш сервер хорошо подключен/локальным. Вы также можете еще autopublish пакет на, так что вы бы уже видел это наказание), а затем клонирование всех документов (проверка вашей коллекции Logs для извлечения любых предыдущих отрывков), что вдвое увеличивает потребность в вашей памяти.

Является ли ваш сервер и/или удаленная БД медленными, чтобы оправдать вашу потребность делать все локально (на стороне клиента)?

Может быть гораздо более проблематичным, если у вас открыто более одного «кассира»/клиентского браузера, локальные коллекции Meals не будут синхронизированы.

Если соединение с сервером и клиентом хорошее, нет причин делать все клиентскую сторону. Meteor автоматически кэширует только то, что необходимо, и обеспечивает оптимистичную модификацию БД, чтобы ваш пользователь быстро работал (если вы правильно структурируете свой код).

• С aldeed:tabular пакета, вы можете легко отображать Persons большую таблицу «страниц».
• Вы также можете связать его с вашей коллекцией Logs, используя dburles:collection-helpers (IIRC есть пример в домашней странице aldeed:tabular).