Можно использовать в таком примере, как пользователь логинится в приложение (command) и ответ на запрос "сколько активных пользователей" (query). Список команд можно логировать в эвент лог и использовать как источник правды, а вот query можно легко кэшировать.
Ситуация нескольких минут как раз хорошо выражается через пины.
вы как минимум можете спрогнозировать, сколько в этой области окажется машин (как с плюсом, так и с минусом)
В статье не отражено, но в зоне также учитываются занятые водители, просто с некоторым понижающим коэффициентом. Это дает достаточно хороший прогноз.
Также мы работаем над механизмом рекомендаций перемещения водителей не на заказе и там все не так просто — стратегия «ехать в зону максимального спроса» не всегда является оптимальной. Возможно об этом тоже расскажем.
выявлять ситуации, когда повышенные значения сурджа носят характер «всплеска»
Всплески мы сглаживаем ближайшими соседями.
В целом, ваша идея хорошая и поможет еще сильнее повысить точность, но не факт, что это действительно киллер-фича — сурдж обычно достаточно стихийный и возникает в зонах, из которых люди хотят выехать и не очень важно, где они окажутся после завершения заказа, в большинстве кейсов сурджа там уже не будет.
Прогнозировать наперед мы немного учимся с помощью машинного обучения.
Плюс ко всему, в зонах, в которых спрос на регулярной основе превышает предложение мы гарантируем водителям повышенные коэффициенты через механизм геосубсидий.
Сурдж достаточно важный, но не единственный механизм распределения водителей.
1) водителей в системе слишком много, нужен безумных размеров чат водителей, находящихся в одном районе
2) реакция суржа на свободные машины моментальная, поэтому те водители, которые уйдут с линии заказ с суржом не получат, а получат те, кто остался. это прекрасная теоретико-игровая проблема, требующая дополнительной синхронизации от водителей.
в общем даже мы внутри, зная как в точности оно работает, не сможем манипулировать суржом сильно.
Есть ряд правил:
1) Мы не синхронизируем временные файлы офиса, информация об этом есть в статье
2) Мы начинаем синхронизацию через 4 секунды после изменения
Мы прямо сейчас работаем в направлении ускорения индексации.
Можете написать мне на почту a.skogorev@corp.mail.ru, посмотрим, чем вызвана конкретно ваша проблема.
Что значит «ломается синхронизация»? Могли вы написать мне на почту a.skogorev@corp.mail.ru дату проблемы, название проблемного файла, попробуем разобраться с вашей ситуацией.
Сейчас в разработке на находится инструмент, который позволит синхронизировать любые символы и названия. Неразрешенные для платформы символы будут экранироваться.
Все зависит от того, реально ли вам нужно преобразование в кодировку, отличную от UTF-16. Я бы советовал работать именно с ней и оставить данное название «как есть». В другом случае, опишите ваш кейс более подробно, подумаем все вместе =)
Если в дереве появится какой-то номер inode, совпадающий с уже существующим, то пытаться обработать перемещение для этих файлов или папок мы не будем.
Также при обнаружения inode в другом месте проверяется контрольная сумма объекта (или какой-то процент соответствия вложенного контента, если это папка), которая отметает возможность ложного срабатывания.
👍
Можно использовать в таком примере, как пользователь логинится в приложение (command) и ответ на запрос "сколько активных пользователей" (query). Список команд можно логировать в эвент лог и использовать как источник правды, а вот query можно легко кэшировать.
Писал подробнее тут: https://t.me/startup_architecture/11
Постараюсь ответить.
Ситуация нескольких минут как раз хорошо выражается через пины.
В статье не отражено, но в зоне также учитываются занятые водители, просто с некоторым понижающим коэффициентом. Это дает достаточно хороший прогноз.
Также мы работаем над механизмом рекомендаций перемещения водителей не на заказе и там все не так просто — стратегия «ехать в зону максимального спроса» не всегда является оптимальной. Возможно об этом тоже расскажем.
Всплески мы сглаживаем ближайшими соседями.
В целом, ваша идея хорошая и поможет еще сильнее повысить точность, но не факт, что это действительно киллер-фича — сурдж обычно достаточно стихийный и возникает в зонах, из которых люди хотят выехать и не очень важно, где они окажутся после завершения заказа, в большинстве кейсов сурджа там уже не будет.
Прогнозировать наперед мы немного учимся с помощью машинного обучения.
Плюс ко всему, в зонах, в которых спрос на регулярной основе превышает предложение мы гарантируем водителям повышенные коэффициенты через механизм геосубсидий.
Сурдж достаточно важный, но не единственный механизм распределения водителей.
2) реакция суржа на свободные машины моментальная, поэтому те водители, которые уйдут с линии заказ с суржом не получат, а получат те, кто остался. это прекрасная теоретико-игровая проблема, требующая дополнительной синхронизации от водителей.
в общем даже мы внутри, зная как в точности оно работает, не сможем манипулировать суржом сильно.
1) Мы не синхронизируем временные файлы офиса, информация об этом есть в статье
2) Мы начинаем синхронизацию через 4 секунды после изменения
Таким образом, файл будет изменен правильно.
Можете написать мне на почту a.skogorev@corp.mail.ru, посмотрим, чем вызвана конкретно ваша проблема.
Мы учимся работать с тем, что есть.
Также при обнаружения inode в другом месте проверяется контрольная сумма объекта (или какой-то процент соответствия вложенного контента, если это папка), которая отметает возможность ложного срабатывания.
Откуда такой вывод?