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

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

В сборнике VLDB'17 вышла такая статья. В ней представлена NAM-DB, масштабируемая распределённая система баз данных, использующая удалённый прямой доступ к памяти (RDMA) — в основном, однонаправленный вариант RDMA — и инновационную технологию диспетчера временных меток (timestamp oracle) для поддержки транзакций с изоляцией мгновенного снимка (SI). NAM в данном случае означает архитектуру с прикреплением памяти к сети (network-attached-memory), где благодаря активному использованию RDMA вычислительные узлы получают возможность напрямую общаться с пулом узлов памяти.

Уникальные ограничения — классическая функция реляционной базы данных, которая обеспечивает уникальность столбца или группы столбцов во время ввода данных или построения индекса. Они могут быть указаны с помощью ключевых слов UNIQUE / PRIMARY KEY. Уникальные индексы — сущности, которые их поддерживают. Хотя такие ограничения всегда можно было указать в heap-таблицах, они не поддерживались в append optimized таблицах (AO/CO). 

В статье разберём, как уникальные индексы помогают принимать более эффективные решения по планированию. А также рассмотрим примеры базовых сценариев и объясним, как они обрабатываются. 

Пламенный хабропривет! Это лонгрид от двух Иванов из VK: Ивана Расторгуева, который знает всё про платформу VK Mini Apps, и Ивана Бойченко, который развивает направление NFT ВКонтакте. Недавно мы провели первый собственный Web3 онлайн-хакатон VK NFT × Definition и хотим поделиться с вами его результатами и своими планами развития NFT-технологий в наших сервисах. 

Привет, Хабр! На связи Андрей Зяблин, Java разработчик компании «Магнит». В статье я расскажу про три решения, которые позволяют реализовать потоковый обмен данными из БД между распределёнными приложениями.

Greenplum 7 — первая версия СУБД, совместимая с секционированными таблицами из PostgreSQL: World DB. 

Небольшая предыстория: до PostgreSQL 10 партицирование в PostgreSQL выполнялось в очень ограниченной форме и по сути, было просто вариантом наследования таблиц. Начиная с PostgreSQL 10, мы можем использовать декларативный синтаксис для определения парадигмы разделов. 

В рамках слияния с PostgreSQL 12 Greenplum 7 вобрал в себя весь синтаксис PostgreSQL для разбиения таблиц, сохранив при этом синтаксис Greenplum. В результате у Greenplum 7 есть шанс взять лучшее из обоих миров — что именно, обсудим в этой статье. 

Любая распределенная система, например включающая несколько микросервисов со своими источниками данных (и особенно запущенная внутри сложной системы оркестрации, которая сама по сути является распределенным приложением), обладает множеством точек отказа и по мере ее масштабирования и развития становится все сложнее обнаружить проблемы в функционировании (например, долгий ответ одного из микросервисов), которые приводят к общей потере производительности и даже отказам при высокой нагрузке (или при других неудачных стечениях обстоятельств). И даже если обнаружить сам факт наличия проблемы еще возможно через метрики систем мониторинга, наиболее часто для этого используются замеры задержки ответа, интенсивности запросов, операционные метрики насыщенности сервиса (например, отношение одновременно обрабатываемых запросов к лимиту или замеры процессорного время и/или зарезервированной памяти), то выяснить истинную причину возникновения отклонения уже не так просто (например, это может быть неудачная настройка кэшей запросов базы данных или достижения лимита подключений из‑за того, что приложение не использует пул и т. д.). Чтобы решить эту задачу используются сочетания инструментов (мониторинг, отслеживание распределенных операций и логирование), которые объединяются в общем подходе Observability. В этой статье мы рассмотрим несколько стеков и инструментов для наблюдения за приложениями в Kubernetes.

Начало работы с Petals

