@AMar4enko Ну это можно тоже. Я пока остановился на следующей схеме.
Так как ts в результирующей таблице у меня округляется до даты (без времени) то я просто запускаю процесс мап-редьюса с такими параметрами:
var map = function(){...}
var reduce = function(k,v){...}
out = {merge:"result_collection"}
var d = new ISODate()
d.setHours(0)
d.setMinutes(0)
d.setSeconds(0)
d.setMilliseconds(0)
db.source_collection.find({ts:{$gt:d}})
по крону все это выполняется раз в 10 минут и по сути в процесс м/р попадает только сегодняшний день. А флаг merge перезаписывает в результирующей таблицы данные с одинаковыми ключами.
Вроде как работает и работает быстро.
@Kerman Таки я не админ - вот в чем проблема. Я разработчик и для меня это выглядит костылем, так как запускается еще 2-3 внешних не зависимых от меня шага :)
@Ernillew@Kerman А по поводу FreeBSD - у нас она уже лет так 11 стоит в качестве DNS и кушать не просит. Но из за особенностей разработки - продашкены ессно на Ubuntu LTS (разномастные версии правда - но за это спасибо Hetzner)
@Hellpain Да ладно вам. Есть и другие варианты. Хуже но есть.
Было бы страничек 20 - поправили бы. А когда их переваливает за 1000 файлов - ну его. Будет ждать большого рефакторинга.
@Vintorez Про collectstatic я естественно в курсе. Но ее в нашем случае не применить. Проект создавался еще во времена django 0.x и все пути, все ссылки и прочее остались еще в том времени. Переход на нормальные collectstatic - дело хоть и нужное но очень хлопотное.
Ну как бы тоже есть мысля создать шаблонный тег который сам получит TS изменения файла и создаст путь на его основе. Изменений только много будет. Но вариант рабочий.
@TekVanDo Не, ну есть же теоретическое программирование :) Знавал я такие собеседования - специальность Python/PyQt программист UI - задавали вопросы по графам, теории программирования и прочему бреду который я уже давно и благополучно забыл. Не одного вопроса по питону или qt не было :)
@iskros Да этого всего дохрена, я писал свой так как было лень искать готовый. Да и реализуется все досточно просто. Единственное, что я бы рекомендовал - делать "обрезание" всеакие на сервере, а не отправлять уже обрезанную картинку. Как по мне - клиент потыкал, потаскал изображени, на сервер ушла изначально загруженная картинка и координаты все нужные (обычно bbox нужного участка). А обрезание уже на стороне сервера тем же GD(если богомерзкий PHP) или PIL или на худой конец ImageMagic. Так надежней будет.
Товарищ @virpool выше все верно сказал, forever по сути простой супервизор, он не зависит от работы самой аппликухи, содержит "пул" запущенных программ и имеет команды для работы с группами.
@portfelio Вот еще что вспомнилось.
У нас индекс товаров в проекте более 10М записей. Понятно что каждый день были новые и измененные записи. Вся эта балалайка была реализована как: основной индекс который делался на какой-то момент врмени, все что было дополнительное загонялось в дельта индексы. По каким то причинам данные из дельты могли становиться временно недоступными. Чтобы это компенсировать раз в неделю по крону запускался основной реиндекс товаров, который занимал, насколько я помню, от 6 до 12 часов, при этом создавал нехилый оверхед на сервере. Городили master-slave реплику БД чтобы можно было с одной работать продакшен серверу, второй чисто для индексации. Понятно что все это не проблемы SPH, а проблемы реализации. Но с ES как то проще, дружелюбнее он. А sph у меня все еще вызывает ассоцииации с совецким секретным танком.
@portfelio Ну самое сильное воспоминание было от жуткой низкоуровневости sph, отсутствие нормального клиента для питона и отвратительной, на тот момент, документации. Но повторяюсь - это абсолютно не обективно, так как нам пришлось работать с тем что нам дали. Во втором проекте уже осознанно сделали выбор в сторону ES. Вот еще был батхерт когда увидили скорость работы xmlpipe2 протокола.
