-
Balancer: Все сообщения за 28 Января 2017 года
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
Bredonosec> смотри чтоб не потерялось )))
Bredonosec> а то у нас могут ))
Да, я слышал про Балтнеты и т.п.
В идеале я стремлюсь вообще всюду иметь вторую рабочую копию, чтобы при падении одной можно было легко на другую переключиться. Не всегда получается, но как раз повод будет
Вот ещё подумываю перевезти саму Авиабазу на другой сервер. Б/у с аукциона у Хетцнера. Тоже надо будет думать про резервирование...
Хм. Кстати, мысль. Если за (примерно) те же деньги, что сейчас, взять не сильно более мощный сервер, а два таких же, как сейчас. Нагрузку можно будет понизить не более мощным железом, а распределением запросов на две машины, зато будет резервирование — при отказе одной машины, пусть с тормозами, но все смогут работать на другой Надо подумать...
Bredonosec> а то у нас могут ))
Да, я слышал про Балтнеты и т.п.
В идеале я стремлюсь вообще всюду иметь вторую рабочую копию, чтобы при падении одной можно было легко на другую переключиться. Не всегда получается, но как раз повод будет Вот ещё подумываю перевезти саму Авиабазу на другой сервер. Б/у с аукциона у Хетцнера. Тоже надо будет думать про резервирование...
Хм. Кстати, мысль. Если за (примерно) те же деньги, что сейчас, взять не сильно более мощный сервер, а два таких же, как сейчас. Нагрузку можно будет понизить не более мощным железом, а распределением запросов на две машины, зато будет резервирование — при отказе одной машины, пусть с тормозами, но все смогут работать на другой
Надо подумать...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
инфо
инструменты
Если весь файловый архив убрать в IPFS, обеспечив его раздачу через пару нод (для резервирования) на том же time4vps — это €3/мес. при резервировании и терабайте места.
Тогда можно заморочиться только БД на сервере. При чём может хватить и 24Гб оперативки (32 не обязательно, т.к. часть нагрузки с сервера итак снимется). Жаль, все варианты бюджетных 24/32Гб включают в себя уже итак ёмкие HDD, не сэкономить Цены на Хетцнере начинаются от €27, т.е. €54 за две машины против нынешних €42 за одну. Зато резервирование
...
Хм. Ещё есть Scaleway. €24 за 32G/50G+250G (что значит 50G SSD + 250G Direct SSD ?) или €18 за 16G/50G. Это уже сравнимо/конкурентно по цене...
Тогда можно заморочиться только БД на сервере. При чём может хватить и 24Гб оперативки (32 не обязательно, т.к. часть нагрузки с сервера итак снимется). Жаль, все варианты бюджетных 24/32Гб включают в себя уже итак ёмкие HDD, не сэкономить
Цены на Хетцнере начинаются от €27, т.е. €54 за две машины против нынешних €42 за одну. Зато резервирование ...
Хм. Ещё есть Scaleway. €24 за 32G/50G+250G (что значит 50G SSD + 250G Direct SSD ?) или €18 за 16G/50G. Это уже сравнимо/конкурентно по цене...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
PSS> Что в одном большом файле хранились все изображения.
Это совершенно плохой подход. Это автоматически привязывает к одной программе. И что делать потом, когда её перестанут поддерживать и она перестанет работать?
У меня уже столько таких баз (не по картинкам, своих) лежит по архивам... Ладно, я ещё использовал открытые решения и потом можно вытянуть данные, если понадобится. А сколько есть закрытых, когда данные перестают быть доступными без программы...
Так что единственно верное многолетнее решение для сохранности трудов — это база, работающая на файловой системе. Картинки остаются картинками (т.е. их можно в любой момент посмотреть в любом вьювере), а описания кладутся где-то как-то рядом с ними.
Заодно это крайне упростит синхронизацию, перенос на другие машины, ведение версионных изменений и т.п. И повысит сохранность информации — любые файлы подвержены сбоям. И сбой в одном монолитном файле может убить всю базу. А сбой в одном файле из тысяч повредит только его.
К сожалению, идеального решения тут нет. Если только обрабатывать и помечать одно фотографии — тут до сих пор рулит Picasa, хотя Гугл её забросил и ведёт пусть к закрытию.
Если нужно хранить много текстов с иллюстрациями — можно посмотреть на Zim Desktop Wiki. Но там проблема в нестандартном собственном формате. Проблема маленькая, так как тексты хранятся в простых текстах и даже когда Zim перестанет работать, данные останутся доступны. Но всё равно — не очень удобно.
Я же, наигравшись за пару десятков лет со всем этим зоопарком перешёл на полностью ручную работу с файловой системой Т.е. каталоги, в них картинки, с картинками одноимённые .txt или .md (в Markdown-формате) с описаниями произвольной подробности.
Это совершенно плохой подход. Это автоматически привязывает к одной программе. И что делать потом, когда её перестанут поддерживать и она перестанет работать?
У меня уже столько таких баз (не по картинкам, своих) лежит по архивам... Ладно, я ещё использовал открытые решения и потом можно вытянуть данные, если понадобится. А сколько есть закрытых, когда данные перестают быть доступными без программы...
Так что единственно верное многолетнее решение для сохранности трудов — это база, работающая на файловой системе. Картинки остаются картинками (т.е. их можно в любой момент посмотреть в любом вьювере), а описания кладутся где-то как-то рядом с ними.
Заодно это крайне упростит синхронизацию, перенос на другие машины, ведение версионных изменений и т.п. И повысит сохранность информации — любые файлы подвержены сбоям. И сбой в одном монолитном файле может убить всю базу. А сбой в одном файле из тысяч повредит только его.
К сожалению, идеального решения тут нет. Если только обрабатывать и помечать одно фотографии — тут до сих пор рулит Picasa, хотя Гугл её забросил и ведёт пусть к закрытию.
Если нужно хранить много текстов с иллюстрациями — можно посмотреть на Zim Desktop Wiki. Но там проблема в нестандартном собственном формате. Проблема маленькая, так как тексты хранятся в простых текстах и даже когда Zim перестанет работать, данные останутся доступны. Но всё равно — не очень удобно.
Я же, наигравшись за пару десятков лет со всем этим зоопарком перешёл на полностью ручную работу с файловой системой
Т.е. каталоги, в них картинки, с картинками одноимённые .txt или .md (в Markdown-формате) с описаниями произвольной подробности.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Balancer> Альтернативы IPFS
Впечатления по мере эксплуатации...
Balancer> ZeroNet
Распробовал и оценил. ИМХО, лучший сегодня вариант по созданию и распространению сайтов в p2p, без центрального сервера. Довольно активно общаюсь там, веду блоги и форумы. Даже филиал форумов Авиабазы есть, хотя и пустой
Balancer> Tahoe-LAFS
Интересная альтернатива IPFS для хранения файлов в коллективе (или наборе серверов). В отличие от IPFS не раздаёт «чужие» данные. Позволяет модифицировать данные по ключу. Например, делать аплоад в каталоги. Хорошая скорость. Использую для тестового хранения удалённого с YouTube видео.
Balancer> RetroShare
Отреагировал с большим интересом, но впоследствии разочаровался. Очень закрытая кривая система, которая почти не развивается. Публика в основном весьма параноидальная.
Впечатления по мере эксплуатации...
Balancer> ZeroNet
Распробовал и оценил. ИМХО, лучший сегодня вариант по созданию и распространению сайтов в p2p, без центрального сервера. Довольно активно общаюсь там, веду блоги и форумы. Даже филиал форумов Авиабазы есть, хотя и пустой
Balancer> Tahoe-LAFS
Интересная альтернатива IPFS для хранения файлов в коллективе (или наборе серверов). В отличие от IPFS не раздаёт «чужие» данные. Позволяет модифицировать данные по ключу. Например, делать аплоад в каталоги. Хорошая скорость. Использую для тестового хранения удалённого с YouTube видео.
Balancer> RetroShare
Отреагировал с большим интересом, но впоследствии разочаровался. Очень закрытая кривая система, которая почти не развивается. Публика в основном весьма параноидальная.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
В общем, энтузиазма со стороны так и не увидел, так что, привычно, буду развивать эту тему в одиночку 
Коммьюнити наше не готово для совместной поддержки данных, увы.
Amazon CloudDrive для хранения архива YouTube, дополнительный сервер в Литве с 1Тб места для раздачи файлов... Посмотрим, что в итоге получится
Коммьюнити наше не готово для совместной поддержки данных, увы.Amazon CloudDrive для хранения архива YouTube, дополнительный сервер в Литве с 1Тб места для раздачи файлов... Посмотрим, что в итоге получится
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Не то, чтобы это P2P. И даже не Infonesy. Но всё равно где-то в этот форум...
Для повышения отказоустойчивости и сохранности данных как форумов Авиабазы, так и прочих проектов (включая, кстати, и АвиаПорт) в очередной раз прихожу к мысли, что нужно иметь вторичные резервные полностью рабочие копии сайтов. Речь не о бэкапах, а именно о полной системе, готовой к работе в любой момент.
Раньше я думал много о полной копии (например, rsync для полностью автономного LXC-контейнера), но с этим вариантом всё так и не срослось. Он плохо работает, когда объём БД измеряется десятками гигабайт, а объём файлов — сотнями.
Сложно также поддерживать живую консистентность БД. Да, в том же MySQL отлично работает master-master репликация баз и я даже этим активно пользовался, но... Как только начинаются проблемы с репликацией, потом замучаешься это всё восстанавливать. Время от времени дело доходит до очередного mysqdump/mysql, что выливается, порой, в часы восстановления... Печально. Ещё хуже дело обстоит с разнородными БД на одном сервере.
Проще с файлами. Их можно гонять с машины на машину по rsync. Можно синхронизировать изменения через lsync или btsync/syncthing. Есть небольшие задержки, но чаще это не критично. Проблема тут в том, что p2p-синхронизация тяжело работает на сотнях гигабайт. А централизованная требует каждый раз ручного конфигурирования и жёстко привязывается к структуре проектов.
Интересно тут попробовать IPFS, но руки пока не дошли до массовой практики. Хотя у IPFS есть серьёзный недостаток — невозможность работать с её файлами локально. Они хранятся в собственном формате. В качестве же бонуса — прозрачная работа при смене реплики или при удалённом добавлении файла на другом сервере. Локально он будет гарантированно доступен при обращении, хотя и с задержкой.
С базами же данных я до конца вопрос не решил. Хочу попробовать идею, реализованную в Infonesy. При появлении новых данных или обновлении старых на одном сервере, он сбрасывает JSON-объект в файл в каталог синхронизации. Реплицирующие машины забирают файл и загружают в свои БД. Автоматически решается вопрос структуры сети, так как работа идёт через честный p2p. Проблема конфликта идентификаторов (которой нет в Infonesy — там другой принцип) не возникает при использовании mysql autoincrement offset, как при master-master. Практику тормозит мелочь — надо дорабатывать свои сайтовые движки. Но тут относительно просто — BORS© имеет централизованную точку сохранения объектов, туда и можно встраиваться.
Т.е. система вырисовывается такая. Например, при появлении ответа на форуме, файлы/аттачи сразу кидаются в IPFS. Объекты постинга, обновлённого топика, форума и всего, что обновилось, кидаются в виде JSON в btsync. На удалённом сервере демон, следящий за btsync-каталогом видит прибытие JSON. Считывает данные и грузит их в БД. Файлы, на которые может ссылаться запись, уже сразу доступны в IPFS. Тонкое место тут только в ссылочной целостности базы. Скажем, в случае нового топика постинг может прийти раньше топика. И тогда в БД не получится topic_id сделать внешним ключём для поста... Придётся не пользоваться ссылочной целостностью :-/
Ну и ещё один момент — развёртывание проектов. Недавно переносил АвиаТоп (для разгрузки, а то он процентов 15 нагрузки давал) с сервера Авиабазы на отдельный сервер в DigitalOcean. Теперь думаю переносить на другой сервер, у Scaleway. Постое копирование — это лишняя работа. А я очень ленив Поэтому уже при недавнем переносе я постарался максимально пакетизировать проект. Чтобы можно было развернуть по простому composer require .... Но БД пока переносится ещё вручную. Надо и этот вопрос тоже решить. Миграции и утягивание данных по запросу через p2p-репликацию. Вот это было бы отлично. Но это ещё предстоит делать
Для повышения отказоустойчивости и сохранности данных как форумов Авиабазы, так и прочих проектов (включая, кстати, и АвиаПорт) в очередной раз прихожу к мысли, что нужно иметь вторичные резервные полностью рабочие копии сайтов. Речь не о бэкапах, а именно о полной системе, готовой к работе в любой момент.
Раньше я думал много о полной копии (например, rsync для полностью автономного LXC-контейнера), но с этим вариантом всё так и не срослось. Он плохо работает, когда объём БД измеряется десятками гигабайт, а объём файлов — сотнями.
Сложно также поддерживать живую консистентность БД. Да, в том же MySQL отлично работает master-master репликация баз и я даже этим активно пользовался, но... Как только начинаются проблемы с репликацией, потом замучаешься это всё восстанавливать. Время от времени дело доходит до очередного mysqdump/mysql, что выливается, порой, в часы восстановления... Печально. Ещё хуже дело обстоит с разнородными БД на одном сервере.
Проще с файлами. Их можно гонять с машины на машину по rsync. Можно синхронизировать изменения через lsync или btsync/syncthing. Есть небольшие задержки, но чаще это не критично. Проблема тут в том, что p2p-синхронизация тяжело работает на сотнях гигабайт. А централизованная требует каждый раз ручного конфигурирования и жёстко привязывается к структуре проектов.
Интересно тут попробовать IPFS, но руки пока не дошли до массовой практики. Хотя у IPFS есть серьёзный недостаток — невозможность работать с её файлами локально. Они хранятся в собственном формате. В качестве же бонуса — прозрачная работа при смене реплики или при удалённом добавлении файла на другом сервере. Локально он будет гарантированно доступен при обращении, хотя и с задержкой.
С базами же данных я до конца вопрос не решил. Хочу попробовать идею, реализованную в Infonesy. При появлении новых данных или обновлении старых на одном сервере, он сбрасывает JSON-объект в файл в каталог синхронизации. Реплицирующие машины забирают файл и загружают в свои БД. Автоматически решается вопрос структуры сети, так как работа идёт через честный p2p. Проблема конфликта идентификаторов (которой нет в Infonesy — там другой принцип) не возникает при использовании mysql autoincrement offset, как при master-master. Практику тормозит мелочь — надо дорабатывать свои сайтовые движки. Но тут относительно просто — BORS© имеет централизованную точку сохранения объектов, туда и можно встраиваться.
Т.е. система вырисовывается такая. Например, при появлении ответа на форуме, файлы/аттачи сразу кидаются в IPFS. Объекты постинга, обновлённого топика, форума и всего, что обновилось, кидаются в виде JSON в btsync. На удалённом сервере демон, следящий за btsync-каталогом видит прибытие JSON. Считывает данные и грузит их в БД. Файлы, на которые может ссылаться запись, уже сразу доступны в IPFS. Тонкое место тут только в ссылочной целостности базы. Скажем, в случае нового топика постинг может прийти раньше топика. И тогда в БД не получится topic_id сделать внешним ключём для поста... Придётся не пользоваться ссылочной целостностью :-/
Ну и ещё один момент — развёртывание проектов. Недавно переносил АвиаТоп (для разгрузки, а то он процентов 15 нагрузки давал
) с сервера Авиабазы на отдельный сервер в DigitalOcean. Теперь думаю переносить на другой сервер, у Scaleway. Постое копирование — это лишняя работа. А я очень ленив Поэтому уже при недавнем переносе я постарался максимально пакетизировать проект. Чтобы можно было развернуть по простому composer require .... Но БД пока переносится ещё вручную. Надо и этот вопрос тоже решить. Миграции и утягивание данных по запросу через p2p-репликацию. Вот это было бы отлично. Но это ещё предстоит делать
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Shuric> Можно картинку поменять или цвет цифр?
Так лучше? (Ctrl-F5).
Так лучше? (Ctrl-F5).
… чтобы понять рекурсию, нужно сперва понять рекурсию …
fast> Чушь голимая. Подавляющее крупных провайдеров в мире запрещают на пользовательских машин запуск сервисов.
Прикольно 16 лет спустя читать от запретах p2p
Прикольно 16 лет спустя читать от запретах p2p
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Ещё одно интересное археологическое изыскание
А, ведь, правильно было сказано. Молекулярная биология стала очень прикладной наукой
А, ведь, правильно было сказано. Молекулярная биология стала очень прикладной наукой
… чтобы понять рекурсию, нужно сперва понять рекурсию …
PSS> Использовать старую версию?
Через какое-то время старая версия перестаёт работать в новых ОС А старые ОС перестают работать на новом железе. Не поддерживать же только ради каталога старый комп?
PSS> Все это я читал. Вот только у меня в данный момент как раз и есть такая база. И знали бы Вы как мне не хватает возможности индексанции.
Да, тут мне проще. Я могу тупо сделать grep по текстовым файлам. Или, если понадобится, сгрузить их содержимое в тот же shpinx для последующего поиска.
PSS> Как теперь узнать из какого файла эта иллюстрация.
В общем случае индексация тут не спасёт. Так или иначе, но придётся писать ручками. Или, загрузив каталог, или создав одноимённый текстовый файл, или сохранить скриншот под тем же именем, что и PDF.
В частном, кстати — многие скриншутеры при сохранении содержимого окна (а не всего экрана целиком или вырезки с него) сохраняют картинку по тем же именем, что в заголовке этого окна. А в заголовке окна просмотрщика PDF обычно указано имя этого PDF
PSS> У всех этих снимков можно сделать атрибутику. Когда снимали, когда опубликовали, что на снимке.
Picasa позволяет быстро и удобно навешивать на изображения теги. При чём прописываются они прямо в файле (JPEG — в EXIF, вот за PNG не скажу). Что позволяет не потерять описание при перемещении файла в другой каталог. Кстати, тоже проблема для внешнего индексатора в общем случае. Если файл, описанный в сторонней базе куда-то переместить, база может его потерять.
PSS> Но теперь я не знаю из каких пдфок многие изображения. А просматривать каждый раз 1436 пдфок с сотнями страниц не хочется.
Теги, правда, тут не помогут — т.к. название файла не тег. Но название файла можно вписывать в заголовок картинки или её описание. В принципе, можно довольно сильно автоматизировать даже под Windows. Picasa, когда запущена, отслеживает появление новых картинок. И при внесении в свою базу, выводит всплывающее окошечко. Т.е. сохраняем скриншот, видим окошечко, кликаем по нему — и уже у нас этот скриншот открыт в Picasa. Осталось только вставить в поле заголовка название файла. Потом можем делать с картинкой что угодно, в т.ч. перемещать вне программы — заголовок останется. Кстати, если такую картинку потом, скажем, загрузить в photos.wrk.ru или fotki.yandex.ru — она сохранит заголовок и там
Вот, например, я фотоальбом загружал:
Подписи оттуда на сайт ручками не записывал, подписал всё в Picasa на десктопе...
Через какое-то время старая версия перестаёт работать в новых ОС
А старые ОС перестают работать на новом железе. Не поддерживать же только ради каталога старый комп?PSS> Все это я читал. Вот только у меня в данный момент как раз и есть такая база. И знали бы Вы как мне не хватает возможности индексанции.
Да, тут мне проще. Я могу тупо сделать grep по текстовым файлам. Или, если понадобится, сгрузить их содержимое в тот же shpinx для последующего поиска.
PSS> Как теперь узнать из какого файла эта иллюстрация.
В общем случае индексация тут не спасёт. Так или иначе, но придётся писать ручками. Или, загрузив каталог, или создав одноимённый текстовый файл, или сохранить скриншот под тем же именем, что и PDF.
В частном, кстати — многие скриншутеры при сохранении содержимого окна (а не всего экрана целиком или вырезки с него) сохраняют картинку по тем же именем, что в заголовке этого окна. А в заголовке окна просмотрщика PDF обычно указано имя этого PDF
PSS> У всех этих снимков можно сделать атрибутику. Когда снимали, когда опубликовали, что на снимке.
Picasa позволяет быстро и удобно навешивать на изображения теги. При чём прописываются они прямо в файле (JPEG — в EXIF, вот за PNG не скажу). Что позволяет не потерять описание при перемещении файла в другой каталог. Кстати, тоже проблема для внешнего индексатора в общем случае. Если файл, описанный в сторонней базе куда-то переместить, база может его потерять.
PSS> Но теперь я не знаю из каких пдфок многие изображения. А просматривать каждый раз 1436 пдфок с сотнями страниц не хочется.
Теги, правда, тут не помогут — т.к. название файла не тег. Но название файла можно вписывать в заголовок картинки или её описание. В принципе, можно довольно сильно автоматизировать даже под Windows. Picasa, когда запущена, отслеживает появление новых картинок. И при внесении в свою базу, выводит всплывающее окошечко. Т.е. сохраняем скриншот, видим окошечко, кликаем по нему — и уже у нас этот скриншот открыт в Picasa. Осталось только вставить в поле заголовка название файла. Потом можем делать с картинкой что угодно, в т.ч. перемещать вне программы — заголовок останется. Кстати, если такую картинку потом, скажем, загрузить в photos.wrk.ru или fotki.yandex.ru — она сохранит заголовок и там
Вот, например, я фотоальбом загружал:
Community / Balancer / Гумбинненское сражение 2016 | Фотогалерея сообщества Balancer'а
Community / Balancer / Гумбинненское сражение 2016 // photos.wrk.ruПодписи оттуда на сайт ручками не записывал, подписал всё в Picasa на десктопе...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
PSS> Заглянул. Так Пикаса уже все
PSS> https://picasa.google.ru
PSS> Спасибо гуглу за это. Есть аналоги?
Ну, пока, слава Богу, работает она отлично. А вот аналогов — нет. За что десять лишних проклятий Гуглу Но пока работает.
PSS> https://picasa.google.ru
PSS> Спасибо гуглу за это. Есть аналоги?
Ну, пока, слава Богу, работает она отлично. А вот аналогов — нет. За что десять лишних проклятий Гуглу
Но пока работает.Осторожно! Корпорация добра! [Balancer#30.06.16 15:34]
Нашёл в гуглокеше копию старой страницы с работающей ссылкой https://dl.google.com/picasa/pic asa39-setup.exe — но, похоже, действительно, это всё...// Компьютерный
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Об эмуляции/виртуализации старых ОС для старых программ #28.01.2017 13:00 @V.Stepan#28.01.2017 08:54 
V.Stepan> Сейчас это не такая острая проблема с активным развитием виртуализации.
Однако, всё равно проблема.
Однако, всё равно проблема.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
starshina> Отсутствием/наличием политики? Но это смешно!
Не смешно. Из-за политики в неполитических форумах разосралась огромная масса народа. И многие ушли только из-за того, что их политика достала. Поэтому весь политсрач теперь сносится в соответствующие форумы. Всюду. Хочется потанцполить — на Танцпол.
Не смешно. Из-за политики в неполитических форумах разосралась огромная масса народа. И многие ушли только из-за того, что их политика достала. Поэтому весь политсрач теперь сносится в соответствующие форумы. Всюду. Хочется потанцполить — на Танцпол.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Balancer> Пока для теста перевёл на него отдачу аттачей старого форума
Теперь к ним присоединились и аттачи за 2013 год.
Теперь к ним присоединились и аттачи за 2013 год.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
ReST> Посты Div стёрты?
Куда смотреть?
Div: Все сообщения за 12 Августа 2014 года
Куда смотреть?
Div: Все сообщения за 12 Августа 2014 года
… чтобы понять рекурсию, нужно сперва понять рекурсию …
ReST> После ошибки 503 солнышко не прибавляется, а пост есть.
Не бывает. 503 выпадает до любых действий. А отправка сообщения и изменения в солнышках делаются в одном обращении к серверу. Т.е. если проверку на перегрузку сервера запрос прошёл, то он и отправит пост, и изменит солнышки. Если не прошёл — то не произойдёт и отправка сообщения.
Вот когда не 503, а, например, 504 или 500 — там по-разному может быть. Эти ошибки уже при начавшейся обработке запроса идут. А сообщение сохраняется в БД первым делом, до всего остального. Сперва сохраняется сообщение, а уже потом идёт вся магия вокруг него.
Не бывает. 503 выпадает до любых действий. А отправка сообщения и изменения в солнышках делаются в одном обращении к серверу. Т.е. если проверку на перегрузку сервера запрос прошёл, то он и отправит пост, и изменит солнышки. Если не прошёл — то не произойдёт и отправка сообщения.
Вот когда не 503, а, например, 504 или 500 — там по-разному может быть. Эти ошибки уже при начавшейся обработке запроса идут. А сообщение сохраняется в БД первым делом, до всего остального. Сперва сохраняется сообщение, а уже потом идёт вся магия вокруг него.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Рогозин сообщил о подмене документов при производстве двигателей для «Протона-М»
Вице-премьер Дмитрий Рогозин сообщил, что причиной неполадок при производстве двигателей для ракеты-носителя «Протон-М» стала подмена документации и технологии. Он пообещал, что виновные будут жестко наказаны. «Три "Протона-М" будут разобраны. Двигатели второй и третьей ступеней заменены», — добавил чиновник. // lenta.ru// via Telegram: Contact @airbase_ru
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Andru [Andru#07.11.16 13:30]
В субботу побывал на празднике ветеранов посвященному 55 летию форминования 3-й Дивизии атомных подводных лодок, было более 250 человек, с начала проходила тожественная часть в училище Фрунзе, а потом организованно на автобусах поехали в Дворец Молодежи, где были накрыты прекрасные стол. по итогам праздника потерял только шапку... на фото с бывшим командиром К-53 Степановым Александром Юрьевичем// Персоналии форумов Авиабазы
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Andru> Понаставили импортных фонарей, никто не знает как лампочку поменять.....приходится возглавлять.
«Сколько человек нужно, чтобы поменять импортную лампочку?» — почти ©
«Сколько человек нужно, чтобы поменять импортную лампочку?» — почти ©
… чтобы понять рекурсию, нужно сперва понять рекурсию …
И в рамках Infonesy в целом, и в рамках реплицирования форумов нужно думать о механизме удалённой поисковой индексации.
Пока думаю сделать таким образом. Дёргать чужие сервера по HTTP не лучшая идея в рамках постоянства доступности ресурсов и т.п. Но на помощь может прийти уже активно практикующийся обмен по btsync и/или IPFS. Скажем, при полной индексации сбрасывается дамп БД в унифицированном формате (целиком, или разбитый на файлы по годам/месяцам) в нашу систему обмена. Нода с поисковиком обнаруживает обновление, индексирует его тем же Sphinx с запоминанием ноды и категории. Voilà!
Также и с обновлениями. При чём обновления поисковая нода может брать прямо в обычном Infonesy-потоке.
Скорее всего воспользуюсь Sphinx с XMLPIPE. Основной индекс статический + rt для оперативных обновлений.
Пока думаю сделать таким образом. Дёргать чужие сервера по HTTP не лучшая идея в рамках постоянства доступности ресурсов и т.п. Но на помощь может прийти уже активно практикующийся обмен по btsync и/или IPFS. Скажем, при полной индексации сбрасывается дамп БД в унифицированном формате (целиком, или разбитый на файлы по годам/месяцам) в нашу систему обмена. Нода с поисковиком обнаруживает обновление, индексирует его тем же Sphinx с запоминанием ноды и категории. Voilà!
Также и с обновлениями. При чём обновления поисковая нода может брать прямо в обычном Infonesy-потоке.
Скорее всего воспользуюсь Sphinx с XMLPIPE. Основной индекс статический + rt для оперативных обновлений.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
ReST> У нас вроде как посты не удаляются. А тут такое
Посты не удаляются. Аккаунты пару раз в особых случаях (товарищи грозились судами и блокировками через Роскомнадзор) — да.
Посты не удаляются. Аккаунты пару раз в особых случаях (товарищи грозились судами и блокировками через Роскомнадзор) — да.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Balancer>>Аккаунты пару раз в особых случаях
D.Vinitski> Удивительно, что архив.орг не забанили
D.Vinitski> Удивительно, что архив.орг не забанили
Черный список сайтов Роскомнадзора [Balancer#25.06.15 15:02]
Ну, все, приехали. Блокируют Архив Интернета. Реестр запрещенных сайтов Реестр заблокированных сайтов. Информация из реестров запрещенных сайтов по законам о блокировках интернет-ресурсов. // reestr.rublacklist.net Как раньше выглядела Авиабаза теперь простой юзер не посмотрит...// А вы их дустом пробовали?И снова блокировка archive.org
Не успели ещё полностью утихнуть обсуждения блокировки Википедии, а операторы начали блокировать архив интернета (archive.org). Так как сайт использует https,... // geektimes.ru
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Copyright © Balancer 1997..2024
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
