rPman

Главное чтобы вы юридически находились в стране где деятельность - законна, а дальше достаточно исполнять соответствующие предписания для этой страны.

Для других стран - серая зона, вы не обязаны определять и доказывать что ваш клиент нарушает свои собственные законы (например в китае смотреть порно запрещено, какой там публиковать).

Все что вам потребуется часто а меняться будет редко/никогда - пишите в базу заранее! не нужно нагружать ее такими глупостями.

Т.е. заведите таблицу или поля соответствующие, и тригером обновляйте поля при редактировании базы.

Есть большой шанс что HTTP канал с сервером не закрывается, это дает заметный бонус на последующие запросы.
Попробуйте делать запросы к разным серверам. А для бенчмарков лучше поднимать свой http сервер.

У вас проблема не с большими числами, bigint их решит, а большой объем данных, миллионы и миллиарды записей положат вашу базу и создадут охренительные проблемы в будущем
Поэтому сразу закладывайте партиционирование таблиц по интервалам времени, причем не обязательно средствами базы данных, достаточно самим создавать новую таблицу для каждого следующего временного интервала (недели, месяцы - зависит от вашей нагрузки).

почему вы хотите хранить простые линейные логи в БД?
что еще вам нужно делать с данными кроме фильтрации и суммы?

если всетаки храните в базе, то не создавайте индексов на такие поля как объем трафика и url, это наиглупейшая ошибка, во время записи в таблицу заранее считайте необходимые параметры, выделяйте важные данные из url, вычисляйте домен, ip (сегодня он один, завтра другой), собирайте суммы по трафику в отдельной табличке, если нагрузка позволяет, можете по ip считать (или по зонам), в итоге вы будете работать не с сырыми данными, а уже агрегированными и посчитанными, их на порядок меньше и они удобнее для использования.

Что бы вы не делали, в конечном счете вору будет достаточно делать запись с экрана, в котором запущен браузер с вашим видео.

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

На текущий момент вашу задачу пытаются решить DRM технологии, и они очень плохо дружат с веб (обычно вынуждают пользователя ставить приложения и плагины, и пользователям это не нравится), обычно решения гуляют вокруг нестандартных кодеков и приложений, контролирующих проигрывание видео и копирование данных (зачатки есть даже в аппаратных, том же hdmi, правда его взломали уже давно).

Моя практика показывает что в конце концов пользователям нужны обе возможности, как повторная генерация отчета (на основе текущих данных, которые пользователь изменил, даже если это изменения 'задним числом', поверьте, в конце концов вам придется такое делать, если это корпоративное приложение), так и загрузка ранее сгенерированного отчета, потому что у пользователя на компе бардак и он не знает куда его сохранил а нужно еще вчера распечатать...

Поэтому, храните документ на сервере, настоятельно рекомендую хранить в файлах, настоятельно рекомендую имена файлов делать на основе идентификаторов, и раскидывать по подкаталогам (100500 файлов в одном каталоге = плохо), а настоящее имя файла подставлять пользователю во время загрузки (иначе пробелы и нестандартные unicode символы вас и вашего администратора доканают).

Дайте пользователю возможность сгенирировать новый документ и посмотреть список предыдущих сгенерированных, а администратору возможность удалить документ, в идеале полуавтоматические инструменты по пакетному удалению (например по окончанию отчетного периода чистить все сохранения за этот период кроме последнего), но помните про бакапы.

namecheap.com, бесплатно только первый год (например домен + private + ssl <10$ на первый год)

Если обсуждать 'сферического коня' то выбор между 'notepad' и 'полнофункциональный IDE с отладчиком' диктуется не только выбранными библиотеками и фреймворками, но и банальной трудоемкостью развертывания и первоначальной настройки.

Отличный пример - попробуйте настроить с ходу на windows машине какой-нибудь php-IDE с работающей отладкой, вы меня поймете.

Например, долгое время, разработку серверной части php-сервисов (не только веб кстати) проходил в windows в FAR+несколько плагинов, без отладчика, зато без каких либо требований к рабочей машине, каких-то настроек и установки приложений, а на linux мне хватало vim.

В тему обсуждения, тогда непонятно, как существуют продажи мобильных устройств, ведь в каждом устройстве есть бинарные блобы, и если бы только в драйверах, так каждый наровит в системные утилиты воткнуть от утилиты открывающей страничку в интернете (приложение висит в памяти на 20мб) и до крутой поддержки инфраструктуры google, в случае с которым язык не повернется о том, что первично в устройстве.

Если оригинальный скрипт не сохранил идентификатор таймера, возвращаемого при иннициализации, то никак. Официального способа перечислить запущенные таймеры нет, кроме как переопределить setInterval ДО вызова на свою функцию.

Если повезет, можно найти в вызываемом скрипте условие, при котором он завершится с ошибкой или будет работать вхолостую (удалить используемый DOM объект например).

Кажется вам лучше выбрать что-нибудь поддерживающее IMAP и воспользоваться какой-нибудь хорошей библиотекой на клиенте (или, если нужно, изобретите прослойку в виде сервера, тупо транслирующую вызовы по сети)

Поделись в личку ссылку на сервис, пожалуйста.

