Обновить
256K+

Java *

Объектно-ориентированный язык программирования

298,25
Рейтинг
Сначала показывать
Порог рейтинга

Прямая Web3-монетизация без посредников (Peer-to-Peer) для артистов на радио.

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

Задача была непростой. Нужно было объединить возможности мессенджера с его токеномикой и реализовать передачу медиаконтента (картинок, аудиофайлов, текстовых данных) на удаленный сервер в формате JSON. Для этого я написал серверную страницу на PHP, в которой реализовал весь необходимый API.

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

function isJpeg(string $data): bool
{
    return substr($data,0,2) === "\xFF\xD8";
}

function isMp3(string $data): bool
{
    if (substr($data,0,3)==="ID3") {
        return true;
    }

    return isset($data[1])
        &&
        ord($data[0])===0xFF
        &&
        (ord($data[1]) & 0xE0)===0xE0;
}

После получения данных нужно сразу определить что именно пришло - команда или файл:

if (preg_match('/^\/(help|bio|title|tracks|done)\b/i', $data))
{
    processCommand($db, $uuid, $data);
    exit;
}

if (isBase64($data))
{
    saveBinary($db, $uuid, $data);
    exit;
}

reply("Unknown command, please use /help.", false);

Описание профиля артиста и названия его треков передаются в текстовом виде используя специальный набор команд:

  • /help - Show this help

  • /bio text - Update artist biography

  • /tracks - Show info of all tracks

  • /title text - Update current track title

  • /pay amount - Pay for service

  • /done - Finalize current track

  • Send JPG image to update artist image

  • Send MP3 audio to update current track

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

  1. артист отправляет фото профиля

  2. артист отправляет описание профиля

  3. артист загружает трек

  4. артист отправляет описание трека

  5. артист выполняет оплату сервиса

  6. артист финализирует трек

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

МОНЕТИЗАЦИЯ

Отправка материала артистом требует платы за сервис. Когда артист подтверждает оплату, бот списывает с его кошелька требуемую сумму и зачисляет её на кошелек владельца радиосервиса. Это значительно упрощает обмен активами между плательщиком и получателем.

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

схема работы блокчейна
схема работы блокчейна

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

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

Если у вас появятся предложения, буду рад подискуссировать.

Теги:
-4
Комментарии3

30 июня в 18:00 начнется  вебинар «Почему Java-разработчику следует брать на вооружение Quarkus». В прямом эфире рассмотрим ключевые преимущества Quarkus перед Spring Boot: родную сборку, малое потребление памяти и удобство разработки.

Создадим один и тот же REST-сервис на Spring Boot и на Quarkus, сравним время старта и затраты ресурсов.

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

Содержание:

✅ Проблема долгого запуска и высокого потребления памяти в Spring Boot.

✅ Что такое Quarkus? Окружающая среда расширений, родная сборка.

✅ Живой код: создание REST-сервиса на Spring Boot и на Quarkus.

✅ Измерение времени запуска и потребления памяти.

✅ Как родная сборка ускоряет размещение в Kubernetes и снижает затраты.

✅ Настоящий случай из практики автора.

✅ Как продолжить изучение Quarkus.

🧑‍🎓 Спикер: Чвилёв Константин, эксперт в области разработки ПО

📆 Когда: 30 июня, 18:00–19:00 (Мск)

👉 Регистрация

Теги:
+3
Комментарии0

Представлено бесплатное десктопное приложение Streambert с открытым исходным кодом для ПК на Windows, macOS и Linux. Решение распространяется по лицензии GNU GPL v3.0. Главное преимущество Streambert — здесь совсем нет рекламы и трекеров. Разработчики подчёркивают, что приложение всегда будет бесплатным и не станет собирать личные данные пользователей.

Для поиска и отображения информации о фильмах и сериалах Streambert использует базу TMDB и для работы понадобится бесплатный API-ключ TMDB. Программа поддерживает русский интерфейс и субтитры, а также даёт возможность скачивать любые медиафайлы для офлайн-просмотра.

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

