Все правильно, но зачем три раза по 5 параграфов с примерами рассказывать то, что и так понятно. Возраст и пробег автомобиля коррелируют, но не всегда. Может быть такси, а может быть дачник. Нужно всегда смотреть конкретный экземпляр. Все. Дальше - про ИИ.
В доме хорошо бы разводить пятипроводную систему, с тремя классами нагрузки: 1. высокоприоритетная слаботочная (свет, охрана, компьютерная/аудио/видеотехника) - подключена бесперебойно; 2. бытовая и кухонная техника (может подключаться через токовые реле взаимных приоритетов внутри группы в условиях ограничения по мощности (питание от инвертора), или без него (питание от сети); 3. инерционная нагревательная техника (бойлер и отопление) - всегда отключена при питании от инвертора, и отключается через реле приоритета при питании от сети при потреблении выше порога из группы 2 (например, включен чайник + стиралка => отключаем бойлер).
Здесь лучшая по охвату нашего прошлого мира (который, как известно, определяет настоящее) песня Высоцкого цитируется. Одно это стоит 10 частотомеров, даже на штатных АЛС. А в соседнем треде - меченый гвоздь, который 30 лет назад был просто удачной метафорой..
Если бы из баз только читали, то подход был бы годным. Чем выше отношение W / (R+W) - тем больше погрешность метода. При достаточно высоком отношении влияние затрат на ожидание/постановку/снятие эксклюзивных блокировок будет порядково выше, чем затрат на операции поиска/выборки. Аналог - модель идеального газа в термодинамике и нелинейного после определенных концентраций молекул - когда влияние их друг на друга начинают существенно искажать простую теорию. Другой аналог - зависимые или независимые случайные величины. Начиная с какой-то величины созависимости пренебрежение ей делает независимую модель практически неработоспособной.
Соответственно, если проверять производительность в близких к реальным условиях - нужно работать на близких к реальным нагрузочных смесях.
Кроме этого - scan и seek в условиях параллельной активности по записи отличаются не только по O(N) vs O(logN) - scan в условиях параллельных записей практически убивает параллелизм, а seek за счет точечных блокировок позволяет системе жить при гораздо более высоких отношениях W / (R+W).
Отсюда вывод - производительность СУБД зависит не только от настройки (задача ДБА), но и от способа работы с ней (задача Дата Архитектора). Даже при наличии индексов или шард один неоптимально написанный запрос убьет перформанс сотни остальных, написанных правильно. И значит, мы можем говорить о производительности СУБД только в контексте ее связки с приложением, которое с ней работает - то есть о производительности всей [b]информационной системы[/b]
И далее - вывод, который непосредственно идет из последнего абзаца - только Дата Инженер / Дата Архитектор компетентны в оптимальной работе с БД. Значит, если построить слой, который позволит менее компетентным разработчикам работать с данными только определенными вышеуказанными фигурами способами - это будет гарантировать производительность системы. Самые надежные способы, которые нельзя обойти by design - это внутрибазное программирование - то есть SP и TVF в первую очередь. Этот способ заодно абсолютно надежно решает и проблемы разделения доступа к БД со стороны разных систем - размещением этих объектов в разных схемах. Оба этих свойства дают абсолютную гарантию того, что автомобили фуллстеков поедут строго по заранее определенным и проверенным дорогам, а не будут двигаться по территории построенного архитектором города хаотически, сталкиваясь и снося все вокруг. Ценность этой гарантии порядково выше (для тех, кто понимает эту ценность) гипотетической возможности заменить бакенд на «аналогичный», которую усиленно педалируют адепты CRUD- и code-first подходов.
Да, это удобная штука для всяких бухгалтерских «нарастающих итогов» - до ее появления приходилось имитировать все это CTE или джойнами с самим собой с открытыми условиями вида ..on a < b, что явно не являлось ни быстрым, ни прозрачным.
Я бы сказал больше - даже в ERP, спроектированных полностью изолированно-абстрактно по слоям, с полной примитивизацией возможностей СУБД до CRUD, замена RDBMS - это авантюра с недетерминированным исходом - то есть на деле все эти задекларированные преимущества (привинтим двигатель от Мерседеса к коробке БМВ) не работают, или требуют (зачастую неочевидной и кропотливой) доработки - особенно, если мы хотим получить от информационной системы гарантированно высокую отдачу.
Смотрите на Природу - она использует все частные возможности биологических созданий для внутривидовой и межвидовой борьбы. Наследование - только ссылка назад, но никак не ограничитель движения вперед :)
А что будет, если у вас, например таймеры-счетчики в одном кристалле 16-разрядные, а в другом - 8? И prescaler где-то есть, где-то - нет? Это я к тому, что универсальная абстракция либо имеет свойства наихудшей имплементации, либо сложность, равную наименьшему общему кратному свойств покрываемых имплементаций.
Количество семплов много больше размерности вектора признаков. Можно решать любым способом - хоть статистически, хоть ML-классификаторами
Статистически проще крутить куб любым способом, и смотреть вот это - водитель-аутлаер на средней машине, или машина-аутлаер. ML придется точить заранее на каждый из случаев.
И кеш, кстати, можно периодически чистить по мере того, как растет K - скажем, раз в 100000 чисел проходить по нему и удалять все, что меньше K. Он тогда и переполняться не будет скорее всего.
Это зависит от развития последовательности с какого-то числа - если тех, что быстро уходят вниз, много, то да. Но нет гарантии, что последовательность не будет долго болтаться где-то между K и K*3, и я бы делал так - если число меньше К - то сразу перезапускать, иначе проверить в хэш-таблице. Если там нет - сделать следующее действие. То есть меньшие числа - перезапуск, большие - кэш.
Пусть летает на электрическом самолете. А вообще большинство вопросов в компании можно решать в режиме онлайн-конференций, так что расчехлять джет понадобится не очень часто.
Так это без разницы. Храните по ключу null в качестве полезной нагрузки - это будет съедать явно меньше памяти, чем вся цепочка. Смысл моей идеи в том, чтобы опираться только на факт того, что встреченное число приводит последовательность после него к 1, и по завершению расчета проитерироваться по этим найденным фактам. Вот я и спрашиваю, какое отношение верхней границы к количеству известных цепочек, и главное, как меняется эта пропорция с увеличением N? Если она сублинейна - то дело выгодное :)
Это доказывает, что проблема не в технике, а в самом принципе непреложности исполнения воли пахана. То, каким способом вы можете его обхитрить - не имеет значения, никто в этих способах не будет разбираться - просто накажут за сам факт или попытку ослушания, может быть даже показательно, чтобы другим не повадно было.
А какое примерно отношение максимального числа к количеству ключей в кэше? Может проще иметь хеш-таблицу ключей, которые на предыдущем шаге привели к 1? Тогда храниться все будет в разы компактнее => больше ключей поместится в память, => можно будет быстрее исследовать больший диапазон. А после того, как мы достигли верхней границы, пробегаемся по ключам и считаем уже для них последовательности сведения к 1 (здесь можно и с кешированием полных путей) - то есть такая двухступенчатая ракета ;)
Система фрактальна. По поведению маленького начальника можно догадаться, что и каким способом делает с ним вышестоящий. Те же портреты, методы, цели и средства, и та же [корпоративная] религия.
Мой опыт говорит, что основа безопасности - качество построения в голове модели развития дорожной ситуации. Это самое сложное в процессе езды. Я за рулем с 92 года, наездил тысяч 600 километров по РФ, Европе и Азии. Помимо общих паттернов и флагов-варнингов, на которые нужно обращать внимание (велосипедисты - да, один из них), есть и национальные особенности, и даже особенности вождения в разных городах (РФ). И все вокруг - пешие, конные, вело-, мото-, пьяные и трезвые, лисы, кабаны и лоси (не дай Бг) на дорогах - это входные переменные нашей статмодели. Она от этого пухнет, и голова болит - но если какую-то переменную не учитывать - рано или поздно ваша модель даст false positive - и если второй участник (если он не столб) тоже сделает fail - то это будет фатально.
Это не относится к тем, кто не видит велосипедистов, и вообще всех, кого считает ниже себя, специально. За инциденты, произошедшие в этой связи, нужно наказывать, как за умышленные действия. Наступила смерть - умышленное убийство. В РФ таких классификаций нет - даже за доказанные видео подставы «учителей» все равно считается, что чел «не имел умысла на причинения смерти» - и поэтому - «.. по неосторожности». Вот это самый адъ.
Все правильно, но зачем три раза по 5 параграфов с примерами рассказывать то, что и так понятно. Возраст и пробег автомобиля коррелируют, но не всегда. Может быть такси, а может быть дачник. Нужно всегда смотреть конкретный экземпляр. Все. Дальше - про ИИ.
В доме хорошо бы разводить пятипроводную систему, с тремя классами нагрузки: 1. высокоприоритетная слаботочная (свет, охрана, компьютерная/аудио/видеотехника) - подключена бесперебойно; 2. бытовая и кухонная техника (может подключаться через токовые реле взаимных приоритетов внутри группы в условиях ограничения по мощности (питание от инвертора), или без него (питание от сети); 3. инерционная нагревательная техника (бойлер и отопление) - всегда отключена при питании от инвертора, и отключается через реле приоритета при питании от сети при потреблении выше порога из группы 2 (например, включен чайник + стиралка => отключаем бойлер).
Здесь лучшая по охвату нашего прошлого мира (который, как известно, определяет настоящее) песня Высоцкого цитируется. Одно это стоит 10 частотомеров, даже на штатных АЛС. А в соседнем треде - меченый гвоздь, который 30 лет назад был просто удачной метафорой..
Да, к сожалению, документами подтвердить не могу. Только личный опыт (. Если нужно на гербовой - можно просто игнорировать ).
Если бы из баз только читали, то подход был бы годным. Чем выше отношение W / (R+W) - тем больше погрешность метода. При достаточно высоком отношении влияние затрат на ожидание/постановку/снятие эксклюзивных блокировок будет порядково выше, чем затрат на операции поиска/выборки. Аналог - модель идеального газа в термодинамике и нелинейного после определенных концентраций молекул - когда влияние их друг на друга начинают существенно искажать простую теорию. Другой аналог - зависимые или независимые случайные величины. Начиная с какой-то величины созависимости пренебрежение ей делает независимую модель практически неработоспособной.
Соответственно, если проверять производительность в близких к реальным условиях - нужно работать на близких к реальным нагрузочных смесях.
Кроме этого - scan и seek в условиях параллельной активности по записи отличаются не только по O(N) vs O(logN) - scan в условиях параллельных записей практически убивает параллелизм, а seek за счет точечных блокировок позволяет системе жить при гораздо более высоких отношениях W / (R+W).
Отсюда вывод - производительность СУБД зависит не только от настройки (задача ДБА), но и от способа работы с ней (задача Дата Архитектора). Даже при наличии индексов или шард один неоптимально написанный запрос убьет перформанс сотни остальных, написанных правильно. И значит, мы можем говорить о производительности СУБД только в контексте ее связки с приложением, которое с ней работает - то есть о производительности всей [b]информационной системы[/b]
И далее - вывод, который непосредственно идет из последнего абзаца - только Дата Инженер / Дата Архитектор компетентны в оптимальной работе с БД. Значит, если построить слой, который позволит менее компетентным разработчикам работать с данными только определенными вышеуказанными фигурами способами - это будет гарантировать производительность системы. Самые надежные способы, которые нельзя обойти by design - это внутрибазное программирование - то есть SP и TVF в первую очередь. Этот способ заодно абсолютно надежно решает и проблемы разделения доступа к БД со стороны разных систем - размещением этих объектов в разных схемах. Оба этих свойства дают абсолютную гарантию того, что автомобили фуллстеков поедут строго по заранее определенным и проверенным дорогам, а не будут двигаться по территории построенного архитектором города хаотически, сталкиваясь и снося все вокруг. Ценность этой гарантии порядково выше (для тех, кто понимает эту ценность) гипотетической возможности заменить бакенд на «аналогичный», которую усиленно педалируют адепты CRUD- и code-first подходов.
Да, это удобная штука для всяких бухгалтерских «нарастающих итогов» - до ее появления приходилось имитировать все это CTE или джойнами с самим собой с открытыми условиями вида ..on a < b, что явно не являлось ни быстрым, ни прозрачным.
Я бы сказал больше - даже в ERP, спроектированных полностью изолированно-абстрактно по слоям, с полной примитивизацией возможностей СУБД до CRUD, замена RDBMS - это авантюра с недетерминированным исходом - то есть на деле все эти задекларированные преимущества (привинтим двигатель от Мерседеса к коробке БМВ) не работают, или требуют (зачастую неочевидной и кропотливой) доработки - особенно, если мы хотим получить от информационной системы гарантированно высокую отдачу.
Смотрите на Природу - она использует все частные возможности биологических созданий для внутривидовой и межвидовой борьбы. Наследование - только ссылка назад, но никак не ограничитель движения вперед :)
А что будет, если у вас, например таймеры-счетчики в одном кристалле 16-разрядные, а в другом - 8? И prescaler где-то есть, где-то - нет? Это я к тому, что универсальная абстракция либо имеет свойства наихудшей имплементации, либо сложность, равную наименьшему общему кратному свойств покрываемых имплементаций.
Количество семплов много больше размерности вектора признаков. Можно решать любым способом - хоть статистически, хоть ML-классификаторами
Статистически проще крутить куб любым способом, и смотреть вот это - водитель-аутлаер на средней машине, или машина-аутлаер. ML придется точить заранее на каждый из случаев.
Да, а в свободное от печати время космонавты играли в настолку на поверхности принтера - кто самый лучший водитель Хаммера!
Супер. Летать на прессованной кофейной гуще! Назад к дизельным поршневым авиамоторам на вытяжке из кофейного жома.
И кеш, кстати, можно периодически чистить по мере того, как растет K - скажем, раз в 100000 чисел проходить по нему и удалять все, что меньше K. Он тогда и переполняться не будет скорее всего.
Это зависит от развития последовательности с какого-то числа - если тех, что быстро уходят вниз, много, то да. Но нет гарантии, что последовательность не будет долго болтаться где-то между K и K*3, и я бы делал так - если число меньше К - то сразу перезапускать, иначе проверить в хэш-таблице. Если там нет - сделать следующее действие. То есть меньшие числа - перезапуск, большие - кэш.
Пусть летает на электрическом самолете. А вообще большинство вопросов в компании можно решать в режиме онлайн-конференций, так что расчехлять джет понадобится не очень часто.
Так это без разницы. Храните по ключу null в качестве полезной нагрузки - это будет съедать явно меньше памяти, чем вся цепочка. Смысл моей идеи в том, чтобы опираться только на факт того, что встреченное число приводит последовательность после него к 1, и по завершению расчета проитерироваться по этим найденным фактам. Вот я и спрашиваю, какое отношение верхней границы к количеству известных цепочек, и главное, как меняется эта пропорция с увеличением N? Если она сублинейна - то дело выгодное :)
Это доказывает, что проблема не в технике, а в самом принципе непреложности исполнения воли пахана. То, каким способом вы можете его обхитрить - не имеет значения, никто в этих способах не будет разбираться - просто накажут за сам факт или попытку ослушания, может быть даже показательно, чтобы другим не повадно было.
У четных чисел, представленных в двоичной системе, нулевой бит равен 0. Что значит проверять последнюю цифру?
А какое примерно отношение максимального числа к количеству ключей в кэше? Может проще иметь хеш-таблицу ключей, которые на предыдущем шаге привели к 1? Тогда храниться все будет в разы компактнее => больше ключей поместится в память, => можно будет быстрее исследовать больший диапазон. А после того, как мы достигли верхней границы, пробегаемся по ключам и считаем уже для них последовательности сведения к 1 (здесь можно и с кешированием полных путей) - то есть такая двухступенчатая ракета ;)
Система фрактальна. По поведению маленького начальника можно догадаться, что и каким способом делает с ним вышестоящий. Те же портреты, методы, цели и средства, и та же [корпоративная] религия.
Мой опыт говорит, что основа безопасности - качество построения в голове модели развития дорожной ситуации. Это самое сложное в процессе езды. Я за рулем с 92 года, наездил тысяч 600 километров по РФ, Европе и Азии. Помимо общих паттернов и флагов-варнингов, на которые нужно обращать внимание (велосипедисты - да, один из них), есть и национальные особенности, и даже особенности вождения в разных городах (РФ). И все вокруг - пешие, конные, вело-, мото-, пьяные и трезвые, лисы, кабаны и лоси (не дай Бг) на дорогах - это входные переменные нашей статмодели. Она от этого пухнет, и голова болит - но если какую-то переменную не учитывать - рано или поздно ваша модель даст false positive - и если второй участник (если он не столб) тоже сделает fail - то это будет фатально.
Это не относится к тем, кто не видит велосипедистов, и вообще всех, кого считает ниже себя, специально. За инциденты, произошедшие в этой связи, нужно наказывать, как за умышленные действия. Наступила смерть - умышленное убийство. В РФ таких классификаций нет - даже за доказанные видео подставы «учителей» все равно считается, что чел «не имел умысла на причинения смерти» - и поэтому - «.. по неосторожности». Вот это самый адъ.