Очень круто, когда в стране появляются новые производства. Арктика сейчас осваивается активно, надеюсь власти обратят внимание на вашу продукцию.
По поводу плавучести дилетантский совет - по типу спасательный круг можно попробовать на борт крепить надувные «блоки», места мало занимает а водоизмещение и площадь добавит.
"Вознаграждение за продажу" 1042 / 4550 = 22%. Я же брал минимальные цифры для категорий Декор - 16%, максимально там 20%. Что тут нереального? Умножьте свои цифры на 100, чтоб соответствовать плюс-минус цифрам из статьи. Еще и возвраты кстати оплачиваете, это не учтено, статистики нет)
Попробовал воссоздать математику, исходя из опубликованных цифр: Общий доход 545304, комиссия площадки 87248 (16%), 94300 стоимость доставки (условно по 100 рублей за единицу товара), 27265 комиссия агентству (5% от роста дохода), 32718 налог с оборота 6%, 54430 реклама (ДРР 10%), 249241 рублей доход предпринимателя после уплаты "расходов на транзакцию", что составило 45% от изначальной цифры в 545304 руб. У рекламных агентств очень все просто, вот доход, вот ДРР - красиво же)
Моралисты, белые и пушистые… живут в какой-то параллельной вселенной что-ли... Просто пора уже очнуться!
А кто-то в курсе про Boston Dynamycs? Роботов уже создают, и во-первых для военных целей. И лучшая защита от того, чтоб нам, как и Японии (по приколу!) в свое время не прилетела парочка подросших Малышей - иметь своих Крепышей.
Есть поговорка, хочешь мира, готовься к войне. Чем мощнее оружие, тем больше мотивация решать все вопросы Без оружия!
При оптимизации запросов важно учитывать объемы данных, ведь от размера таблиц оптимизатор может выбрать разные сценарии, о чем было сказано в статье.
На больших таблицах поведение может измениться от разных значений фильтров. Из-за разной статистики (распределения значений).
Для OLAP нагрузок уже гораздо проще перейти на колоночные базы и индексы, работают быстро и без заморочек.
Для OLTP нагрузок надо измерять наносеки, нормализацию базы проводить. И еще у индексов есть стоимость обслуживания, которая добавляет свои наносеки.
В своей практике я пришел к простому выводу, все сложные запросы должны выбирать как можно меньше данных на каждом этапе. Иной раз лишний JOIN может увеличить время выполнения запроса в сотни раз (таблицы с миллионами записей).
Также не упоминается о временных таблицах. Если запрос «никак не хочет» выполняться быстро, можно его раскидать во временные таблицы, речь про OLAP нагрузку разумеется.
Вся эта тема с оптимизацией SQL дико долгая, чтоб я мог еще что-то добавить)
Вопросы с целью определить выгоды, что-то вроде «Что станет лучше?», «Что мы получим от этого?» и любые другие интерпретации гораздо понятнее и более коммуникабельные. А из-за таких зачемканий можно лишиться работы (заказчиков) или заработать славу глупого и занудного человека.
Хотя признаю, что зачемкания очень быстро избавят от надоедливых советчиков )
Atom приостановили из-за успеха VS Code. Атом создали в GitHub, а GitHub купила Microsoft. Разрабы ушли с проекта после сделки. Ничего нового не происходит, крупные компании выкупают мелкие успешные проекты, каким и был Atom в то время, чтоб забрать рынок себе. https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
Обиделся чтоли?) Давай еще один минус, может легче станет.
Кластеризованный ключ не надо пихать в некластеризованный индекс.
Создал 1 индекс вместо 2 (1 лучше чем 2 в этом случае) по 1 колонке IsValidated. И предложенные индексы без фильтрации. Итог - тот же вложенный цикл с Key Lookup. И IO Cost сравнимый с "улучшенной версией", примерно 0.34.
А после создания рекомендованного индекса (добавляем в индекс 1 бит, прикол), IO Cost становится 0.003. От исходного варианта, Вашего, разница примерно в 1100 раз. Занавес. С наступающим)
Касаемо MS SQL, потестил на своем маке (докер + Azure Data Studio)
Пересоздал индексы правильно (без включения ID в некластеризованный индекс), сделал замеры... И создал 1 индекс по колонкам Sessionid, Val, IsValidated без фильтров.
Clustered Index Scan заменился на Index Seek.
Было Est. CPU Cost 0.220031 + 0.220031, Act. CPU Cost 28, Est. IO Cost 3.30979
Стало Est. CPU Cost 0.220157, Act. CPU Cost 22, Est. IO Cost 0.351273.
Также, количество выполнений снизилось с 11 до 1. IO Cost снизилось более чем в 9 раз!
Выводы:
Индексы надо создавать правильно
В некластеризованный индекс не нужно пихать колонку кластеризованного индекса, она там уже есть
Не натягивать сову на глобус (покрывающие индексы для общих примеров)
Кластеризованный индекс - B+ дерево, он будет выбираться по-умолчанию, если нет более точных индексов для конкретных запросов. Можете поиграться с Plan Explorer, чтоб проверить это.
Не знаю как у других, в Майкрософт рекомендуют табличные модели (колоночная структура) использовать, как основную модель данных. А кластеризованный колоночный индекс в MS SQL появился в 2016 SP1.
Мой компик приехал, добрался до разборки. По итогу: радиатор похож на медный, 2 тепловые трубки. Фото внутрянки https://disk.yandex.ru/d/026G6UfyxcEQrw. Пасту заменил на "Термоправильную" 8й модели, в простое температура снизилась на 2-3 градуса, под нагрузкой не тестил, думаю разница будет заметнее. Также, можно отключить турбо режим (очень дико греет), утилиткой QuickCPU.
Очень круто, когда в стране появляются новые производства. Арктика сейчас осваивается активно, надеюсь власти обратят внимание на вашу продукцию.
По поводу плавучести дилетантский совет - по типу спасательный круг можно попробовать на борт крепить надувные «блоки», места мало занимает а водоизмещение и площадь добавит.
Надо для начала сказать, что макбук это мобильное устройство. И этим же закончить. Выбирайте технику по своему сценарию использования.
Не заметно, чтоб крипта "перевернула жизнь". А вот влияние нейросетей все больше и больше заметно, и они везде, где это возможно.
"Вознаграждение за продажу" 1042 / 4550 = 22%. Я же брал минимальные цифры для категорий Декор - 16%, максимально там 20%. Что тут нереального? Умножьте свои цифры на 100, чтоб соответствовать плюс-минус цифрам из статьи. Еще и возвраты кстати оплачиваете, это не учтено, статистики нет)
Попробовал воссоздать математику, исходя из опубликованных цифр:
Общий доход 545304, комиссия площадки 87248 (16%), 94300 стоимость доставки (условно по 100 рублей за единицу товара), 27265 комиссия агентству (5% от роста дохода), 32718 налог с оборота 6%, 54430 реклама (ДРР 10%), 249241 рублей доход предпринимателя после уплаты "расходов на транзакцию", что составило 45% от изначальной цифры в 545304 руб. У рекламных агентств очень все просто, вот доход, вот ДРР - красиво же)
Сделайте группировку до Джойна. Интересно даже какой будет тайминг в первом запросе, но правильном (СТЕ или подзапрос)
Сначала кучу менеджеров) до сеньоров может и не дойдет дело!)
Интересно, что предлагается делать с vpn подключениями к своей личной сети, в случае блокировок целых протоколов…
Моралисты, белые и пушистые… живут в какой-то параллельной вселенной что-ли... Просто пора уже очнуться!
А кто-то в курсе про Boston Dynamycs? Роботов уже создают, и во-первых для военных целей. И лучшая защита от того, чтоб нам, как и Японии (по приколу!) в свое время не прилетела парочка подросших Малышей - иметь своих Крепышей.
Есть поговорка, хочешь мира, готовься к войне. Чем мощнее оружие, тем больше мотивация решать все вопросы Без оружия!
При оптимизации запросов важно учитывать объемы данных, ведь от размера таблиц оптимизатор может выбрать разные сценарии, о чем было сказано в статье.
На больших таблицах поведение может измениться от разных значений фильтров. Из-за разной статистики (распределения значений).
Для OLAP нагрузок уже гораздо проще перейти на колоночные базы и индексы, работают быстро и без заморочек.
Для OLTP нагрузок надо измерять наносеки, нормализацию базы проводить. И еще у индексов есть стоимость обслуживания, которая добавляет свои наносеки.
В своей практике я пришел к простому выводу, все сложные запросы должны выбирать как можно меньше данных на каждом этапе. Иной раз лишний JOIN может увеличить время выполнения запроса в сотни раз (таблицы с миллионами записей).
Также не упоминается о временных таблицах. Если запрос «никак не хочет» выполняться быстро, можно его раскидать во временные таблицы, речь про OLAP нагрузку разумеется.
Вся эта тема с оптимизацией SQL дико долгая, чтоб я мог еще что-то добавить)
Вопросы с целью определить выгоды, что-то вроде «Что станет лучше?», «Что мы получим от этого?» и любые другие интерпретации гораздо понятнее и более коммуникабельные. А из-за таких зачемканий можно лишиться работы (заказчиков) или заработать славу глупого и занудного человека.
Хотя признаю, что зачемкания очень быстро избавят от надоедливых советчиков )
Atom приостановили из-за успеха VS Code. Атом создали в GitHub, а GitHub купила Microsoft. Разрабы ушли с проекта после сделки. Ничего нового не происходит, крупные компании выкупают мелкие успешные проекты, каким и был Atom в то время, чтоб забрать рынок себе. https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
Обиделся чтоли?) Давай еще один минус, может легче станет.
Кластеризованный ключ не надо пихать в некластеризованный индекс.
Создал 1 индекс вместо 2 (1 лучше чем 2 в этом случае) по 1 колонке IsValidated. И предложенные индексы без фильтрации. Итог - тот же вложенный цикл с Key Lookup. И IO Cost сравнимый с "улучшенной версией", примерно 0.34.
А после создания рекомендованного индекса (добавляем в индекс 1 бит, прикол), IO Cost становится 0.003. От исходного варианта, Вашего, разница примерно в 1100 раз. Занавес. С наступающим)
Касаемо MS SQL, потестил на своем маке (докер + Azure Data Studio)
Пересоздал индексы правильно (без включения ID в некластеризованный индекс), сделал замеры... И создал 1 индекс по колонкам Sessionid, Val, IsValidated без фильтров.
Clustered Index Scan заменился на Index Seek.
Было Est. CPU Cost 0.220031 + 0.220031, Act. CPU Cost 28, Est. IO Cost 3.30979
Стало Est. CPU Cost 0.220157, Act. CPU Cost 22, Est. IO Cost 0.351273.
Также, количество выполнений снизилось с 11 до 1. IO Cost снизилось более чем в 9 раз!
Выводы:
Индексы надо создавать правильно
В некластеризованный индекс не нужно пихать колонку кластеризованного индекса, она там уже есть
Не натягивать сову на глобус (покрывающие индексы для общих примеров)
Кластеризованный индекс - B+ дерево, он будет выбираться по-умолчанию, если нет более точных индексов для конкретных запросов. Можете поиграться с Plan Explorer, чтоб проверить это.
Статья будто студент для ВУЗа писал.
Не знаю как у других, в Майкрософт рекомендуют табличные модели (колоночная структура) использовать, как основную модель данных. А кластеризованный колоночный индекс в MS SQL появился в 2016 SP1.
Мой компик приехал, добрался до разборки. По итогу: радиатор похож на медный, 2 тепловые трубки. Фото внутрянки https://disk.yandex.ru/d/026G6UfyxcEQrw. Пасту заменил на "Термоправильную" 8й модели, в простое температура снизилась на 2-3 градуса, под нагрузкой не тестил, думаю разница будет заметнее. Также, можно отключить турбо режим (очень дико греет), утилиткой QuickCPU.
Наверняка там и дешевый термоинтерфейс (паста) намазан. Никто не пробовал менять?
Заказал себе такой же, приедет поэкспериментирую)
2020 год, давайте изобретём CMS и MVC заново)