import { Angulartics2 } from 'angulartics2') - в компоненте ang2.virtualPageviews(false). Далее подписываешь на изменение урла (_router.events.subscribe(e=>...)) и после окончания навигации (if (e instanceof NavigationEnd){...}) трэкаешь событиe.this._gtm.eventTrack('event', {
event: 'ngPageView',
value: {
url: this.location.path(false)
}
})setUsername(userId) аналитика сама будет это учитывать при агрегации. Можно конечно на конфигах все разрулить как в доке сказано (там всякие шаблоны прописать, регэкспы), но на мой взгляд в коде удобнее и более гибко.
1. Плюсовик есть, он собственно и генерирует этот файл с талонами, их значения не рандомны, их порядок рандомный (поэтому мы можем идти для каждого вида с начала или конца очереди и записывать очередной индекс). Масштабировать этот файл не нужно или нужно будет достаточно редко (раз в несколько месяцев), поскольку именно этот файл как-то там сертифицируется после генерации. Далее этот файл после сертификации передается на сервер (с флешки/жестким диском - не важно), важно сократить время подготовки к работе с ним. То есть 2 варианта: работать с файлом напрямую или перелопатить 40 ярдов в БД (что по времени там тоже очень долго).
2. Хорошее железо - понятие размытое. Процы, память обеспечим. Как быть с винтами которые придется чуть ли не каждую неделю (по 240-480 Гб) доподключать?(амазоном заказчик не хочется пользоваться) До 10 машин администрировать еще можно, но больше уже становится адово. Сейчас взяли на хеснере 9 виртуалок не очень мощных чтобы посмотреть как будет кухня себя вести под нагрузкой. Железки проблемны администрированием - нужно делать свою СХД.
Команда у нас очень маленькая 3 человека: с++, го, js/nodejs. Есть опыт работы со свармом в бою. Но настройка того же кластера монги/кассандры (с кошем пока не понятно как персистентно хранить, Flocker?) может вызвать проблемы с пониманием системы с случае отказа одной из нод.
Рассматриваем вариант написать свои воркеры с embedded boltdb/tiedot на го. Но тут не уложимся в сроки для реализации репликации.