MongoDB: слишком много полей для индексации? Используйте общий индекс

Отлично! Решил после этого поста обновить mongodb и переписать поиск по таблице с пользователями

Использование ActiveRecord от Yii в игре тайм менеджере

ага, спасибо за информацию

Использование ActiveRecord от Yii в игре тайм менеджере

Ага, в самом деле
Сделал так. В ExtActiveRecord добавил

/**
* Избавляет от model() в моделях
* return CActiveRecord
*/
public static function model() {
return parent::model(get_called_class());
}

и убрал в моделях (кроме базовых) метод model.

Такой вариант предлагали?

Использование ActiveRecord от Yii в игре тайм менеджере

ага, интересно. Спасибо за наводку

Использование ActiveRecord от Yii в игре тайм менеджере

Я приводил примеры кода из текущего проекта. Пришлось часть убрать, которая не нужна. Ошибка с $dict->area_id все таки прошла :)

По первому пункту — вызывается в registry, так как у нас уже реализована работа с кэшем, а после получения данных из кэша не происходит afterFind

Использование ActiveRecord от Yii в игре тайм менеджере

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

Использование ActiveRecord от Yii в игре тайм менеджере

Так же save от CAvtiveRecord выполняет валидации, которые нам не нужны

Использование ActiveRecord от Yii в игре тайм менеджере

Потому что beforeSave вызывается внутри методов update и insert у CActiveRecord, а у нас в переодпределенном save вызывается update метод, при этом указывается, какие поля изменились

Использование ActiveRecord от Yii в игре тайм менеджере

чтобы потреблять больше памяти

Использование ActiveRecord от Yii в игре тайм менеджере

Из очереди достается пачка с командами. Это массив. Вот как все они были выполнены — обработка завершена.
Про очередь писал в прошлом посте — habrahabr.ru/post/176497/
Там правда немного изменился уже принцип работы, но суть та же.

Использование ActiveRecord от Yii в игре тайм менеджере

Смотри. Три команды, которые как-то изменяют поля пользователя
Обработчик запускает команды поочередно. Команды через реестр получают модель пользователя и изменяют поля.
Сохранение происходит в обработчике после обработки всех команд. При этом сохраняются все модели, которые были получены командами.

Использование ActiveRecord от Yii в игре тайм менеджере

Ага, спасибо за наводку.

Использование ActiveRecord от Yii в игре тайм менеджере

Да, в самом деле :) Исправлюсь :)

Отложенная обработка команд в социальной игре

ага, ничего такого не используем

Отложенная обработка команд в социальной игре

1) частота отправки будет опытным путем подбираться. К примеру 10 команд накопилось — скинули. Или раз в 5 минут.
2) Такое возможно. Уходим от такого с помощью тестов, которые покрывают логику приложения и снижают риск возникновения такой ситуации.
3) В бд логики никакой нет. Каких-либо связей между таблицами в самом бд не реализовано. Все довольно просто там.
А что за ХП?

Отложенная обработка команд в социальной игре

Связка генерируется в момент создания user_id и сохраняется в таблицу, которая не шардируется. Потом из нее узнаем где лежит пользователь. Так что все ок :)

Отложенная обработка команд в социальной игре

А, что-то я бред написал. Да, ваш вариант интересный. Возможно изменим логику. Спасибо :)

Отложенная обработка команд в социальной игре

Потому что количество серверов может увеличиваться :)

Отложенная обработка команд в социальной игре

Согласен, что вариантов решения много. Я привел тот, который был выбран в связи с тем, что мы знаем как его реализовать качественно и в нужные сроки.

Отложенная обработка команд в социальной игре

Тоже шардинг. Принцип тот же. Я получаю данные из кэша стандартными методами проекта, а внутри все разруливается и определяется с какого сервера тянуть.