Pull to refresh
0
Karma
0
Rating
  • Followers
  • Following

Спектральный анализ временных рядов с помощью python

Вот сейчас не понял? Что субъектвно у вас ан графике со шкалами и цифрами? Вы цифры шкал не видите? Или субъективно их воспринимаете?

Спектральный анализ временных рядов с помощью python

"отклонений прогноза от реальных данных "

История одного фееричного провала тестового задания на C#

Задание то для работы расписания CRON в панелях управления сервером.

Видимо aPanel решили нанять кодера и все-таки напсиать нормальную работу крона, после того, как я им указал, что их "добавляльщик" крона не умеет никаких интервалов временных добавлять :) Либо кто-то пишет свою панель и хочет выйти на рынок.

CRON в котором реализованы ми-секунды, реально должен кушать мало памяти, ибо слишком быстро, если очередь будет периодически "флашиться" из памяти и перезагружаться.

Спектральный анализ временных рядов с помощью python

Автор: А вот порог расчетных гармоник по мощности, думаю надо бы еще отбирать, например, среднеквадратичным отклонением, чтобы включить не самые пиковые, а просто все, которые влияют до определенного предела на результат, а иначе, с топовыми гармониками у вас в низших точках получились слишком сильные отклонения в прогнозах, именно из-за нехватки числа гармоник в среднем ряду.

Спектральный анализ временных рядов с помощью python

На картинке наложения графиков реальных данных и прогноза - всё видно, всё исследовано.

Рассказ о том, почему в 2021 году лучше выбирать TypeScript, а не JavaScript

Нечего делать в большом проекте тому, кто даже не работал с типизированными языкми и не принял за привычку объявлять переменые и принудительно подтверждать типы.
Я осуждаю даже тех, кто работая с типизированным языком, отключает опцию IDE, требующую явных объявлений и типизации.

Преобразование типов, замену разделителей дробной части, локальной денежной единицы, просто должно врасти в организм на уровне инстинктов. И выбирать мертвый язык вместо развивающегося, именно из-за своей проблемы, а не проблемы языка — это моветон.

Читаем EXPLAIN на максималках

Не, в партициях ровно просто разделить и делать много запросов, по однму в каждую партицию, узнать разницу между кодом работы партиций и кодом работы с разными таблицами, чтобы увидеть где быстрее.
В любом случае спасибо за напутствие, буду пробовать.

Читаем EXPLAIN на максималках

Да решений для тестов много, нужно просто правильно подобрать размеры и веса решений.

Вот сейчас откатываю разные размеры партиций и отдельных таблиц, а не партиций и вместо одного — 5-20 запросов, если процент выигрыша будет существенный, это будет очередной костыль, пока не будет найдено протестировано более быстрое и незатратное решение.

Пробую и файловые операции использовать на регэкспах, вместо полнотекста в БД, посмотрим, понюхаем.

Читаем EXPLAIN на максималках

А вы считает, что раз гул и риа то должны кидать деньги налево и направо и брать горлом мощностью, а не оптимизированностью?
Нет, чем больше и круче компания, тем серьезнее и интереснее стараются подойти к оптимизации.

Мои вот движки держат легко 120-200 тыс посетителей в стуки даже на одно-двух процессорных вдс за доллар, при этом, обновление данных каждые 20-40 секунд.
И именно потому, что я очень жестко подхожу к борьбе за каждый байт и процессорную операцию при разработке, это уже как азарт просто, само-собой разумеющийся.

Сейчас вот как раз озадачаен решением выше-озвученной задачи для вдс на 2-3 CPU ядра средней линейки.

Читаем EXPLAIN на максималках

Нет, не разнесем — может сразу ДЦ купим ради десятка миллионов запсией?
Всё на одном сервере, и внешний поисковый двиг только добавит нагрузку.

Поиск по меткам — как пример, что сейчас есть по меткам, а дальше предположение, что был полнотекст на хабре вначале пути.

«Поиск „похожих новостей“ и полнотекстовый поиск — это две большие разницы» нет, никакие метки вам не дадут гарантии похожести, полнотекст лидирует, либо человек должен проверять глазами выборку после меток.