Этот блокнот познакомит вас с основами Petals — системы логического вывода и точной настройки языковых моделей с сотнями миллиардов параметров без необходимости использования высокопроизводительных GPU. С помощью Petals вы можете объединять вычислительные ресурсы с другими людьми и запускать большие языковые модели с миллиардами параметров, например BLOOM-196B или BLOOMZ того же размера, что и GPT-3.

Эта статья не о криптовалюте, а о блокчейне и совокупности технологий и идей, которые, на мой взгляд, помогут создать быстрый, масштабируемый и безопасный распределенный реестр (DLT). Простые DLT могут быть созданы с использованием возможностей смарт-контрактов блокчейнов второго или третьего поколения, но более сложные реестры могут потребовать альтернативных решений. Примером достаточно  сложного и специфического DLT может быть децентрализованная платежная система общего пользования, совместимая с государственной денежно-кредитной политикой, то есть платформа для "цифровых денег". Реализация такого проекта на смарт-контрактах едва ли возможна. Поэтому в статье предлагаю рассмотреть для этой роли AppChain - гибридную платформу приложения и блокчейна.

Всем привет! Меня зовут Максим, я руководитель одной из групп эксплуатации инфраструктурных сервисов в Ozon. Наша команда занимается поддержкой и развитием нескольких базовых сервисов компании, одним из которых, по историческим причинам, является сервис разрешения доменных имен (DNS).

В Ozon много различных сервисов и систем. Они общаются друг с другом и внешним миром по доменным именам. DNS — центральное звено, без которого не обходится почти ни одна инфраструктура. Понятно, что когда DNS отдаёт некорректные данные, то это неприятно, когда таймаутит — плохо, когда прилёг — очень плохо, когда прилёг надолго — в принципе, можно расходиться. Значит, одна из основных задач команды инфраструктуры — обеспечить сервисам надёжное и, желательно, быстрое разрешение доменных имён. Об этом мы и поговорим. Также затронем вопросы управления ресурсными записями, жизнь в Multi DC-среде, обслуживание DNS, кеширование, журналирование запросов и возможные проблемы.

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

«Можно ли изменить код смарт‑контракта и разместить по его по старому адресу?» — такой вопрос мне задали на собеседовании Solidity разработчика.

Точный ответ требует разбора вопроса и определения требований к задаче. Требование — «изменить контракт без изменения адреса». Для этого есть подходы с обновляемым смарт‑контрактом… Но оказалось, что нет. Это вопрос на знание опкодов EVM.

Сейчас расскажу как создать‑уничтожить‑разместить_иной_контракт по старому адресу смарт‑контракта (далее — СмК) без использования паттерна Transparent Proxy и UUPS.

Это был конец декабря 2021-го года, мы едем через Техас, только что благополучно переночевали в El Paso — низкий тебе поклон Голливуд за прекрасные фильмы, такие как Sicario, после которых у нас тряслись коленки когда мы въезжали в этот прекрасный город. Продолжаем движение по направлению к Boca Chica, посмотреть на StarBase (оно того стоит поверьте). На улице жара +30 и солнечно, приятная летняя погода. В фоне отгоняю от себя мысли о том, что тут творится летом с температурой и людьми.

О чем можно думать в этот момент кроме как о космосе, о будущем и о распределенных системах? Конечно много о чем, а не этой гиковской фигне:) ...

Приветствую тебя дорогой читатель.

Я хочу начать цикл статей о паролях и о том какие проблемы они решают и вызывают в нашей жизни. Зачем? Спросите вы. Чтобы облегчить и улучшить нашу жизнь отвечу я. Поэтому мы занимаемся разработкой Meta Secret, но об этом позже, а сейчас поговорим о сложности и надежности паролей и механизмов лежащих в основе проблемы которая звучит так: люди очень плохо придумывают надежные пароли а запоминают эти пароли ещё хуже.

И тут меня посетила простая и очевидная мысль — чем сложнее пароль тем выше вероятность, что владелец забудет пароль. P = password_length^2; Это простая зависимость, каждая добавленная буква к паролю увеличивает сложность его запоминания человеком в 2 раза.

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