И оперативную память в том числе сдавал много раз. Старый комп после чистки не включался - я грешил на ОЗУ. Взял в днс сразу несколько комплектов чтобы проверить, ни с одним не запустился, значит проблема не в памяти была - пошел вернул «не подошла», без проблем вернули деньги
можно, и неоднократно менял в том же днс. Даже не из-за «ненадлежащего качества», а просто потому что «не подошел». Сам покупал плату и не увидел что второй разъем pci-e очень близко расположен к первому, и поэтому не влезала аудиокарта. Пошел сдал - деньги вернули. Если же в товаре какой-то заводской дефект, то уж тем более вернут.
Доводилось сталкиваться с обратным эйджизмом - не брали на работу, так как "слишком молодой" для такой зарплаты/должности/ответственности (нужное подчеркнуть), "ты ещё в универе учишься".
С 17 лет коммерческой разработкой занимаюсь, поэтому к 19-20 годам уже было 2+ года релевантного опыта, претендовал на позиции Strong Junior с зарплатой около 2k$ на тот момент, хотя по сути ещё учился в университете на 2м курсе.
Приходилось или скрывать возраст или слышать в голосе HR явные дилеммы "брать нельзя пропустить"
Потому что сегодня "более, чем адекватная" это 9к за 2 года, а завтра пост выстрелит на целевую аудиторию и придёт множество клиентов, которым можно сказать "более, чем адекватная" это мы имели в виду 14к за 2 года.
3. Используйте динамическое семплирование. Чем больший промежуток смотрите, тем меньше данных читаете.
создаём колонку sample типа UInt16 и используем её в ключе сортировки;
заполняем случайными значениями в диапазоне от 0 до 99.
В каждом запросе ограничиваем sample пропорционально количеству прочитанных дней
Таким образом, при чтении данных за 2 дня мы прочитаем случайную половину от всего объёма, при чтении 10 дней прочитаем 1/10 и так далее.
Очень интересное решение, в своём проекте приходилось обрабатывать случай, когда в табличке хранится большой объём записей о трафике клиентов с точностью до миллисекунд, а клиент хочет посмотреть график за день/неделю/месяц или даже больше, поэтому идёт чтение большого куска данных.
Думали над таким же решением, но у нас оно практически постоянно давало неточность измерений для частных случаев:
Если за последний день основные всплески трафика записались с sample от 50 до 100. График "за день" их покажет, а вот "за последние 3 дня" их проигнорирует, т.к. where sample <= 100/days возьмёт лишь треть трафика и в итоге выведет число, которое может отличаться от реального (или от того числа, которое выводится на графике "за день") более чем на 20%, что может быть критично.
Если трафик неравномерный или импульсивный, например за день для конкретного клиента набегает всего 1к строк примерно равным количеством записей каждый час, то игнорировать половину из них, при запросе "за последние 2 дня" это примерно равно "заменить половину записей нулями".
Понятное дело что эту ошибку можно уменьшить если поиграться с диапазоном для sample и условием where sample <= , но у каждого клиента может быть разное поведение трафика и подобрать "ключ ко всем" не получится, ровно как и определить количество записей до начала запроса и скорректировать запрос.
А вы не сталкивались с подобными проблемами? Или в вашем случае различия в значениях на дневном и недельном графиках не критичны?
И оперативную память в том числе сдавал много раз. Старый комп после чистки не включался - я грешил на ОЗУ. Взял в днс сразу несколько комплектов чтобы проверить, ни с одним не запустился, значит проблема не в памяти была - пошел вернул «не подошла», без проблем вернули деньги
можно, и неоднократно менял в том же днс. Даже не из-за «ненадлежащего качества», а просто потому что «не подошел». Сам покупал плату и не увидел что второй разъем pci-e очень близко расположен к первому, и поэтому не влезала аудиокарта. Пошел сдал - деньги вернули. Если же в товаре какой-то заводской дефект, то уж тем более вернут.
Я сначала подумал, что автор оригинала работает в рамблере :)
Доводилось сталкиваться с обратным эйджизмом - не брали на работу, так как "слишком молодой" для такой зарплаты/должности/ответственности (нужное подчеркнуть), "ты ещё в универе учишься".
С 17 лет коммерческой разработкой занимаюсь, поэтому к 19-20 годам уже было 2+ года релевантного опыта, претендовал на позиции Strong Junior с зарплатой около 2k$ на тот момент, хотя по сути ещё учился в университете на 2м курсе.
Приходилось или скрывать возраст или слышать в голосе HR явные дилеммы "брать нельзя пропустить"
Наверное, под «в виде README-файлов» автор имел в виду все же расширение .md, а не само название файла :)
Для трех репозиториев хватило бы 3 запросов в минуту. Почему вас остановили 83 запроса в минуту, которые гитхаб позволяет делать?
Потому что сегодня "более, чем адекватная" это 9к за 2 года, а завтра пост выстрелит на целевую аудиторию и придёт множество клиентов, которым можно сказать "более, чем адекватная" это мы имели в виду 14к за 2 года.
Очень интересное решение, в своём проекте приходилось обрабатывать случай, когда в табличке хранится большой объём записей о трафике клиентов с точностью до миллисекунд, а клиент хочет посмотреть график за день/неделю/месяц или даже больше, поэтому идёт чтение большого куска данных.
Думали над таким же решением, но у нас оно практически постоянно давало неточность измерений для частных случаев:
Если за последний день основные всплески трафика записались с
sampleот 50 до 100. График "за день" их покажет, а вот "за последние 3 дня" их проигнорирует, т.к.where sample <= 100/daysвозьмёт лишь треть трафика и в итоге выведет число, которое может отличаться от реального (или от того числа, которое выводится на графике "за день") более чем на 20%, что может быть критично.Если трафик неравномерный или импульсивный, например за день для конкретного клиента набегает всего 1к строк примерно равным количеством записей каждый час, то игнорировать половину из них, при запросе "за последние 2 дня" это примерно равно "заменить половину записей нулями".
Понятное дело что эту ошибку можно уменьшить если поиграться с диапазоном для
sampleи условиемwhere sample <=, но у каждого клиента может быть разное поведение трафика и подобрать "ключ ко всем" не получится, ровно как и определить количество записей до начала запроса и скорректировать запрос.А вы не сталкивались с подобными проблемами? Или в вашем случае различия в значениях на дневном и недельном графиках не критичны?
Увидел рейтинг -7, спустился в комменты, а тут почему-то пусто?
Через А
Тоже об этом задумался когда переводил. Но это Егор Бугаенко) Его мнение почти никогда не совпадает с мнением комьюнити)
Хотел отправить, но ты опередил меня) Спасибо
Норм база