Подумайте все таки по выбору города не только по названию.
Пример для размышлений:
maps.yandex.ru

Россия, Москва
Польша, Восточно-Лодзинский повят, Новосольна, Москва

Вы сами, с каждым новым примером расширяли саму задачу: +увеличить скорость, +увеличить надежность, +найти место и причину проблемы и возможность получить состояние на любой момент времени,…
Что значит другие модели? какие еще задачи нужно решить?

p.s. последний приведенный вариант вполне хорош, но накладывает ограничение — данные должны быть последовательны (для получения следующей записи нужна самая последняя запись), что может некрасиво ложиться на горизонтальное масштабирование, когда коллекция размазывается по нескольким физическим нодам (но эта проблема вполне решается, либо глобальными локами на объект — в данном случае 'счет', либо введением дополнительными коллекциями типа — данные о последнем изменении, если честно это та же реализация глобального лока, но уже через эту коллекцию...)
Т.е. ваша задача будет расширяться и дополняться, боюсь как бы не до бесконечности по мере появления новых проблем, порождаемых очередным решением предыдущей… рекомендую где то остановиться сразу.

Хочу дать совет, не то чтобы я активно пользовался, но когда всплывает хоть малейшая необходимость в каком-либо функционале, всплывает понимание как надо делать и как не надо.

Сделайте основу и модульное расширение функционала, где модули раздаваться должны тут же в неком подобии интернет-магазина. Не пытайтесь сделать супер монстра по функционалу.

При необходимости — серверную часть делать на какой либо SAAS платформе, например google app engine (хотя в вашем случае там так мало кода что нет разницы на чем делать… php/asp/..)

Клиентскую часть можно сделать на ru.wikipedia.org/wiki/Twitter_bootstrap

Просто авторизация и информация по аккаунту решается уже существующими технологиями (OpenID на персональном сервере, хоть на том же google app engine позволит пользователю не заботиться о повторном вводе данных а серверу не заморачиваться)

Миру нужна гарантированная (ну это идеальный вариант) система уникальной идентификации пользователей с одновременным с этим обеспечением анонимности. Для обеспечения сбора достоверной статистической информации, в т.ч. голосования, например. При этом, обладая информацией о человеке никакой проект не должен иметь возможности сопоставить его идентификатор с информацией на любом другом (это могло бы быть достигнуто централизованной выдачей идентификаторов и хранением их в секретной базе — что кстати проблема мирового масштаба). Мало того, технически возможно защитить информацию в проектах от владельцев основной центральной базы (выдаваемые центром идентификаторы пользователей должны дополнительно модифицироваться самим проектом)

Регистрацию в такой системе пользователей придется проводить оффлайн с постоянной проверкой (смерти, смены паспорта, ФИО, пола,… или экзотики вида — смена личности для сокрытия людей по программам защиты свидетелей в США).

Так же авторизация в такой системе могла бы быть более надежной чем привычные пароли и даже SMS, например симбиоз их с биометрическими системами (отпечатки пальцев или задницы, распознавание лиц, голоса, стиль использования клавиатуры, мыши и т.п. и даже психопрофиля).

Конечно, помимо информационной составляющей существует проблема управления одним пользователем несколькими аккаунтами, но не такая страшная как сейчас боты рулят тысячами и миллионами, так как регистрация значительно осложнена.

Если попытаться разработать такую систему децентрализованной, с защитой всей базы от доступа (интуиция подсказывает что это скорее всего возможно), то это будет бомба по круче bitcoin с ее proof of work.

Просто авторизация и информация по аккаунту решается уже существующими технологиями (OpenID на персональном сервере, хоть на том же google app engine позволит пользователю не заботиться о повторном вводе данных а серверу не заморачиваться)

Миру нужна гарантированная (ну это идеальный вариант) система уникальной идентификации пользователей с одновременным с этим обеспечением анонимности. Для обеспечения сбора достоверной статистической информации, в т.ч. голосования, например. При этом, обладая информацией о человеке никакой проект не должен иметь возможности сопоставить его идентификатор с информацией на любом другом (это могло бы быть достигнуто централизованной выдачей идентификаторов и хранением их в секретной базе — что кстати проблема мирового масштаба). Мало того, технически возможно защитить информацию в проектах от владельцев основной центральной базы (выдаваемые центром идентификаторы пользователей должны дополнительно модифицироваться самим проектом)

Регистрацию в такой системе пользователей придется проводить оффлайн с постоянной проверкой (смерти, смены паспорта, ФИО, пола,… или экзотики вида — смена личности для сокрытия людей по программам защиты свидетелей в США).

Так же авторизация в такой системе могла бы быть более надежной чем привычные пароли и даже SMS, например симбиоз их с биометрическими системами (отпечатки пальцев или задницы, распознавание лиц, голоса, стиль использования клавиатуры, мыши и т.п. и даже психопрофиля).

Конечно, помимо информационной составляющей существует проблема управления одним пользователем несколькими аккаунтами, но не такая страшная как сейчас боты рулят тысячами и миллионами, так как регистрация значительно осложнена.

Если попытаться разработать такую систему децентрализованной, с защитой всей базы от доступа (интуиция подсказывает что это скорее всего возможно), то это будет бомба по круче bitcoin с ее proof of work.