Теги:
+3
Комментарии2

Риски ИИ- генерируемого кода - качество, производительность, “УСПЕВАЮ ЛИ Я ЗА ТЕМПОМ” 

ИИ генерирует код быстрее, чем мы успеваем ловить его реальные проблемы.
В JPA/Hibernate это особенно больно: код компилируется, тесты зелёные — а внутри N+1 и лишние запросы. Veai проверяет такие гипотезы на фактах проекта прямо в IDE: семантические usages, реальные прогоны тестов, coverage, debugger, доступ к исходникам Hibernate.

Не “этот код, возможно, тормозит”, а проверка через запуск. Скорость растёт — контроль над качеством остаётся. Большой разбор продукта сделан в статье

Теги:
+4
Комментарии0

От падающего теста до правки: как General ведёт задачу в любимой IDE

Когда разработчик открывает AI-чат в IDE, он не думает категориями режимов. Он не формулирует задачу как «сначала Plan, потом Code, затем Test и Review» — он пишет проще:

Почини тест

И только по ходу становится понятно, что это за задача: иногда хватит поправить одну строку, иногда — пройти по нескольким модулям, разобраться в зависимости, изменить production-код и обновить тесты. Заранее это знать нельзя — и не нужно.

Под этот сценарий в Veai сделан режим General: вы описываете цель обычными словами, а агент сам выбирает маршрут — проход по коду, планирование, тесты, ревью, отладка или подключение субагентов. Специализированные режимы (Ask, Code, Test, Plan, Review, Debug) остаются для случаев, когда вы хотите управлять процессом явно.

Почему ручной выбор режима мешает

Реальная задача редко укладывается в один режим. «Исправить падающий тест» — это сразу несколько подзадач: понять причину, решить, где ошибка (в тесте, production-коде, моках, данных или окружении), внести правку и запустить проверку. Если режим нужно выбрать заранее, новый разработчик начинает не с решения проблемы, а с изучения классификации агентов. General убирает этот выбор из начала задачи.

Что происходит по шагам

На запрос «в сервисе оплаты падает тест, найди причину и почини» General в простом случае ведёт задачу сам:

  1. находит и запускает тест через IDE run configuration — в том же окружении, что и разработчик (SDK, профиль, переменные, модули), а не в собранном из терминала, которое может отличаться;

  2. читает стектрейс, открывает связанный production-код, при необходимости смотрит usages, warnings и inspections;

  3. вносит минимальную правку и перезапускает проверку: тест прошёл или упал — это факт из IDE, а не предположение модели.

Если стектрейса не хватает, агент опирается на отладчик (breakpoints, значения переменных, call tree), а если стектрейс уводит в библиотеку — открывает её код или декомпилированный класс через IDE, а не угадывает API по памяти модели.

Когда подключаются субагенты

Маршрут выбирает не отдельный классификатор, а сама модель: по тексту задачи и первым фактам из проекта она решает, достаточно ли пройтись по коду или стоит разложить работу на субагентов (один исследует причину, второй — зависимости, третий — тесты). Поправить одну строку General сделает сам, большую задачу — распараллелит. Многоагентность здесь не самоцель, а инструмент для задач, где она реально ускоряет результат.

Полностью исключить ошибки модели нельзя. Но General опирается не только на LLM, grep и RAG, а на JetBrains IDE как на источник проверяемых фактов: run configurations, SDK и classpath, структуру кода, usages и inspections, coverage, код зависимостей и ошибки компиляции так, как их видит IDE. Отсюда меньше галлюцинаций API и ситуаций «у агента прошло, а в IDE или CI падает».

Разницу можно измерить. 

Мы прогнали 8 enterprise-задач на Java/Spring через четыре агента на одной модели — Cursor, Claude Code, JetBrains Junie и Veai:

Контроль остаётся у разработчика

