Начинание хорошее, но еще долго придется идти к хорошей версии конечного продукта.
Технические ошибки (в переводе откуда-то появляются: точки, запятые с пробелами лишние), не верное оформление текста - путь еще длинен и суров, но идея сама имеет место быть. Поддерживаю вас - сил и успехов.
Как архивы, заверенная нотариусом дата публикации и прочее, повлияют на сайт абузера, который выставит дату публикации более раннюю? И его сайт не индексируется ни гуглом ни архивом - а страница для проверки есть, и дата там меньше, чем у вас - вы вор? Чем докажете?
Задание то для работы расписания CRON в панелях управления сервером.
Видимо aPanel решили нанять кодера и все-таки напсиать нормальную работу крона, после того, как я им указал, что их "добавляльщик" крона не умеет никаких интервалов временных добавлять :) Либо кто-то пишет свою панель и хочет выйти на рынок.
CRON в котором реализованы ми-секунды, реально должен кушать мало памяти, ибо слишком быстро, если очередь будет периодически "флашиться" из памяти и перезагружаться.
Автор: А вот порог расчетных гармоник по мощности, думаю надо бы еще отбирать, например, среднеквадратичным отклонением, чтобы включить не самые пиковые, а просто все, которые влияют до определенного предела на результат, а иначе, с топовыми гармониками у вас в низших точках получились слишком сильные отклонения в прогнозах, именно из-за нехватки числа гармоник в среднем ряду.
Нечего делать в большом проекте тому, кто даже не работал с типизированными языкми и не принял за привычку объявлять переменые и принудительно подтверждать типы.
Я осуждаю даже тех, кто работая с типизированным языком, отключает опцию IDE, требующую явных объявлений и типизации.
Преобразование типов, замену разделителей дробной части, локальной денежной единицы, просто должно врасти в организм на уровне инстинктов. И выбирать мертвый язык вместо развивающегося, именно из-за своей проблемы, а не проблемы языка — это моветон.
Не, в партициях ровно просто разделить и делать много запросов, по однму в каждую партицию, узнать разницу между кодом работы партиций и кодом работы с разными таблицами, чтобы увидеть где быстрее.
В любом случае спасибо за напутствие, буду пробовать.
Да решений для тестов много, нужно просто правильно подобрать размеры и веса решений.
Вот сейчас откатываю разные размеры партиций и отдельных таблиц, а не партиций и вместо одного — 5-20 запросов, если процент выигрыша будет существенный, это будет очередной костыль, пока не будет найдено протестировано более быстрое и незатратное решение.
Пробую и файловые операции использовать на регэкспах, вместо полнотекста в БД, посмотрим, понюхаем.
А вы считает, что раз гул и риа то должны кидать деньги налево и направо и брать горлом мощностью, а не оптимизированностью?
Нет, чем больше и круче компания, тем серьезнее и интереснее стараются подойти к оптимизации.
Мои вот движки держат легко 120-200 тыс посетителей в стуки даже на одно-двух процессорных вдс за доллар, при этом, обновление данных каждые 20-40 секунд.
И именно потому, что я очень жестко подхожу к борьбе за каждый байт и процессорную операцию при разработке, это уже как азарт просто, само-собой разумеющийся.
Сейчас вот как раз озадачаен решением выше-озвученной задачи для вдс на 2-3 CPU ядра средней линейки.
Нет, не разнесем — может сразу ДЦ купим ради десятка миллионов запсией?
Всё на одном сервере, и внешний поисковый двиг только добавит нагрузку.
Поиск по меткам — как пример, что сейчас есть по меткам, а дальше предположение, что был полнотекст на хабре вначале пути.
«Поиск „похожих новостей“ и полнотекстовый поиск — это две большие разницы» нет, никакие метки вам не дадут гарантии похожести, полнотекст лидирует, либо человек должен проверять глазами выборку после меток.
Полнотекст обязателен для вывода похожих новостей в релевантном поиске (как у гулга например).
Но, сотрудник тех части google — Ubl, в недавней беседе упомянул структуру их индексов поиска (у них обычный индекс текста по словам, такой же в принципе, как создает любая БД), и сказал, что помимо самих индексов у них есть индексы — индексов, и указатели индексов — индексов.
Вот это и интересно. Это решает, как я понимаю, проблему с нагрузкой при полнотекстовом поиске, но как это реализовано у них, пока представить не могу в полной мере.
Это увеличит нагрузку на CPU на 30% в среднем.
А не встречали, почему?
Вот хабр сейчас использует для поиска похожих статей метки, был-ли раньше полнотекстовый поиск для этого на хабре? (по идее был). Поиск в поле поиска на хабре — что использует? (сфинкс, или другой поиск, который как-то индексирует тексты и затем использует что? — правильно всё те же полнотекстовые индексы).
И это пример с низкой скоростью добавления данных.
А взять риа например — новости каждые 20-30 секунд в БД, и поиск похожих новостей перед добавлением, за год например — как ищутся?
Оптимизация запроса это конечно хорошо, но она имеет смысл только тогда, когда есть оптимальная конструкция самой БД и таблиц.
А вот как решить задачу оптимизации, например, если нужно делать запросы к FULLTEXT индексу в постоянно нарастающей по объему таблице (и отсечь данные нельзя ни под дате, ни как-либо еще — всегда нужно делать запрос ко всем текстовым данным в таблице, которые каждый день прирастают по сотне тысяч строк текста).
Любой такой запрос подбрасывает расход CPU в 100% пока запрос не получит результат.
Вот это задача номер раз!
У меня последний FireFox просто не открывает через указанный автором DNS ни один https сайт, с сообщением — Издатель не может быть проверен.
То, есть блок сразу за MitM.
Все ткущие попытки бана по IP — профанация.
Они все идут (и автор в их числе) по стопам лажи движка DLE.
Я неделями не мог войти в админку DLE из-за банов IP, потому, что в моей стране на 5 миллионов пользователей в сети — 50 NAT IP, всего на всю страну.
И сайты то мои на DLE не слишком и популярны были, но постоянно кто-то из моей страны пробовал войти в акк админа и IP улетал в бан, а я не мог потом войти из-за этого.
У автора сейчас будет та же проблема — я не смогу войти в свой акк, потому, что мой IP всегда будет в бане. Всегда найдется пару из 500 000 человек на моем IP, кто ломанется в мой акк и забанит этот IP.
Начинание хорошее, но еще долго придется идти к хорошей версии конечного продукта.
Технические ошибки (в переводе откуда-то появляются: точки, запятые с пробелами лишние), не верное оформление текста - путь еще длинен и суров, но идея сама имеет место быть. Поддерживаю вас - сил и успехов.
Как архивы, заверенная нотариусом дата публикации и прочее, повлияют на сайт абузера, который выставит дату публикации более раннюю? И его сайт не индексируется ни гуглом ни архивом - а страница для проверки есть, и дата там меньше, чем у вас - вы вор? Чем докажете?
Вот сейчас не понял? Что субъектвно у вас ан графике со шкалами и цифрами? Вы цифры шкал не видите? Или субъективно их воспринимаете?
"отклонений прогноза от реальных данных "
Задание то для работы расписания CRON в панелях управления сервером.
Видимо aPanel решили нанять кодера и все-таки напсиать нормальную работу крона, после того, как я им указал, что их "добавляльщик" крона не умеет никаких интервалов временных добавлять :) Либо кто-то пишет свою панель и хочет выйти на рынок.
CRON в котором реализованы ми-секунды, реально должен кушать мало памяти, ибо слишком быстро, если очередь будет периодически "флашиться" из памяти и перезагружаться.
Автор: А вот порог расчетных гармоник по мощности, думаю надо бы еще отбирать, например, среднеквадратичным отклонением, чтобы включить не самые пиковые, а просто все, которые влияют до определенного предела на результат, а иначе, с топовыми гармониками у вас в низших точках получились слишком сильные отклонения в прогнозах, именно из-за нехватки числа гармоник в среднем ряду.
На картинке наложения графиков реальных данных и прогноза - всё видно, всё исследовано.
Я осуждаю даже тех, кто работая с типизированным языком, отключает опцию IDE, требующую явных объявлений и типизации.
Преобразование типов, замену разделителей дробной части, локальной денежной единицы, просто должно врасти в организм на уровне инстинктов. И выбирать мертвый язык вместо развивающегося, именно из-за своей проблемы, а не проблемы языка — это моветон.
В любом случае спасибо за напутствие, буду пробовать.
Вот сейчас откатываю разные размеры партиций и отдельных таблиц, а не партиций и вместо одного — 5-20 запросов, если процент выигрыша будет существенный, это будет очередной костыль, пока не будет найдено протестировано более быстрое и незатратное решение.
Пробую и файловые операции использовать на регэкспах, вместо полнотекста в БД, посмотрим, понюхаем.
горломмощностью, а не оптимизированностью?Нет, чем больше и круче компания, тем серьезнее и интереснее стараются подойти к оптимизации.
Мои вот движки держат легко 120-200 тыс посетителей в стуки даже на одно-двух процессорных вдс за доллар, при этом, обновление данных каждые 20-40 секунд.
И именно потому, что я очень жестко подхожу к борьбе за каждый байт и процессорную операцию при разработке, это уже как азарт просто, само-собой разумеющийся.
Сейчас вот как раз озадачаен решением выше-озвученной задачи для вдс на 2-3 CPU ядра средней линейки.
Всё на одном сервере, и внешний поисковый двиг только добавит нагрузку.
Поиск по меткам — как пример, что сейчас есть по меткам, а дальше предположение, что был полнотекст на хабре вначале пути.
«Поиск „похожих новостей“ и полнотекстовый поиск — это две большие разницы» нет, никакие метки вам не дадут гарантии похожести, полнотекст лидирует, либо человек должен проверять глазами выборку после меток.
Полнотекст обязателен для вывода похожих новостей в релевантном поиске (как у гулга например).
Но, сотрудник тех части google — Ubl, в недавней беседе упомянул структуру их индексов поиска (у них обычный индекс текста по словам, такой же в принципе, как создает любая БД), и сказал, что помимо самих индексов у них есть индексы — индексов, и указатели индексов — индексов.
Вот это и интересно. Это решает, как я понимаю, проблему с нагрузкой при полнотекстовом поиске, но как это реализовано у них, пока представить не могу в полной мере.
А не встречали, почему?
Вот хабр сейчас использует для поиска похожих статей метки, был-ли раньше полнотекстовый поиск для этого на хабре? (по идее был). Поиск в поле поиска на хабре — что использует? (сфинкс, или другой поиск, который как-то индексирует тексты и затем использует что? — правильно всё те же полнотекстовые индексы).
И это пример с низкой скоростью добавления данных.
А взять риа например — новости каждые 20-30 секунд в БД, и поиск похожих новостей перед добавлением, за год например — как ищутся?
А вот как решить задачу оптимизации, например, если нужно делать запросы к FULLTEXT индексу в постоянно нарастающей по объему таблице (и отсечь данные нельзя ни под дате, ни как-либо еще — всегда нужно делать запрос ко всем текстовым данным в таблице, которые каждый день прирастают по сотне тысяч строк текста).
Любой такой запрос подбрасывает расход CPU в 100% пока запрос не получит результат.
Вот это задача номер раз!
То, есть блок сразу за MitM.
Они все идут (и автор в их числе) по стопам лажи движка DLE.
Я неделями не мог войти в админку DLE из-за банов IP, потому, что в моей стране на 5 миллионов пользователей в сети — 50 NAT IP, всего на всю страну.
И сайты то мои на DLE не слишком и популярны были, но постоянно кто-то из моей страны пробовал войти в акк админа и IP улетал в бан, а я не мог потом войти из-за этого.
У автора сейчас будет та же проблема — я не смогу войти в свой акк, потому, что мой IP всегда будет в бане. Всегда найдется пару из 500 000 человек на моем IP, кто ломанется в мой акк и забанит этот IP.
Да, лажанул автор со своим eTag :)