Спасибо за коммент. Если я не ошибаюсь, neo4j это база данных для хранения и оперирования графами и пр. сетевыми структурами. Но в принципе, мне достаточно получить бинарный поток по id и десериалезировать его в объект графа уже в скрипте. А потом уже работать с ним используя NetworkX. Поэтому похоже в моём случае neo4j не подходит
Вот наконец-то кто-то сподобился ответить. Спасибо за Ваше мнение, я ведь и спрашивал мнение знающих людей, кто работал с этим.
Значит пока отложу эту идею. Вроде новая спецификация Bluetooth как-раз заточена под энергоэффективность. Посмотрим до чего техника дойдёт
Ну у нас всё же не совсем просто статика отдаётся. Т.е. в принципе статика, но она ещё и считаться и управляться должна. Более комплексная система, чем просто раздача всё же. Хотя единственный путь приблизить как только можно к виду просто раздачи.
И спасибо за инфу, 100 миллионов в сутки, это обнадёживает!
Спасибо большое за столь обстоятельный ответ!!!
Как раз мне не хватало мнения человека в этом разбирающегося. Спасибо хабру и Вам equand.
Теперь я определился, будем делать только один дополнительный сервер для раздачи всей этой статики, это и проще реализовать и задела хватит на 100 раз большие нагрузки чем планируется сейчас. Хотя при проектировке всё же постараемся вложить возможность как можно более простого масштабирования путём добавления сервера.
ОК. Значит я так понял, Вы рекомендуете не заморачиваться такими разветвлёнными схемами, поставить один дополнительный сервер на FreeBSD + хорошее железо и он без проблем выдержит как текущие 2.5 миллионов в неделю, так и потенциальные 25 в неделю в будущем?
Это конечно многое упрощает и мне очень-бы хотелось, чтобы так всё и было!
Только так, я ведь и написал, что планируется накапливать их в мемкеше. Видимо не достаточно чётко выразил мыль. По крону, раз в минуту скажем или другой интервал, статистика запросов на каждом SS из мемкеша будет синхронизироваться с его базой и базой на CM, причём собственная база на SS возможно и не нужна, это ещё надо продумать.
Да, я знаю, что Nginx такой трафик статики перемолотит даже на основном сервере, но это только первый партнёр и не известно сколько их таких будет в будущем и хочется сразу заложить удобство масштабирования.
А насчёт хитов, в принципе ведь не важно сколько народу к нам прийдёт, как я написал выше, есть требования, чтобы всё считать и всем управлять, т.е. каждый раз баннер будет видимо с уникальным URL и не кеширующимся
А операционка к стати у нас CentOS
Ну есть чёткие требования:
1) Партнёры хотят добавлять в свою страницу только пару строк кода и никаких файлов себе заливать не хотят.
2) На нашей стороне нужно контролировать количество показов, из панели управления включать/выключать, смотреть статистику т.е. как раз и придётся каждую открутку в базу писать, хоть и накапливая их в мемкеше, менять вероятности показа для каждого банера в пакете.
Ниже equand указал, что 2.5 лямов запросов статики вообще не серьёзная нагрузка на дедик, сейчас с ним пообщаюь подробнее.
Ну вот не получается им отдать эту статику, я бы с удовольствием!
А насчёт методики подсчёта посетителей, я не знаю конкретно, для меня это входные данные больше
Если из РНР передаём параметры массивы сервису реализованному на .NET, то может пригодится ещё такой параметр:
'features' => SOAP_USE_XSI_ARRAY_TYPE
Иначе он РНР`шный массив не распознаёт