Даже когда агент ведёт задачу автономно, последнее слово за человеком: разработчик смотрит diff в окне Agent Changes и решает, что принять. Перед этим General может сам прогнать несколько субагентов-ревьюеров по своим изменениям и устранить критические проблемы ещё до того, как покажет результат человеку, — авторевью встроено в маршрут, а не остаётся отдельным ручным шагом. Идея не в том, чтобы убрать review, а в том, чтобы убрать лишнюю ручную маршрутизацию до него.

Установить Veai 5.12

Обратная связь — support@veai.ru и чат с командой.

Теги:
+9
Комментарии0

Вайб-кодинг на корпоративном контроле: как превращать хаос генерации в инженерную дисциплину

Приглашаем вас на совместный вебинар ITFB Group и компании Veai, посвящённый практике контролируемого применения ИИ в разработке.

Когда: 24 июня, 11:00
Где: онлайн

Ключевой вопрос: как использовать скорость вайб-кодинга, но при этом не допустить падения качества, потери управляемости и рисков безопасности?

О продукте

Veai — первый российский ИИ-агент, сочетающий высокую скорость генерации кода с жёстким контролем на основе формальных методов. На вебинаре мы на реальных примерах покажем, чем Veai отличается от Cursor, Copilot и других доступных на рынке решений.

Программа вебинара

Практическая демонстрация: работа агента на реальном коде — от постановки задачи до готового результата.

Сравнительный анализ: объективная оценка сильных и слабых сторон популярных ИИ-ассистентов.

Метрики и экономика: данные по экономии часов, ROI, доле принятого сгенерированного кода и росту тестового покрытия (до 80% с использованием символьного исполнения и data-flow анализа).

Работа с некомпилируемым кодом: агент автоматически выявляет и исправляет ошибки компиляции и предупреждения IDE, используя нативные инструменты без дополнительных вызовов.

Безопасность и архитектура: варианты развертывания (on‑premise, self‑hosting, VPC, SaaS), механизмы контроля доступа и встроенный SAST-движок, проверяющий каждую генерацию.

Спикеры

Константин Волков, менеджер по техническим решениям Veai.
Наталья Романова, директор по развитию ITFB Group.

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

Кому будет полезно: ИТ-директорам, руководителям разработки, архитекторам и всем, кто внедряет или планирует внедрять ИИ-инструменты в корпоративную среду.

👉 Зарегистрироваться

Теги:
+4
Комментарии0

Продолжаем делиться докладами с прошедших конференций! На этот раз у нас тут доклад с Joker 2025 🔥

Тема: "Как компилятор видит код. Поиск уязвимостей на графах"

Посмотрели, как код превращается из исходного представления в графовое, чтобы ответить на вопрос: «Как компилятор видит код?». Прошлись по технологиям фронтенда — от AST и графов на его основе до карты вызовов — и посмотрели на их визуализацию.

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

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

Посмотреть можно тут:
- наш сайт
- VK Video
- Rutube
- YouTube

Теги:
+5
Комментарии0

Что посмотреть на неделе: брокеры сообщений, Kubernetes и ИИ‑агенты

Привет, Хабр. На этой неделе в OTUS пройдет серия бесплатных уроков для тех, кто работает с архитектурой, инфраструктурой, разработкой, аналитикой и ИИ‑инструментами.

Будет много практики: выбор брокера сообщений, деплой Java‑приложения в Kubernetes, мониторинг распределённых систем, создание AI‑ассистентов и интеграция ИИ‑агентов в рабочую разработку.

Все уроки бесплатно проводят преподаватели в рамках курсов. Можно прийти на один вебинар по своей задаче или собрать мини‑маршрут на неделю.

Архитектура и backend

  • 8 июня, 19:00. «RabbitMQ vs Kafka. Как выбрать подходящий брокер сообщений?». Записаться
    разберём, чем отличаются RabbitMQ и Kafka, в каких задачах они работают лучше и как выбрать брокер под архитектуру проекта.

  • 15 июня, 20:00. «Системы обмена сообщениями: RabbitMQ и Kafka». Записаться
    поговорим об устройстве систем обмена сообщениями и сценариях, где брокеры помогают строить устойчивые распределённые решения.

