Мы же не про кластер говорим, а про реплики. Реплика с множеством мастеров поддерживается с дремучих времен и работает весьма неплохо.
Перечитайте еще раз цитату.
Мы тоже редис используем. Монгу я использовал в одном из прошлых проектов. Я не бешеный евангелист РСУБД, просто не нужно наговаривать :)
Ну, тут уж приходится мириться — или простая вставка(id-parent), но долгая выборка, или сложная модификация, но быстрая выборка дерева.
Не знаю что все так стремятся сравнивать не-реляционные хранилища с реляционными. Они не про скорость :)
It is possible to achieve a multi-master replication scheme beginning with MySQL version 3.23. MySQL Cluster supports conflict detection and resolution between multiple masters since version 6.3 for true multi-master capability for the MySQL Server.
Используем в своём проекте, как и Redis.
Все как-то разом забыли историю СУБД и то, что реляционные хранилища (выражающий отношение; связанный с выражением отношений между чем либо) пришли на смену нереляционным.
История циклична и вправду.
Есть запрос к источнику данных, есть зависимость, которая определяет актуальность этих данных.
CacheDependency в моем понимании может быть чем угодно и реализуется программистом.
Например:
Storage.cache(dependency).get(criteria)
Если dependency не обновился с момента последнего сохранения результата в кеш, то кеш и возвращаем.
Может вы про случай, когда зависимость нетривиальна и определение актуальности информации действительно сложная задача? Приведите утрированный пример, пожалуйста.
Synchronized cache, синхронизированный кеш – клиент вместе с данными получается метку последнего изменения и может спросить у поставщика не изменились ли данные, чтобы повторно из не запрашивать. Такой тип кеширования позволяет всегда иметь свежие данные, но очень сложен в реализации.
Не понимаю. Мы про бекенд говорим или про фронтенд?
Если про бекенд, то не вижу никакой проблемы в вводе CacheDependency.
Если про фронтенд, то опять же нет никакой проблемы — опрашиваем сервер по таймеру или через постоянное соединение отправляем диффы/обьекты клиенту.
В восторге! Связался со своим Дедом Морозом, вот, готовлю упаковывать вязаные носки(девушка связала несколько пар на зиму), книгу(не по айти), одну интересную электронную примочку и фотку из Питера с открыткой.
Интересно, что же мне придет :) :)
PS: Деанонимизации не боюсь, адрес нигде не засвечен. Вот теперь гадайте — я ваш Дед мороз или нет!
Скрипт делает свое дело по вполне четкой схеме. Рефакторить там нечего.
Это неподдерживаемый, нетестируемый, избыточный код. Это сложно назвать процедурным подходом, так как вы не выделяете процедуры(кроме синтетической main(), которая не нужна).
Поддерживаю комментарии VolCh и fso чуть выше.
Мне кажется, что вы неадекватны.
Я потратил своё время на прочтение вашей статьи, пример более-менее вменяемой имплементации, а также на указание явных ошибок. Если вы с чем-то не согласны, давайте обсудим как программисты. Это будет как-минимум не бесполезно.
Вы же говорите не предметно о каких-то абстрактных сущностях вроде «тона» и «уважения».
Тезис 1 — вам не ведом мой тон
Тезис 2 — мне не за что вас уважать, но и неуважать тоже
К слову, я бы не назвал приведенный выше кусок кода хорошим. Он имеет ряд недостатков — жесткое внедрение зависимости, отсутствие проверки данных в массиви $data, отсутствие интерфейса, отсутствие исключений для обработки и многое другое. Но его хотя бы можно рефакторить.
Ваш же код это откровенная бурда из ветвлений, создания буферов вывода, отправок сообщений Игорю и записи в БД.
Вы же понимаете, что то, что если для вас этот пахучий кусочек какашки работает(у нас у всех такие бывают, чего греха таить) совершенно не означает, что сообществу(а не дай бог новичкам) он будет полезен? Вреден.
Погодите-погодите. Давайте разберемся с терминологией и смыслом.
Напомню, что разговор идет об этой вот интересной фразе:
Гигабит легитимного хттп траффика свалит что угодно
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
К тому же 10 гигабит http запросов и 10 гигабит http закачек несколько разные вещи, согласитесь.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
GET /testFile.pngi HTTP/1.0
Host: test.com
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://habrahabr.ru/
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
Перечитайте еще раз цитату.
Мы тоже редис используем. Монгу я использовал в одном из прошлых проектов. Я не бешеный евангелист РСУБД, просто не нужно наговаривать :)
Ну, тут уж приходится мириться — или простая вставка(id-parent), но долгая выборка, или сложная модификация, но быстрая выборка дерева.
Не знаю что все так стремятся сравнивать не-реляционные хранилища с реляционными. Они не про скорость :)
Не холивара ради, но вы исходники того же Mongo читали? Там тоже есть индексы, query cache, parser, query optimizer и еще много страшных слов :)
Используем в своём проекте, как и Redis.
Все как-то разом забыли историю СУБД и то, что реляционные хранилища (выражающий отношение; связанный с выражением отношений между чем либо) пришли на смену нереляционным.
История циклична и вправду.
CacheDependency в моем понимании может быть чем угодно и реализуется программистом.
Например:
Если dependency не обновился с момента последнего сохранения результата в кеш, то кеш и возвращаем.
Может вы про случай, когда зависимость нетривиальна и определение актуальности информации действительно сложная задача? Приведите утрированный пример, пожалуйста.
Не понимаю. Мы про бекенд говорим или про фронтенд?
Если про бекенд, то не вижу никакой проблемы в вводе CacheDependency.
Если про фронтенд, то опять же нет никакой проблемы — опрашиваем сервер по таймеру или через постоянное соединение отправляем диффы/обьекты клиенту.
Интересно, что же мне придет :) :)
PS: Деанонимизации не боюсь, адрес нигде не засвечен. Вот теперь гадайте — я ваш Дед мороз или нет!
Это неподдерживаемый, нетестируемый, избыточный код. Это сложно назвать процедурным подходом, так как вы не выделяете процедуры(кроме синтетической main(), которая не нужна).
Поддерживаю комментарии VolCh и fso чуть выше.
Я потратил своё время на прочтение вашей статьи, пример более-менее вменяемой имплементации, а также на указание явных ошибок. Если вы с чем-то не согласны, давайте обсудим как программисты. Это будет как-минимум не бесполезно.
Вы же говорите не предметно о каких-то абстрактных сущностях вроде «тона» и «уважения».
Тезис 1 — вам не ведом мой тон
Тезис 2 — мне не за что вас уважать, но и неуважать тоже
?
К слову, я бы не назвал приведенный выше кусок кода хорошим. Он имеет ряд недостатков — жесткое внедрение зависимости, отсутствие проверки данных в массиви $data, отсутствие интерфейса, отсутствие исключений для обработки и многое другое. Но его хотя бы можно рефакторить.
Ваш же код это откровенная бурда из ветвлений, создания буферов вывода, отправок сообщений Игорю и записи в БД.
Вы же понимаете, что то, что если для вас этот пахучий кусочек какашки работает(у нас у всех такие бывают, чего греха таить) совершенно не означает, что сообществу(а не дай бог новичкам) он будет полезен? Вреден.
Напомню, что разговор идет об этой вот интересной фразе:
Тоесть пока мы говорим о трафике.
Однако, чуть ниже вы пишете.
Вы каким-то образом разделяете закачки, которые происходят по http протоколу и сами запросы.
Тоесть вот такая-вот штука:
Это http запрос. но вот http ответ, который идет на этот запрос уже не учавствует в нашем обсуждении, верно?
Или это не http траффик? Почему по-вашему в http траффик входят только заголовки клиента?
Вы имели ввиду ситуацию, когда у меня одних хедеров от клиентов 10 гигабит?
По-поводу решений, всё в общем-то просто. Не упираться в IO, балансировать нагрузку между серверами, мониторить, масштабировать по мере необходимости.
10 Гигабит в пике вчера, что я делаю не так? :)