Clickhouse мы пробовали на других задачах (тоже хранение событий, но уже для внутренней аналитики). Непредсказуемое поведение и ведро процессорных мощностей, которое нужно вкидывать буквально каждый месяц привели к тому, что мы его похоронили в пользу BigQuery.
Новый проект на Phalcon заводить имеет смысл только из большой любви к этому фреймворку. Но когда есть продукт, который уже на нем написан, уже работает и приносит прибыль, смысла использовать Phalcon больше, чем мигрировать на что-то другое.
Спасибо за интересную ссылку. Например, одним из условий размещения у мобильных операторов является возможность ограничить раздачу контента только их клиентам. Плюс различные юридические тонкости. Трёхсторонний договор с западной компанией не всех обрадует. В общем, своё получается проще и гибче.
Nginx не решает вашу задачу. Nginx — это фронтенд вашего объектного хранилища. Swift (либо Ceph) — это объектное хранилище, решающее задачи шардинга и репликации. И к нему тоже нужен фронтенд и тоже с кэшем и это тоже может быть nginx, либо что-то ещё, что хорошо ложится в инфраструктуру и решает задачу. Swift не будет и не может быть быстрее, поскольку это инструмент для совсем другой задачи. Зато там есть репликация, шардинга, отказоустойчивость.
Когда Ceph был не продакшн-рэди уже существовал как минимум Openstack Swift. Не самое быстрое, конечно, решение, но всё же. На дворе 2017 год и Ceph уже давно вполне годен для продакшна. Мы у себя решили похожую проблему как-то так https://www.youtube.com/watch?v=Y8JHEb1BkGQ
Попробовал так как-то. Программисты сделали не то и слишком поздно. Лучше контекст им все-таки давать)
Clickhouse мы пробовали на других задачах (тоже хранение событий, но уже для внутренней аналитики). Непредсказуемое поведение и ведро процессорных мощностей, которое нужно вкидывать буквально каждый месяц привели к тому, что мы его похоронили в пользу BigQuery.
А что используете для тестов? И чем генерируете коллекции?
Новый проект на Phalcon заводить имеет смысл только из большой любви к этому фреймворку. Но когда есть продукт, который уже на нем написан, уже работает и приносит прибыль, смысла использовать Phalcon больше, чем мигрировать на что-то другое.
Когда хранилище делали нужно было «ещё вчера», поэтому выбрали то, что умеем и знаем. К nats пока присматриваемся.
Нет )
Домен один, да и данных в сравнении с фотками гораздо меньше, след. тупит тоже меньше.
Файлы храним в Ceph, отложенную репликацию между дата-центрами с активным бэкапом в AWS S3 реализовали сами на RabbiyMQ + Go
Если я правильно понимаю, нужна автономка, а это сильно дороже.
Спасибо за замечание :)
Спасибо за интересную ссылку. Например, одним из условий размещения у мобильных операторов является возможность ограничить раздачу контента только их клиентам. Плюс различные юридические тонкости. Трёхсторонний договор с западной компанией не всех обрадует. В общем, своё получается проще и гибче.
Nginx не решает вашу задачу. Nginx — это фронтенд вашего объектного хранилища. Swift (либо Ceph) — это объектное хранилище, решающее задачи шардинга и репликации. И к нему тоже нужен фронтенд и тоже с кэшем и это тоже может быть nginx, либо что-то ещё, что хорошо ложится в инфраструктуру и решает задачу. Swift не будет и не может быть быстрее, поскольку это инструмент для совсем другой задачи. Зато там есть репликация, шардинга, отказоустойчивость.
Сравнивать object storage и веб-сервер… Okay…
Пишем параллельно асинхронной 2 ceph-кластера в разных ЦОДах и в AWS S3 в качестве бэкапа для «самого ужасного случая»
Когда Ceph был не продакшн-рэди уже существовал как минимум Openstack Swift. Не самое быстрое, конечно, решение, но всё же. На дворе 2017 год и Ceph уже давно вполне годен для продакшна. Мы у себя решили похожую проблему как-то так https://www.youtube.com/watch?v=Y8JHEb1BkGQ