Инфраструктура и эксплуатация

  • 8 июня, 20:00. «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube». Записаться
    покажем, как подготовить Java‑приложение к запуску в Kubernetes и развернуть его локально через Minikube.

  • 10 июня, 20:00. «Мониторинг распределённых систем». Записаться
    разберём, как отслеживать состояние сложных систем, быстрее находить проблемы и не теряться в метриках, логах и алертах.

ИИ в рабочих процессах

  • 11 июня, 20:00. «Создаём ИИ‑ассистента для системного аналитика за 1 час». Записаться
    покажем, как ИИ может помогать аналитику в рабочих задачах: от обработки требований до подготовки артефактов.

  • 15 июня, 20:00. «Интеграция ИИ‑агентов в рабочую разработку: обвязка агента навыками и MCP». Записаться
    разберём, как расширять возможности ИИ‑агента с помощью навыков и MCP, чтобы он был полезен в реальном рабочем процессе.

  • 15 июня, 20:00. «Создаём AI‑ассистента и интегрируем его в Telegram». Записаться
    покажем, как собрать AI‑ассистента и подключить его к Telegram для пользовательских сценариев.

Команды и процессы

  • 11 июня, 20:00. «Внутри Scrum: как работают мастер, владелец и команда». Записаться
    разберём, как на практике распределяются роли в Scrum и почему процесс часто ломается не из‑за фреймворка, а из‑за его применения.

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

Теги:
+3
Комментарии0

Представлен открытый проект waylandcraft - это полнофункциональный композитор Wayland полностью интегрирован в мод Fabric для Minecraft Java 26.1.2.

«Запускайте приложения и открывайте окна прямо в вашем мире Minecraft. Перетаскивайте данные из одного окна в другое. Закрепите видеоплеер на вашем HUD. Выбор за вами. Важно: этот мод работает только под Linux! MacOS и Windows не поддерживаются», — пояснил автор проекта.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии1

В предыдущих сериях был реализован простейший движок на основе HashMap, в которой сохраняются данные key -> value, и в принципе была открыта дорога для написания сервера и клиента для тестов. Но я решил добавить в Space работу с распределенными (XA) транзакциями.

Наличие такого механизма обязательно приведет к деградации производительности. Закономерно возникает вопрос: для чего это было сделано? Memifydb - это распределенная БД и она должна обеспечивать конкурентный доступ к данным обеспечивая их целостность. Что проку если она будет работать быстро, но её содержимое будет - хаос? Ведь деже при создании простого приложения для обработки данных в нескольких потоках используется synchronized в java (и пр. механизмы синхронизации).

Второй момент состоит в том что я всегда работал с транзакциями на стороне клиента, т.е. работал с менеджером транзакции (TransactionManager). Теперь же я писал сервис и пришлось иметь место с менеджером ресурсов (XAResource), что тоже интересно (не забываем что проект модельный и исследовательский).

Итак, транзакционность добавил, пока что на уровне RAM без сохранения данных в долговременную помять для отката/восстановления. Следующий шаг это написание самого сервера, который будет управлять Space’ами и обработкой клиентских запросов.

👉 Telegram: https://t.me/memifydb 👉 GitHub: https://github.com/yourname/memifydb

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

Нововведения Java 26

В марте 2026 года вышла Java 26.

Поскольку мы в PVS-Studio используем Java для разработки наших Java, JavaScript и TypeScript анализаторов, такая новость нами не могла быть пропущена. Мы выпустили статью, где рассмотрели основные изменения, которые эта версия с собой принесла. Так что давайте вместе посмотрим на основные нововведения, появившиеся в Java 26.

Теги:
Всего голосов 6: ↑6 и ↓0+7
Комментарии0

Друзья, рады поделиться записью первого вебинара из цикла “Современный Gradle для Java-разработчика” 🔥

