Комментарии 99
Почему выбрано решение с триггерами, а не простое кэширование поверх логики сайта? Логика работы мне кажется несколько хитрой, что делает систему неустойчивой при дальшейших модификациях и сложной при поддержке
Простое кэширование поверх логики не подходит — связь между узлами по условиям поставленной задачи может быть нестабильной или вовсе отсутствовать. Ничего хитрого в логике не вижу — как раз наоборот, триггеры мне кажутся как раз самым простым решением для отслеживания изменений.
Херня, а не показатели 170К в сутки, кластер. Хоть заминусуйте, но те же адалтеры в 2000-бородатые держали по 300-400К в сутки на одном выделенном сервере (при весьма средней конфиги на те моменты). и да контент как вы понимаете тоже был на этой машине.
Чего-то мне не верится, что в бородатые 2000-е на одном выделенном сервере можно было раздавать контент со скоростью 3 Гигабита в секунду. Да и сейчас мне это представляется хоть и возможным, но несколько ненадёжным решением.
У меня в данный момент новостной сайт с 30-50 тыс визитов в сутки полностью на одном сервере. отдачи видео нет конечно. При этом в пиковые моменты нагрузка составляет 450-500 хитов в минуту, но load average при этом не превышает 1.5. рывки до 100 тысяч визитов в сутки проходили без выпданий сервера в 50х. Он обслуживает много авторизованных пользователей, а не только анонимов. Иными словами 1 сервер имеет хороший запас прочности на нагрузке соответствующей где-то четверти нагрузки вашего кластера, при этом не лишаясь ни управляемости, ни удобств.
Кстати счетчик просмотра страниц я тоже реализовал. Он работает в реальном времени, но чтобы он не создавал проблем я его разместил на google app engine ( помещается в бесплатную квоту с запасом). Скажем новости про Японию сейчас за час набирают 15-20 тыс просмотров (сегодня наверно посещаемость будет высокой), но никаких проблем это не создает. Ваш способ считаю слишком громоздким и неповоротливым.
Кстати счетчик просмотра страниц я тоже реализовал. Он работает в реальном времени, но чтобы он не создавал проблем я его разместил на google app engine ( помещается в бесплатную квоту с запасом). Скажем новости про Японию сейчас за час набирают 15-20 тыс просмотров (сегодня наверно посещаемость будет высокой), но никаких проблем это не создает. Ваш способ считаю слишком громоздким и неповоротливым.
Расскажите подробности — наверняка не мне одному будет интересно. LA я приводил для сервера, который обслуживает 2 админки, а не нод.
То, что спокойно можно построить сервер, который справится с 100к визитов в сутки я и нигде не оспаривал — нам по условию задачи требовался распределённый сервер. А то мало ли что :)
То, что спокойно можно построить сервер, который справится с 100к визитов в сутки я и нигде не оспаривал — нам по условию задачи требовался распределённый сервер. А то мало ли что :)
Расскажите подробности — наверняка не мне одному будет интересно.
такой счетчик — совершенно не сложная вещь. в нем те же принципы, что и во всех системах сбора статистики:
— основной javascript код счетчика подгружается на страницу с сервера. берет настройки для конкретной страницы (id пустого элемента куда выводить результат, текст, которым обрамить цифру приходящую с сервера статистики)
— загрузившись этот скрипт делает ajax-запрос к счетчику и получает ответ в виде jsonp. если запрос окончился ошибкой — тихо прекращает свою работу.
— функция которую вызывает jsonp находится в основном коде и пользуясь конфигурацией проецирует результат на страницу.
— на сервере из приходящего запроса берется адрес страницы которую считаем (или из referer или из специального поля)
— из этого адреса для простоты делается hash и добавляется номер шарды (сейчас счетчик каждой страницы имеет 4 шарды, и вроде бы работает стабильно. если будет не хватать — добавлю). этот ключ используется для инкрементации или создания записи в базе.
— данные по странице обновляются в memcache
— перед выходом результат берется либо из memcache либо из базы, по сумме значений в шардах
— формируется jsonp с ответом и отправляется клиенту
Вы вынуждаете меня на «искромётные портянки» :)
А он и не раздавался на такой скорости. По долгу службы как одмин, я админил и такие сервера уж поверьте мне на слово.
300К в сутки — это примерно 50 конкурирующих запросов в секунду всего-то навсего.
При том, что в суточных запросах (хитах),
это 50*60sec*60min*24h = 4 320 000 запросов в сутки, то есть каждый уникальный IP в среднем получается делает не менее 14 запросов (кликов).
Другое дело (!), что интернеты у людей тогда были потоньше (более узкие каналы и много диалапщиков) и проблема в основном была даже не в канале, а в большом количестве висящих сокетов.
Но даже тогда, когда отдача контента на один запрос была лимитирована до 60-80Кб/с (что не мало кстати и вообще является нормальной практикой), то это получается около 0.5 Mbit/s на запрос, то есть на 50 конкурирующих запросов — это 25 Mbit/s полоса — с учетом что все подключенные могут качать на такой скорости. Конечно трафик тоже распределяется неравномернно по суткам, хотя тут я не могу судить всё зависит от «отрасли», но даже если сместить пик то можно смело умножить полосу на двое и допустить 100 конкурирующих запросов и 50 Mbit'ную полосу.
Предположим у вас 170К в сутки, и допустим все уники у вас («моча им в голову») приходят за пиковые 4 часа (экстремально). Это 170 000 / 4 h / 60 min / 60 sec * 10 запросов =~ 120 запросов в секунду. Даже если на каждый запрос отдать по 1 мегабиту, что немало, то все равно получится 120 мегабит… Не другое дело, конечно, если у вас там все 170К вообще приходят как флешмоб в одночасье и все по часу смотрят видео в 3 потока… но как то цифры удивляют…
А он и не раздавался на такой скорости. По долгу службы как одмин, я админил и такие сервера уж поверьте мне на слово.
300К в сутки — это примерно 50 конкурирующих запросов в секунду всего-то навсего.
При том, что в суточных запросах (хитах),
это 50*60sec*60min*24h = 4 320 000 запросов в сутки, то есть каждый уникальный IP в среднем получается делает не менее 14 запросов (кликов).
Другое дело (!), что интернеты у людей тогда были потоньше (более узкие каналы и много диалапщиков) и проблема в основном была даже не в канале, а в большом количестве висящих сокетов.
Но даже тогда, когда отдача контента на один запрос была лимитирована до 60-80Кб/с (что не мало кстати и вообще является нормальной практикой), то это получается около 0.5 Mbit/s на запрос, то есть на 50 конкурирующих запросов — это 25 Mbit/s полоса — с учетом что все подключенные могут качать на такой скорости. Конечно трафик тоже распределяется неравномернно по суткам, хотя тут я не могу судить всё зависит от «отрасли», но даже если сместить пик то можно смело умножить полосу на двое и допустить 100 конкурирующих запросов и 50 Mbit'ную полосу.
Предположим у вас 170К в сутки, и допустим все уники у вас («моча им в голову») приходят за пиковые 4 часа (экстремально). Это 170 000 / 4 h / 60 min / 60 sec * 10 запросов =~ 120 запросов в секунду. Даже если на каждый запрос отдать по 1 мегабиту, что немало, то все равно получится 120 мегабит… Не другое дело, конечно, если у вас там все 170К вообще приходят как флешмоб в одночасье и все по часу смотрят видео в 3 потока… но как то цифры удивляют…
неужели молдавский трафик такой суровый, что готов отхавать 3 гигабитную полосу, но одном из (пусть даже самом посещаемом) сайтов среди прочих в домене .md, что-то не охотно верится «по Станиславскому».
+1
у нас 4 ноды держат 10 лямов импрешнов в сутки. все флеш видео идет с ЦДН
вопрос автору: я не разобрался как происходит балансировка на ноды. это netdirekt делает? что это вообще аткое :-)
у нас 4 ноды держат 10 лямов импрешнов в сутки. все флеш видео идет с ЦДН
вопрос автору: я не разобрался как происходит балансировка на ноды. это netdirekt делает? что это вообще аткое :-)
Балансировка — обычный round-robin DNS :)
Netdirekt — это провайдер такой у немцев — сдаёт сервера в аренду. По уровню — примерно как и Хетзнер, но за счёт того, что сервера без setup fee немного дороже. Но без setup fee.
Раньше у них траффик был дорогой, но с осени очень полегчало — видимо кто-то ткнул их носом в стоимость траффика у конкурентов.
А какой CDN вы используете?
Netdirekt — это провайдер такой у немцев — сдаёт сервера в аренду. По уровню — примерно как и Хетзнер, но за счёт того, что сервера без setup fee немного дороже. Но без setup fee.
Раньше у них траффик был дорогой, но с осени очень полегчало — видимо кто-то ткнул их носом в стоимость траффика у конкурентов.
А какой CDN вы используете?
imho наоборот. динамика превращается в статику централизованно, и выносить логику из БД в промежуточный слой тут нет совершенно никакой необходимости.
А своя cdn для видео — принципиальная необходимость?
Да, так как де-факто народ привык к локальному быстрому анлиму. У нас только-только начинает стираться разница между «внешкой» и «локалкой» — приведённые выше цифры по траффику касаются только «внешки» — т.е. траффика у Netdirekt/Hetzner. Локальный траффик никто не считает, но не думаю, что там будет меньше 20Тб в месяц.
примечательно, что hetzner считает локальный трафик между серверами.
Если нужно гонять много локального трафика — нужно купить FlexyPack + Additional Switch + Additional NIC на каждый сервер, кроме того желательно, чтобы сервера были в одной стойке (rack), если в разных придется еще заказывать услугу переноса в один rack (69 euro for each server)
Если нужно гонять много локального трафика — нужно купить FlexyPack + Additional Switch + Additional NIC на каждый сервер, кроме того желательно, чтобы сервера были в одной стойке (rack), если в разных придется еще заказывать услугу переноса в один rack (69 euro for each server)
Так мало статей по развертыванию подобных систем, да еще и с реальным примером.
Насколько я понимаю, задача была решена.
Но давайте на секунду предположим, что все это должно работать в реальном времени.
Как бы вы поступил в данном случае, в какую сторону бы копали, какие технологии использовали? Взялись бы за задачу в принципе?
Спасибо.
Насколько я понимаю, задача была решена.
Но давайте на секунду предположим, что все это должно работать в реальном времени.
Как бы вы поступил в данном случае, в какую сторону бы копали, какие технологии использовали? Взялись бы за задачу в принципе?
Спасибо.
Конечно же задача была решена — решение используется до сих пор (хотя мы его постоянно дорабатываем в плане оптимизации).
Со счётчиками в реальном времени дело обстоит хуже. Любой вменяемый клиент понимает, что любые счётчики в реальном времени (даже те, которые показывают на Евровидении) — профанация и шоу (знаю на личном опыте). Тут пришлось бы оговаривать, что мы понимаем под реальным временем.
Навскидку я бы предложил использовать выделенный сервер только для счётчиков, которые бы хранились целиком в оперативке (что-нибудь из Memcached/Redis вполне бы подошло). В случае аврала — отключаем счётчики, меняя конфиг в JS-файле и просто не обращаемся к серверу.
Ну а невменяемому клиенту пришлось бы объяснять, что потребуется создать орбитальную группировку спутникв с мыслесканерами — но так как это дорого, то даже Пентагон этого себе позволить не может :)
Со счётчиками в реальном времени дело обстоит хуже. Любой вменяемый клиент понимает, что любые счётчики в реальном времени (даже те, которые показывают на Евровидении) — профанация и шоу (знаю на личном опыте). Тут пришлось бы оговаривать, что мы понимаем под реальным временем.
Навскидку я бы предложил использовать выделенный сервер только для счётчиков, которые бы хранились целиком в оперативке (что-нибудь из Memcached/Redis вполне бы подошло). В случае аврала — отключаем счётчики, меняя конфиг в JS-файле и просто не обращаемся к серверу.
Ну а невменяемому клиенту пришлось бы объяснять, что потребуется создать орбитальную группировку спутникв с мыслесканерами — но так как это дорого, то даже Пентагон этого себе позволить не может :)
Если я правильно понял odiszapc, ему было интересно Ваше решение для подобной системы, в которой добавление новой статьи должно отрабатываться и отображаться в браузерах клиентов с минимальной задержкой (то есть не совсем «реальное время», но скорее 3-4 секунды чем нынешние 3-5 минут).
Собственно, я поддерживаю этот его вопрос.
Собственно, я поддерживаю этот его вопрос.
Мой ответ по сути не меняется — если требовать географического раскидывания узлов сервера и НЕ иметь при этом высокоскоростной инфраструктуры, которая это всё объединяет — то тогда я не представляю себе, как решить подобную задачу.
Если же речь не идёт о том, чтобы раскидывать сервера и всё находится в одной стойке у одного провайдера — то тогда мы приближаемся к задаче построить свой фейсбук с блэкджеком и далее по тексту :) А его архитектура уже описана, насколько я знаю.
Кстати, именно объяснить заказчику, что не имеет смысла требовать от нас «нажал — и тут же появилось» — было одной из самых сложных задач в этом проекте. Пока не придумали простую аналогию — это НЕ прямой эфир. А для прямого эфира (для тех же яблодевайсов я описывал наше решение тут).
Если же речь не идёт о том, чтобы раскидывать сервера и всё находится в одной стойке у одного провайдера — то тогда мы приближаемся к задаче построить свой фейсбук с блэкджеком и далее по тексту :) А его архитектура уже описана, насколько я знаю.
Кстати, именно объяснить заказчику, что не имеет смысла требовать от нас «нажал — и тут же появилось» — было одной из самых сложных задач в этом проекте. Пока не придумали простую аналогию — это НЕ прямой эфир. А для прямого эфира (для тех же яблодевайсов я описывал наше решение тут).
kirushik верно подметил. Вот например статьи чтоб максимально быстро отображались.
Вообще интересно полноценное горизонтальное масштабирование.
Вообще интересно полноценное горизонтальное масштабирование.
Со счетчиками всё намного проще. Вызывать счетчик надо из javascript. Не загрузился, значит не показываем. Как я писал выше, для немелкого сайта вполне достаточно google app engine для отдельного сервера счетчиков. Мне это удалось для проекта размером в ~75 тыс страниц и 30-50 тыс визитов в сутки. Еще остался пятикратный запас бесплатной квоты :).
Новый программист добавил страницу (не новость) «О разработчиках». Как offline-кеширователь поймет, что ее нужно сгенерировать и отправить на все узлы? Как происходит обновление таких порталов если, скажем, меняется схема базы статические ресурсы, бизнес логика: вручную или скриптом? Что если обновление не удалось, например, после смены схемы база данных приложение не завелось, то все откатывается со всех узлов вручную или скриптом? Если скриптом, то как он тестируется: вручную или автотестами (какими).
У добавленной страницы поле generation_id будет больше значения генератора на момент последней синхронизации. Соответственно, при следующей синхронизации, она попадёт в список страниц, которые требуется (пере)создать на диске. Точно то же самое происходит со страницами, которые обновляются каскадно — значение генератора же всегда растёт вверх.
При этом, 10% канала каждой ноды (это как раз 10 или 100 мегабит, в зависимости от конкретного подключения) зарезервировано для синхронизации.
Любопытно, как это сделано?
И получается, что схема не подходит для мало-мальски динамических сайтов?
Резервирование канала сделано просто — приоритеты у ssh и http протоколов разные и исходящий траффик ограничен 90% пропускной сопсобности сервера на уровне iptables (используем arno iptables firewall).
Я не знаю примеров динамических сайтов, которые были бы географически разбросаны по миру и при этом не использовали бы собственной инфраструктуры для связи серверов. По условию задачи каналы между серверами могут вообще отсутствовать некоторое время.
Если бы всё было изначально в одной стойке — то тогда проблем нет — ставим кучу проксирующих nginx-ов и никаких проблем :)
Я не знаю примеров динамических сайтов, которые были бы географически разбросаны по миру и при этом не использовали бы собственной инфраструктуры для связи серверов. По условию задачи каналы между серверами могут вообще отсутствовать некоторое время.
Если бы всё было изначально в одной стойке — то тогда проблем нет — ставим кучу проксирующих nginx-ов и никаких проблем :)
НЛО прилетело и опубликовало эту надпись здесь
Синхронизацю нужно проводить не чаще раза в неделю, при том, что каждый сервер статики должен получать все то, что получил один из серверов методом POST
Я не совсем понял вашу мысль. Вы действительно хотите обновлять информацию на статических серверах, для новостей, раз в неделю?
Я не совсем понял вашу мысль. Вы действительно хотите обновлять информацию на статических серверах, для новостей, раз в неделю?
Почему много? Де-факто их 1+N, где N — количество нод, которые мы хотим задействовать и 1 — это сервер админки. Остальное — это резерв на случай «бадабум». 2 DNS сервера всё равно учасвуют в любой схеме — просто в данном случае их предоставлял не провайдер (регистрант) а мы сами, так как нам требуется полный контроль над DNS.
Раздавать статику для 130 тысяч посетителей, да еще и в день — много мощностей не надо, один сервер с достаточным количеством памяти (для кэширования той самой статики) и гигабитной сетевухой вполне справится. Однако, чтобы это реализовать, надо сначала обуздать буйную фантазию тех, кто «в теме» вебдванольности, социальных сетей (у которых почти все страницы — динамика), но слабо представляет, сколько эта динамика стоит. Не говоря о том, что для новостного сайта такая архитектура («публикация» статических страниц) подходит хорошо, а вот для других…
:) Ну тут ещё и требовалось сделать сервера географически распределёнными. По поводу гигабитной сетевухи — в нашем случае, её недостаточно, во время выборов только видео тянулось на общей скорости примерно 3 гигабита в секунду. Нельзя впихнуть невпихуемое :)
Ну и я не претендую на то, что у нас получился «решатель всего» — под каждую задачу — своё решение.
Ну и я не претендую на то, что у нас получился «решатель всего» — под каждую задачу — своё решение.
По-настоящему отказоустойчивую схему (без центральной точки входа, с несколькими ДЦ) без своей AS и PI-блока IP адресов реализовать невозможно. Да и бюджетным ДЦ такие клиенты не очень интересны. Все что остается — рулить ДНСами.
Географическая распределенность серверов отдачи контента легко делается центральной точкой на том же Nginx'е, выдающем редиректы на нужный сервер на основании GeoIP от maxmind, типа
md_client -> video.journaltv.md -> video-md.jurnaltv.md
eu_client -> video.journaltv.md -> video-eu.jurnaltv.md
Ну и раздача видео — это задача отдельная. Там кэшировать контент бессмысленно, быстрые диски и nginx (fms по желанию) — все что нужно для раздачи
Географическая распределенность серверов отдачи контента легко делается центральной точкой на том же Nginx'е, выдающем редиректы на нужный сервер на основании GeoIP от maxmind, типа
md_client -> video.journaltv.md -> video-md.jurnaltv.md
eu_client -> video.journaltv.md -> video-eu.jurnaltv.md
Ну и раздача видео — это задача отдельная. Там кэшировать контент бессмысленно, быстрые диски и nginx (fms по желанию) — все что нужно для раздачи
А каким макаром у вас iowait > 200%
Очень интересно как это технически сделать
Очень интересно как это технически сделать
1. Сколько просмотров в сутки совершают ваши посетители в среднем?
2. Не будь скрипта, генерации всего сайта, то сколько времени занимала бы генерация средней страницы при просмотре ее посетителем?
3. Какое по факту получилось время реакции системы на изменения? Т.е. сколько проходит секунд\минут\часов между тем как я выложил новую статью с фотками и тем, что ее гарантировано могут увидеть все посетители?
4. Не возникает ли 404-ссылок — система сгенерировала страницу list_news.html с URL на страницу news123.html, но сама страница news123.html еще не попала на серверы отдачи?
Пока все :) Ну и хотелось бы кусков кода :) Например, для rsync
2. Не будь скрипта, генерации всего сайта, то сколько времени занимала бы генерация средней страницы при просмотре ее посетителем?
3. Какое по факту получилось время реакции системы на изменения? Т.е. сколько проходит секунд\минут\часов между тем как я выложил новую статью с фотками и тем, что ее гарантировано могут увидеть все посетители?
4. Не возникает ли 404-ссылок — система сгенерировала страницу list_news.html с URL на страницу news123.html, но сама страница news123.html еще не попала на серверы отдачи?
Пока все :) Ну и хотелось бы кусков кода :) Например, для rsync
1. Средняя страница состоит из 100-120 элементов, 29 ноября, к примеру, суммарно было около 600к pageviews. Т.е. около 6М запросов к серверам в этот день.
2. Не знаю, никогда не проверяли, изначально была выбрана такая архитектура.
3. Синхронизация стартует раз в 5 минут, среднее время до появления новости 2.5 минуты при нормальной связи и несколько больше при перебоях (это непрогнозируемо).
4. Возникали, но редко и в основном это происходит, когда колбасит связь между серверами. Имено потому, что мы делаем синхронизацию в 2 прохода (сначала видео и картинки. потом текст) — это возникает очень редко на практике, так как ноды синхронизируются в параллели — то может быть ситуация, когда одна нода полностью синхронизирована, посетитель попадает на нее, но видео браузер решает подгрузить с другой ноды.
По поводу кода самой синхронизации — там вообще нет ничего интересного, вот, например, кусок, который синхронизирует текст:
#syncing text
for mirror in $MIRRORS
do
STAT_STRING="${STAT_STRING} `date +%s`,"
for datadir in $DIRLIST2
do
echo -n $SYNCDIR$datadir;
echo -n "->";
echo -n $mirror$datadir;
echo;
/usr/bin/rsync -avlrpz --delete --copy-links --force --timeout=120 --exclude-from=./excludes.rsync $SYNCDIR$datadir $mirror$datadir
done
STAT_STRING="${STAT_STRING} `date +%s`,"
done
Для видео то же самое, только можно сэкономить процессорное время. если отключить сжатие — так как его смысла жать не имеет вообще.
2. Не знаю, никогда не проверяли, изначально была выбрана такая архитектура.
3. Синхронизация стартует раз в 5 минут, среднее время до появления новости 2.5 минуты при нормальной связи и несколько больше при перебоях (это непрогнозируемо).
4. Возникали, но редко и в основном это происходит, когда колбасит связь между серверами. Имено потому, что мы делаем синхронизацию в 2 прохода (сначала видео и картинки. потом текст) — это возникает очень редко на практике, так как ноды синхронизируются в параллели — то может быть ситуация, когда одна нода полностью синхронизирована, посетитель попадает на нее, но видео браузер решает подгрузить с другой ноды.
По поводу кода самой синхронизации — там вообще нет ничего интересного, вот, например, кусок, который синхронизирует текст:
#syncing text
for mirror in $MIRRORS
do
STAT_STRING="${STAT_STRING} `date +%s`,"
for datadir in $DIRLIST2
do
echo -n $SYNCDIR$datadir;
echo -n "->";
echo -n $mirror$datadir;
echo;
/usr/bin/rsync -avlrpz --delete --copy-links --force --timeout=120 --exclude-from=./excludes.rsync $SYNCDIR$datadir $mirror$datadir
done
STAT_STRING="${STAT_STRING} `date +%s`,"
done
Для видео то же самое, только можно сэкономить процессорное время. если отключить сжатие — так как его смысла жать не имеет вообще.
js/css объединяете? ну и если на странице 100 элементов, то при 600к просмотров должно быть 60М запросов к серверу…
Упс, да, на порядок ошибся. Нет, объединяем, но не всё. Даже индусы делают скрытые пустые циклы в коде, которые корни квадратные считают. Надо же оставить себе что-нибудь для допиливания ;-)
Если серьёзно — то та часть, которая не меняется — очень хорошо кэшируется браузером. Ну а та, что меняется — не объединяется по определению. :)
Если серьёзно — то та часть, которая не меняется — очень хорошо кэшируется браузером. Ну а та, что меняется — не объединяется по определению. :)
man rsync
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
-a, --archive archive mode; equals -rlptgoD (no -H,-A,-X)
Какой-то шарашкин кластер…
Видео хранится 3 месяца, т.е., я так понимаю, упирается в свободное место на диске сервера, т.е. горизонтального масштабирования тут нет и не предвидится.
Статическая версия сайта, распространяющаяся по зеркалам rsync'ом, конечно, уникальное решение, никому и в голову ничего подобного не придет никогда.
Распределенный счетчик посещений на текстовых файликах — это только первый элемент динамического сайта, с которым вы столкнулись. Как только захотите чего-то большего, ваш кластер вдруг превратится в тыкву.
Firebird в качестве базы… Тут, честно говоря, просто нет слов. Нет, я, конечно, понимаю, что сайт, собственно, полностью статичный и количество изменений на нем позволяют вести базу хоть на текстовых файлах… Но такое но.
Видео хранится 3 месяца, т.е., я так понимаю, упирается в свободное место на диске сервера, т.е. горизонтального масштабирования тут нет и не предвидится.
Статическая версия сайта, распространяющаяся по зеркалам rsync'ом, конечно, уникальное решение, никому и в голову ничего подобного не придет никогда.
Распределенный счетчик посещений на текстовых файликах — это только первый элемент динамического сайта, с которым вы столкнулись. Как только захотите чего-то большего, ваш кластер вдруг превратится в тыкву.
Firebird в качестве базы… Тут, честно говоря, просто нет слов. Нет, я, конечно, понимаю, что сайт, собственно, полностью статичный и количество изменений на нем позволяют вести базу хоть на текстовых файлах… Но такое но.
P.S. Почему вы вообще называете это кластером? Раунд-робин на DNS на серверы с идентичным статическим контентом и мастер-нода для генерации контента — это что, кластер?
Кластер — объединение нескольких однородных элементов, в данном случае нод.
Ваш кэп.
Ваш кэп.
ru.wikipedia.org/wiki/%D0%9A%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80_%28%D0%B3%D1%80%D1%83%D0%BF%D0%BF%D0%B0_%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BE%D0%B2%29
или вот:
en.wikipedia.org/wiki/Computer_cluster
На HA это, конечно. не тянет. но тем не менее — это кластер. По определению.
или вот:
en.wikipedia.org/wiki/Computer_cluster
На HA это, конечно. не тянет. но тем не менее — это кластер. По определению.
>Firebird в качестве базы…
а что не так с Firebird?
а что не так с Firebird?
Vacuum можно делать только остановив базу, smp поддерживается коряво, брошена борландом и пытается выкопаться.
У. Что за глупости Вы говорите :)
Во-первых, надо говорить sweep, т.к. vacuum появился в Постгре позже.
Во-вторых, gfix -sweep работает и без отключений пользователей (это легко проверить)
В-третьих, правильно написанное приложение двигает маркеры транзакций синхронно и вообще не нуждается в sweep — весь мусор собирается кооперативно.
Песнь про Борланд и т.д. комментировать не буду, не мой уровень фантазии :)
habrahabr.ru/blogs/open_source/105555/
Во-первых, надо говорить sweep, т.к. vacuum появился в Постгре позже.
Во-вторых, gfix -sweep работает и без отключений пользователей (это легко проверить)
В-третьих, правильно написанное приложение двигает маркеры транзакций синхронно и вообще не нуждается в sweep — весь мусор собирается кооперативно.
Песнь про Борланд и т.д. комментировать не буду, не мой уровень фантазии :)
habrahabr.ru/blogs/open_source/105555/
sweep, на сколько я понимаю, делает не совсем то.
Я про растущий размер файла базы, который уменьшить можно только остановив базу и проделав над некий некое колдовство.
Я сам под firebird не писал, но довелось админить сервер под виндой с ней. Это был, мягко говоря, ад. В частности, упомянутый vacuum (я подразумеваю под ним сокращение размера дискового файла базы) предполагалось делать регулярно (раз в сутки), потому что за следущие сутки он вырастал за пределы оперативной памяти и всё начинало дико тормозить (я тот софт не писал, что они там накосячили — не знаю). Соответственно, о работе в режиме 24/7 не могло быть и речи. На деле выходило где-то 23,5/7.
Я про растущий размер файла базы, который уменьшить можно только остановив базу и проделав над некий некое колдовство.
Я сам под firebird не писал, но довелось админить сервер под виндой с ней. Это был, мягко говоря, ад. В частности, упомянутый vacuum (я подразумеваю под ним сокращение размера дискового файла базы) предполагалось делать регулярно (раз в сутки), потому что за следущие сутки он вырастал за пределы оперативной памяти и всё начинало дико тормозить (я тот софт не писал, что они там накосячили — не знаю). Соответственно, о работе в режиме 24/7 не могло быть и речи. На деле выходило где-то 23,5/7.
Ну дык кривыми-то ручками и Оракл народ на серверах за пол лимона евро раком ставил :) Так что нечего на инструмент пенять в стиле «не читал, но осуждаю».
Ок, ручки.
Так а что с растущим файлом базы-то? Можно онлайн его уменьшить?
Так а что с растущим файлом базы-то? Можно онлайн его уменьшить?
А зачем? Я не издеваюсь, я просто не понимаю. Особенно, если оно лежит на raw device — там понятия размера как такового нет. А сколько страниц себе пометил сервер — его личное дело, меня это вообще не интересует.
У нас файл быстро рос (специфика базы такая), пока не забивал весь диск. Дальше все умирало.
> пока не забивал весь диск
В оригинальном посте Вы упомянули о тормозах, которые возникали при превышении размера ОЗУ.
Вопрос — у Вас ОЗУ было очень большим или диск очень маленьким?
Если данных действительно было много, то БД соответственно растет. Другое дело, если данные удалялись, но освобожденное пространство не использовалось повторно. Вот это уже явный косяк разработчиков БД в управлении транзакциями и непонимание версионности.
В оригинальном посте Вы упомянули о тормозах, которые возникали при превышении размера ОЗУ.
Вопрос — у Вас ОЗУ было очень большим или диск очень маленьким?
Если данных действительно было много, то БД соответственно растет. Другое дело, если данные удалялись, но освобожденное пространство не использовалось повторно. Вот это уже явный косяк разработчиков БД в управлении транзакциями и непонимание версионности.
Когда база выростала за пределы оперативной памяти, начинались подтормаживания. С ними, впринципе, можно было работать, но дальше кончался диск. Как-то это быстро наступало… Не помню, то ли диск был маленьким, то ли раздел с базой. Что-то около 30Гб там было всего, если не ошибаюсь. После vacuum база усыхала до 30-40 мегабайт и снова можно было работать. Но процесс этот занимал 20-40 минут, что было неприемлимо.
Там вообще сложно было сказать, откуда берутся тормоза, потому что на сервере бежало сразу много всякой хрени (всё относилось к программе), но из жрущих память процессов был только firebird.
А что при работе с raw-device, оно само потом начинает повторно удаленные куски использовать? А с фрагментацией тогда как быть?
Разумеется, сервер использует освободившиеся страницы заново. Даже есть такой трюк — создать табличку на несколько миллионов записей, а потом дропнуть её. Позволяет бороться с фрагментацией базы. Но это использовалось для ранних версий — сейчас не знаю, использует ли это кто-нибудь вообще.
С фрагментацией никак не быть — это заботы ОС. По крайней мере для *никсовых ФС ничего, кроме полного копирования, удаления и последующего копирования обратно эффективно не работает.
С фрагментацией никак не быть — это заботы ОС. По крайней мере для *никсовых ФС ничего, кроме полного копирования, удаления и последующего копирования обратно эффективно не работает.
Я так понимаю, желание уменьшить размер происходит не от недостатка места на диске, а от тормозов, возникающих в какой-то момент при превышении определенного размера?
Поэтому нужно решать не проблему с размером, которая при текущей стоимости терабайтного диска никак не является проблемой, а проблему производительности, которая на 99% кроется в неверном управлении транзакциями и неумении писать SQL-запросы.
Т.е. надо найти косяки разработчиков и потыкать туда разработчиков (политкорректно это называется «провести обучение» :)
Если проблема с диспетчерской еще актуальна и разработчики в наличии/доступности, то пишите в личку — поможем найти зарытых собак и повесить их на виновных.
Поэтому нужно решать не проблему с размером, которая при текущей стоимости терабайтного диска никак не является проблемой, а проблему производительности, которая на 99% кроется в неверном управлении транзакциями и неумении писать SQL-запросы.
Т.е. надо найти косяки разработчиков и потыкать туда разработчиков (политкорректно это называется «провести обучение» :)
Если проблема с диспетчерской еще актуальна и разработчики в наличии/доступности, то пишите в личку — поможем найти зарытых собак и повесить их на виновных.
Софт писался в дремучие времена на дельфи под interbase. Потом софтину скинули на другую фирму, которая перенесла все на firebird и крайне слабо понимала, что происходит в программе. Многие глюки не фиксились месяцами, если не годами.
Зачем нужна база, с которой нужно пылинки сдувать, что б она работала?
Зачем нужна база, с которой нужно пылинки сдувать, что б она работала?
> Если проблема с диспетчерской еще актуальна и разработчики в наличии/доступности, то пишите в личку — поможем найти зарытых собак и повесить их на виновных.
Прогу выкинули, написали свою. В качестве базы используем CouchDB — доволен как слон. Тут тебе и 24/7, и надежность, и failover из коробки. Без плясок с бубном и тюнинга.
Прогу выкинули, написали свою. В качестве базы используем CouchDB — доволен как слон. Тут тебе и 24/7, и надежность, и failover из коробки. Без плясок с бубном и тюнинга.
ru.wikipedia.org/wiki/CouchDB — Документоориентированная СУБД, без схемы данных?
CouchDB предназначена для работы с полу-структурированной информацией и имеет следующие особенности:
* данные сохраняются не в строках и колонках, а в виде JSON-подобных документов, моделью которых является не таблицы, а деревья;
Если в решении используется документоориентированная СУБД, и использование удачное, то либо в первоначальном ТЗ был жутчайший мискастинг (это как если бы Арнольда на роль хоббита Фродо назначить), либо вся консерватория нуждается в сносе.
Мне было бы очень интересно увидеть статью на хабре, в которой было бы описано решение. Особенно построение отчетов. Очень интересно.
CouchDB предназначена для работы с полу-структурированной информацией и имеет следующие особенности:
* данные сохраняются не в строках и колонках, а в виде JSON-подобных документов, моделью которых является не таблицы, а деревья;
Если в решении используется документоориентированная СУБД, и использование удачное, то либо в первоначальном ТЗ был жутчайший мискастинг (это как если бы Арнольда на роль хоббита Фродо назначить), либо вся консерватория нуждается в сносе.
Мне было бы очень интересно увидеть статью на хабре, в которой было бы описано решение. Особенно построение отчетов. Очень интересно.
Никакого мискастинга. Документ-ориентированных базы данных представляют как некий ужас, в котором ничего нельзя и полный бардак, но это не так. Все стройно, логично. Проблем с отчетами никаких нету, все нативно.
Статьи на хабре не будет, потому что не вижу смысла.
Если интересно, решений на couchdb много, посмотрите любое. Самое сложное изначально — вывернуть себе мозги, отказавшись от нормализации данных и понять, что денормализация — не зло :)
Ну а дальше map-reduce и побочные фишки. Тоже мозги прочищают.
Статьи на хабре не будет, потому что не вижу смысла.
Если интересно, решений на couchdb много, посмотрите любое. Самое сложное изначально — вывернуть себе мозги, отказавшись от нормализации данных и понять, что денормализация — не зло :)
Ну а дальше map-reduce и побочные фишки. Тоже мозги прочищают.
Пара-тройка пруфлинков по реализации систем ERP/CRM с CouchDB в качестве основного хранилища данных могла бы поколебать мои сомнения в пригодности документоориентированных систем для этих целей.
Что касается денормализации — это какой-то новый поворот в нашей оффтопной дискуссии. Денормализация и хранимые агрегаты — важнейшие элементы работы с DBMS, никто против не выступает.
Ну и совет по прочистке мозгов тоже отвергается — для этой цели я использую Bas Armagnac 1987 года выпуска, хэш-таблицы давно не вставляют, как их не обзови.
Что касается денормализации — это какой-то новый поворот в нашей оффтопной дискуссии. Денормализация и хранимые агрегаты — важнейшие элементы работы с DBMS, никто против не выступает.
Ну и совет по прочистке мозгов тоже отвергается — для этой цели я использую Bas Armagnac 1987 года выпуска, хэш-таблицы давно не вставляют, как их не обзови.
Понятно, негативный опыт случается.
На деле все не так плохо — системы 24/7 на Firebird существуют и работают. Но — на любой СУБД режим 24/7 потребует серъезных усилий помимо установки из коробки, т.е. требование 24/7 может относиться к информационной системе в целом, а не к конкретному экземпляру СУБД.
А что это за софт был?
На деле все не так плохо — системы 24/7 на Firebird существуют и работают. Но — на любой СУБД режим 24/7 потребует серъезных усилий помимо установки из коробки, т.е. требование 24/7 может относиться к информационной системе в целом, а не к конкретному экземпляру СУБД.
А что это за софт был?
Ух, какие ужасы вы рассказываете. У меня в одном проекте из-за моей ошибки в коде пул коннектов разросся до 560 коннектов к двухгиговой базе. И ниччо так, сервер даже не тормозил.
А вы, судя по использованному термину «vacuum», фанат Постгри? Тоже хороший сервер, некоторые вещи научился делать относительно недавно, хотя дока у него очень хорошая, это факт. Но эта статья не холивару ради — сделайте решение на своих любимых технологиях и поделитесь опытом, много опыта не бывает, всем будет интересно.
А вы, судя по использованному термину «vacuum», фанат Постгри? Тоже хороший сервер, некоторые вещи научился делать относительно недавно, хотя дока у него очень хорошая, это факт. Но эта статья не холивару ради — сделайте решение на своих любимых технологиях и поделитесь опытом, много опыта не бывает, всем будет интересно.
НЛО прилетело и опубликовало эту надпись здесь
>> ТС: вы о кластерных фс вообще слышали что нибудь? Ну это кода на одном узле чето пишешь в папочку, а другой читает синхронно, да еще и сам писать может.
Да что вы говорите, неужели есть такая технология? Вау, как круто. Она наверняка работает на нестабильных каналах и даже заклинаний типа Infiniband вызывать не надо? Вы ещё Викиликс напишите, что у них сайт неправильный, бо одна статика, которую можно запаковать и в кармане утащить.
Если серьёзно, я знаю что такое кластеры, люстры и прочее. И чем POSIX от MOSIX кластера отличается тоже (хотя на последний израильские товарищи, похоже, забили). И как делать XEN live migration на DRBD тоже, сам делал. Но в данном случае — статья не об этом.
Да что вы говорите, неужели есть такая технология? Вау, как круто. Она наверняка работает на нестабильных каналах и даже заклинаний типа Infiniband вызывать не надо? Вы ещё Викиликс напишите, что у них сайт неправильный, бо одна статика, которую можно запаковать и в кармане утащить.
Если серьёзно, я знаю что такое кластеры, люстры и прочее. И чем POSIX от MOSIX кластера отличается тоже (хотя на последний израильские товарищи, похоже, забили). И как делать XEN live migration на DRBD тоже, сам делал. Но в данном случае — статья не об этом.
> Страна у нас маленькая, ничего страшного не происходит (и мы этому рады), но раз в 4 года у нас традиционно проходят выборы в Парламент. Который уже традиционно никак не избирает Президента.
Поэтой фразе, сразу понял, что речь идет о Молдове. Сам держу новостной сайт для одного молдавского политолога, ava.md
Посещаемость конечно не такая как у вас, но в день выборов было около 40 тыс уникалов и около 200 тыс просмотренных страниц.
Поэтой фразе, сразу понял, что речь идет о Молдове. Сам держу новостной сайт для одного молдавского политолога, ava.md
Посещаемость конечно не такая как у вас, но в день выборов было около 40 тыс уникалов и около 200 тыс просмотренных страниц.
А вот как бы тоже самое но с динамикой.
Вот, например, захотите вы прикрутить комменты к новостям — и усе… приплыли :(
Вот, например, захотите вы прикрутить комменты к новостям — и усе… приплыли :(
А они есть. От фейсбука. ;-) Только не надо говорить, что это читерство. :D
Как раз с каментами проблем нет — Disqus рулит. ;) Но в принципе вы правы.
А если мы хотим, чтобы пользователи вели блоги?
Конечно, можно на ЖЖ посылать :))
Вообще, конечно, статика это читерство… сейчас нужна персонализация и прочие плюшки.
Конечно, можно на ЖЖ посылать :))
Вообще, конечно, статика это читерство… сейчас нужна персонализация и прочие плюшки.
А зачем нужна географическая распределенность? Такое ощущение, что в данном случае от нее больше проблем и ограничений, чем пользы.
Вы очень невнимательно читали то место, где я упомянул про лояльность ;-)
Ко всему прочему — особенность местного Интернет-а — все привыкли к локальному траффику. Сейчас (решению уже 2 года скоро будет) разница между локальным и внешним траффиком стирается, но всё ещё есть.
Ко всему прочему — особенность местного Интернет-а — все привыкли к локальному траффику. Сейчас (решению уже 2 года скоро будет) разница между локальным и внешним траффиком стирается, но всё ещё есть.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Веб-кластер — опыт реального применения