Search
Write a publication
Pull to refresh
4
0
Send message

Зависит от того какие запросы на чтение должны поддерживаться. Зачастую time-series данные имеет смысл разбивать по периодам, например, по дням, неделям и тому подобное, в зависимости от того как много данных добавляется в этот период и как для пользователя имеет смысл отображать эти данные. Этот подход иногда называют бакетированием (от bucket). Для вашего примера можно использовать составной partition key из device_id и, например, даты.


CREATE TABLE sensor_data (
   device_id uuid,
   data_date date
   date_time timestamp, 
   data double, 
   PRIMARY KEY ((device_id, date), date_time)
);

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


При этом понадобится вторая таблица для хранения самих дат, чтобы была возможность по device_id найти даты.


CREATE TABLE sensor_dates (
   device_id uuid,
   data_date date
   PRIMARY KEY (device_id, date)
);

При добавлении значение делаем два Insert в обе таблицы.
При чтении есть варианты:


  • Когда диапазон не задан и нужно получить все данные, то запрашиваем все даты по device_id из sensor_dates, затем по каждой дате запрашиваем сами значение из sensor_data. Это может быть долго, если дат много, так как придется сделать много запросов.
  • Когда указан диапазон, то даты можно получить из указанного диапазона и опять же запросить данные по датам из sensor_data.

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


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

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

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

Есть другие варианты, например, господа наемные работники организуются и коллективно отстаивают свои законные интересы.

Может бизнес что-то и потерял, но ответье, почему за это должны расплачиваться наемные работники?

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

Переводы в Россию остановились 4 месяца назад

Это не правда, свифт еще работает. На данный момент, компания, где я работаю, вполне успешно переводит деньги российским сотрудникам из недружественной страны НАТО и не отмазывается на теме невозможности переводов. Да и многие другие компании, которые приняли решение ликвидировать офисы в РФ, выплатили всё причитающиеся по закону.

Видимо владельцы и руководство Game Insight решили просто свои проблемы порешать за счет сотрудников, и повод сейчас удобный - можно все списать на войну спецоперацию и санкции

Те данные, которые вы увидите в нашем исследовании — не просто цифры
из вакансий или резюме специалистов, это реальные зарплаты, которые
айтишники получают прямо сейчас.

вижу хдесь некоторое противоречие с

Вы можете в любой момент зайти и проверить, ниже или выше рынка вы сейчас получаете зарплату.

Если человек указывает свою текущую зп, которую он получает сейчас, значит это не рыночная зп, потому что человек не находится на рынке труда. Когда человек выходит на рынок труда, или hr-специалисты хотят переманить его, то желаемая зп будет скорее всего больше текущей.

Что касается решающей роли компаний в жизни людей, то уже сегодня складывается платформенная экономика, в которой судьба каждого сотрудника зависит от воли компании. Уже сегодня ничего не мешает Амазону и Яндексу просто заблокировать аккаунт своего курьера, таксиста, грузчика в случае любых спорных вопросов с ним без каких либо юридических проволочек

На самом деле бизнесу вообще не нужны сотрудники в штате, слишком много рисков и головной боли: ЗП плати, взносы, налоги плати, а если человек заболел, кто будет его работу делать, а если поранился на производстве, а еще что-то ему не нравится постоянно, требует что-то, профсоюзы мутит, и тд и тп.

Ну и экономика семимильными шагами идет к тому чтобы заменить сотрудников сервисами-исполнителями, отсюда и такой рост популярности аутсорса. Разработчики думают, что их сложно заменить на ИИ, но на самом деле ИИ и не нужен. Нужны сервисы. Скольких сотрудников уже удалось заменить сервисами от того же Амазон? Да, сервисы тоже должен кто-то разрабатывать, но много ли таких компаний? и будет ли пресловутая возможность у разработчика улучшить условия труда сменив один условный амазон на другой?

Делать всех собственниками - одиозная идея

Что именно одиозного в этой идее?

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

Профсоюз не политическая организация

Профсоюз конечно не политическая организация, в плане левых/правых и всего такого. Но на уровне законодательной власти интересы рабочего класса почти не представлены, к сожалению. А если какие-то партии и декларируют что-то в этом направлении, то как правило это просто болтовня и по факту никакой работы не производится. А вот интересы бизнеса очень даже представлены, особенно крупного. Мое мнение, профсоюзы так или иначе должны участвовать в политике, может и не напрямую. Очень надеюсь, что профсоюзы поспособствуют развитию гражданской ответственности в нашем обществе.

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

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

Горячая замена делается микросервисами и контейнерами, наверное по этому эта фича не особенно востребована именно как часть языковой среды выполнения. С другой стороны для JVM есть фрейморки, например Akka, которые умеют горячий деплой. Про Котлин на докладах от разработчиков они иногда упоминают, что хотели бы сделать сериализуемые корутины, со всеми вытекающими возможностями.

Асинхронность как раз стала востребована с ростом популярности распределенных систем, где много сетевых взаимодействий, но нагрузка на каждый узел минимизируется. В распределенных системах «миллион запросов», вовсе не значит, что этот миллион запросов пришел от конечных пользователей, сама система на каждый запрос от пользователя порождает десяток-другой новых запросов, а то и больше. Одна «жирная» задача от пользователя разбивается на десяток более легких и раздается сервисам, нагрузка на каждый сервис уменьшается, но имеем в 10 раз больше сетевого IO. При этом зависимым компонентам не обязательно уметь выдерживать такую же нагрузку, как система в целом

Information

Rating
Does not participate
Registered
Activity