В первом вебинаре Егор Пиший, Java-разработчик в PVS-Studio, рассказал, зачем в современных проектах нужны модули и как они помогают масштабировать кодовую базу без хаоса. Вместе посмотрели, как устроен жизненный цикл Gradle и какие механизмы стоят за его скоростью и гибкостью.

Посмотреть ещё можно тут:

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

Теги:
Всего голосов 1: ↑0 и ↓1-1
Комментарии0

Ближайшие события

Паттерны проектирования еще актуальны?

Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?

У меня ощущение обратное.

Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.

Все поменялось, когда я стал использовать ИИ как инструмент для обучения. Просил давать задачи, искать проблемы в решениях, объяснять, почему в одном месте уместен Strategy, а в другом лучше Mediator. Через практику и обсуждение паттерны перестали быть абстракцией.

Чем проще генерировать код, тем важнее понимать его форму и границы. Иначе не ускоришь разработку, а ускоришь накопление технического долга.

Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.

Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.

Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?

Теги:
Всего голосов 6: ↑5 и ↓1+6
Комментарии1

🌲 Открываем регистрацию на Дебаг Кемп

Мы придумали формат, который давно хотели сами: выбираешься из города, два дня в сосновом лесу на Карельском перешейке — маршрут, костёр, мастер-классы по выживанию, нетворкинг без слайдов и питчей. Просто люди, с которыми интересно, и никакого Slack-а.

📅 6–7 июня 2026 (выходные) 👥 Всего 25 мест — маленький формат, это принципиально.

Цена растёт по мере приближения к дате. Оплатить можно частями через сплит → регистрация

Если вы 💎 практик сообщества — скидка 15% применяется при регистрации автоматически. Ещё не практик, но думаете? Сейчас самый разумный момент.

👀 Узнать больше · 📝 Регистрация

Вопросы — в чат, мы там живём.

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии0

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу и думаем о данных.

Взлетаем, создал репозиторий под проект https://github.com/mathter/memifydb.git

План

План общий такой:

  • Изначально строю некоторый каркас, который буду достраивать и наполнять содержанием. Это будет удобно для прототипирования.

  • Для работы с данными создам некоторый дополнительный уровнь абстракции, что бы не привязываться к конкретному формату данных/библиотеке и менять его налету для сравнения.

Сделано

  • Данные клиента будут храниться в space’ах - это будет аналог таблиц в БД. Для начала будет только key-value space что бы можно было подумать уже сейчас о WAL клиенской библиотеке для java и сетевом уровне в целом и конечно же о транзакциях.

  • Тестовая реализация WAL, которая в проекте будет называться Log.

Run.

Теги:
Рейтинг0
Комментарии0

🔌Форматы обмена и хранения данных

В предыдущих постах Разбираемся в in-memory базах и Выбираем базу я написал, что собираюсь сделать исследовательский проект по in-memory базам данных  и имя ему MemifyDB. Так же выбрал направление движения: это key-value хранилище, которое потом доработаю до документо-ориентированной системы.

Теперь ключевой вопрос: как клиенты будут с ней общаться?

Протокол обмена — это мост между сервером и клиентом. От его дизайна зависит скорость, удобство и даже то, какие фичи мы сможем реализовать.

Human readable (JSON, XML and etc.)

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

  • Простота реализации: не нужно поддерживать разные типы на уровне протокола, всё передаётся как строки, а клиент сам разбирается.

  • Гибкость: строкой можно закодировать что угодно — число, JSON, бинарные данные.

Но у этого подхода есть обратная сторона:

  • Нет нативной поддержки типов: Клиент сам должен сериализовать/десериализовать.

  • Оверхед на парсинг: Каждый раз нужно преобразовывать “42” в число и обратно.

  • Неэффективное использование памяти: Число 123456 занимает 6 байт как строка, хотя в бинарном виде — 4 или 8.

  • Невозможность частичного обновления сложных структур: Чтобы изменить одно поле в JSON-объекте, приходится переписывать весь объект (можно конечно поспорить).