Полнотекст обязателен для вывода похожих новостей в релевантном поиске (как у гулга например).

Но, сотрудник тех части google — Ubl, в недавней беседе упомянул структуру их индексов поиска (у них обычный индекс текста по словам, такой же в принципе, как создает любая БД), и сказал, что помимо самих индексов у них есть индексы — индексов, и указатели индексов — индексов.
Вот это и интересно. Это решает, как я понимаю, проблему с нагрузкой при полнотекстовом поиске, но как это реализовано у них, пока представить не могу в полной мере.

Читаем EXPLAIN на максималках

Это увеличит нагрузку на CPU на 30% в среднем.
А не встречали, почему?
Вот хабр сейчас использует для поиска похожих статей метки, был-ли раньше полнотекстовый поиск для этого на хабре? (по идее был). Поиск в поле поиска на хабре — что использует? (сфинкс, или другой поиск, который как-то индексирует тексты и затем использует что? — правильно всё те же полнотекстовые индексы).
И это пример с низкой скоростью добавления данных.

А взять риа например — новости каждые 20-30 секунд в БД, и поиск похожих новостей перед добавлением, за год например — как ищутся?

Читаем EXPLAIN на максималках

Оптимизация запроса это конечно хорошо, но она имеет смысл только тогда, когда есть оптимальная конструкция самой БД и таблиц.

А вот как решить задачу оптимизации, например, если нужно делать запросы к FULLTEXT индексу в постоянно нарастающей по объему таблице (и отсечь данные нельзя ни под дате, ни как-либо еще — всегда нужно делать запрос ко всем текстовым данным в таблице, которые каждый день прирастают по сотне тысяч строк текста).

Любой такой запрос подбрасывает расход CPU в 100% пока запрос не получит результат.
Вот это задача номер раз!

Кабысдох – DoH-припарка от русского firewall

Да нет особого смысла в этом. Завернуть запросы на ВПН, или на crypt днс, все-таки надежнее.

Кабысдох – DoH-припарка от русского firewall

У меня последний FireFox просто не открывает через указанный автором DNS ни один https сайт, с сообщением — Издатель не может быть проверен.
То, есть блок сразу за MitM.

Как мы в RUVDS спасаем наших пользователей от брутфорса

Все ткущие попытки бана по IP — профанация.
Они все идут (и автор в их числе) по стопам лажи движка DLE.
Я неделями не мог войти в админку DLE из-за банов IP, потому, что в моей стране на 5 миллионов пользователей в сети — 50 NAT IP, всего на всю страну.

И сайты то мои на DLE не слишком и популярны были, но постоянно кто-то из моей страны пробовал войти в акк админа и IP улетал в бан, а я не мог потом войти из-за этого.

У автора сейчас будет та же проблема — я не смогу войти в свой акк, потому, что мой IP всегда будет в бане. Всегда найдется пару из 500 000 человек на моем IP, кто ломанется в мой акк и забанит этот IP.

Своими руками: Компьютер в столе с жидкостным охлаждением

Так там, я так понял, стекло переменной прозрачности, оно полстола стоит по деньгам.

Нет Cookies, нет проблем — использование ETag для отслеживания пользователей

Тоже :)
Да, лажанул автор со своим eTag :)

Нет Cookies, нет проблем — использование ETag для отслеживания пользователей

Нет — закрыл/открыл браузер — ид разные. (последняя версия Mozilla FireFox)

Сборка 486 — выбор комплектующих

Эх, да — респект за начинание.
Я до сих пор держу 386 для Kings Bounty и Pentium I для WarLords.
Правда я без корпусов и прочей ненужной периферии храню, но раз в год точно запускаю чтобы поиграть в эти шедевры в оригинале :)

Escobar Fold 2 – скам продолжается

Тоже на волне хайпа заказал через посредника-склад в США от имени знаменитости одной — продали. Пока жду, едет сейчас со склада в РФ. От своего имени и от РФ гражданина даже не стал пробовать, видимо шансов ноль.

Information

Rating
Does not participate
Registered
Activity