## 🎯 Наш подход: типизированные данные с рождения В MemifyDB мы пойдём другим путём.
Мы будем хранить данные в памяти в типизированном виде: строки, числа, списки, хеши, документы — каждый тип со своим внутренним представлением.

И протокол обмена с клиентом должен это отражать.
Мы не хотим, чтобы клиент упаковывал число в строку только потому, что так проще.
Мы хотим передавать по сети те же бинарные структуры, которые лежат в памяти.

Это даст:

  1. Типизированность Формат должен явно различать типы данных: строки, числа (разной разрядности), булевы значения, null, массивы, объекты (документы).
    Это позволит серверу правильно интерпретировать данные без дополнительных метаданных.

  2. Компактность Формат не должен раздувать данные. Число 42 должно занимать 8 байт (или 4, если это int32), а не 2 символа ASCII.

  3. Быстрая навигация Мы должны иметь возможность быстро «прыгнуть» к определённому полю документа без полного парсинга.
    Это важно для частичных обновлений и запросов.

  4. Потоковость Формат должен допускать частичную отправку/приём, чтобы можно было обрабатывать большие документы по частям.

  5. Самодостаточность Данные должны содержать всю информацию для интерпретации, но при этом не дублировать имена полей без необходимости (как в JSON).

🔍 Что дальше?

Существуют несколько бинарных: CBOR, BSON, FlatBuffer и пр. Если у вас есть опыт работы с этим форматами, пишите в комментариях какие у них есть плюсы, минусы и подводные камни.

Теги:
Рейтинг0
Комментарии0

🧠 MemifyDB: прежде всего — видение (vision).

Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим?
Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision).
Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.

Поехали!

📚 Типы in-memory баз данных

1. Key-Value хранилища

Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.

  • Примеры: Redis, Memcached, DragonflyDB.

  • Сценарии: кэширование, сессии пользователей, счётчики, очереди задач.

  • Плюсы: максимальная скорость, минимальный оверхед, простота масштабирования (шардирование по ключу).

  • Минусы: ограниченная модель данных — нет сложных запросов, только операции по ключу.

2. Документо-ориентированные БД

Значение — структурированный документ (JSON, BSON, XML). Внутри документа можно индексировать поля и выполнять запросы по содержимому.

  • Примеры: MongoDB (in-memory storage engine), Couchbase.

  • Сценарии: хранение сложных объектов (профили, каталоги), где важна гибкость схемы.

  • Плюсы: удобство для разработчика, естественное представление данных, возможность частичного обновления.

  • Минусы: чуть более высокий оверхед по сравнению с key-value (парсинг, индексация).

3. Колоночные (Columnar) in-memory БД

Данные хранятся не по строкам, а по колонкам. Это даёт огромное преимущество при аналитических запросах (суммы, средние, группировки).

  • Примеры: SAP HANA, MemSQL (SingleStore) в колоночном режиме, Apache Arrow (формат, но не БД).

  • Сценарии: аналитика реального времени, отчёты, BI.

  • Плюсы: сверхбыстрая агрегация, высокая степень сжатия.

  • Минусы: медленные точечные обновления (OLTP-нагрузка), сложность реализации.

4. Графовые БД

Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.

  • Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).

  • Сценарии: социальные сети, рекомендательные системы, сети связей.

  • Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.

  • Минусы: узкая ниша, сложность шардирования.

5. Time-series БД

Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.

  • Примеры: InfluxDB, TimescaleDB (in-memory части).

  • Сценарии: мониторинг, IoT, финансовые тикеры.

  • Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.

  • Минусы: слабо подходят для произвольных данных.

…## 🧭 Наш курс: от Key-Value к документам

Для MemifyDB я выбрал путь, который кажется самым прагматичным:

  1. Создаём ядро Key-Value
    Это фундамент. Мы реализуем:

    • потокобезопасное in-memory хранилище;

    • поддержку разных типов значений (строки, списки, хеши, числа);

    • механизмы TTL и эвикшена (LRU);

    • бинарный протокол, близкий к внутреннему представлению.

    Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).

  2. Надстраиваем документный слой
    Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:

    • индексация по полям;

    • поддержка частичного обновления;

    • запросы с фильтрацией по содержимому.

При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.

Такая двухслойная архитектура даёт:

  • гибкость — можно работать и как с обычным кэшем, и как с документной БД;

  • производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;

  • расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.

Теги:
Всего голосов 4: ↑0 и ↓4-4
Комментарии2

🧠 Разбираемся, как устроены in-memory БД: пишем MemifyDB с нуля.

Redis быстр, но не всегда удобен. SAP HANA — мощь, но ценник…
А что, если заглянуть под капот и создать свою enterprise in-memory СУБД?
Не чёрный ящик, а полностью прозрачную, современную, open-source — и при этом готовую к высоким нагрузкам. Разбираемся как это работает!

Знакомьтесь — MemifyDB.

📌 Что это будет?
Настоящая in-memory система уровня enterprise, в которой мы разберёмся до винтика:

  • живёт в RAM, отвечает за микросекунды;

  • сохраняет данные на диск (RDB + WAL) — никакой потери после ребута;

  • реплицируется и шардируется «из коробки»;

  • поддерживает транзакции (не хуже MULTI/EXEC, но с возможным rollback);

  • и при этом не просит продать почку за лицензию.

Весь код — open source, все решения — с объяснениями.

🛠 Технический фундамент (выбираем стек вместе)
Платформа — JVM. Я сейчас выбираю между Java 21 (Loom) и Scala 3 (ZIO / Akka).

  • Сеть: Netty или виртуальные потоки — посмотрим на бенчмарках.

  • Память: off-heap + собственный slab-аллокатор на ByteBuffer. GC не мешает, фрагментация под контролем.

  • Конкурентность: Lock-Free структуры данных, чтобы не блокировать потоки.

  • Протокол: RESP-совместимость — redis-cli сможет общаться с нами.

🗺 Дорожная карта: что и когда разберём

  1. Ядро: потокобезопасное KV-хранилище в памяти. Как работают LRU и TTL?

  2. Persistence: снапшоты и WAL. Как не потерять данные при краше?

  3. Сеть: пишем TCP-сервер. Netty vs Loom — кто быстрее?

  4. Транзакции: реализуем MULTI/EXEC, WATCH. Нужен ли MVCC?

  5. Репликация и Raft: как достичь консенсуса в распределённой системе?

Каждый этап — открытый код, пост с разбором, грабли и профит.

🤔 Зачем я это делаю публично?
Во‑первых, разобраться самому и дать шанс разобраться другим.
Во‑вторых, фидбек сообщества ловит ошибки на берегу.
В‑третьих, хочется сделать реально полезный инструмент, а не очередной pet‑project.

💬 Вопрос к залу:
Какой стек предпочтительнее для enterprise in‑memory БД — Java 21 + Loom или Scala + ZIO/Akka?
Какие фичи вы бы добавили в дорожную карту?
Пишите в комментариях — лучшие идеи уйдут в реализацию!

👉 Подписывайтесь, чтобы не пропустить:

  • глубокий разбор off‑heap аллокатора;

  • сравнение моделей конкурентности на реальных бенчмарках;

  • историю о том, как одна строка unsafe кода валила прод три дня.

Теги:
Всего голосов 13: ↑3 и ↓10-7
Комментарии22

Всё, что нужно знать для начала работы в PVS-Studio

Статический анализатор PVS-Studio — это инструмент для поиска ошибок в коде на протяжении всего жизненного цикла проекта.
В новой статье разберём основные особенности анализатора PVS-Studio, сценарии и варианты анализа, а также узнаем всё, что нужно знать для начала работы с инструментом.

Теги:
Рейтинг0
Комментарии0
1
23 ...