Запуск контейнера (Start или Run): Команда docker start (для созданного) или docker run (create + start) приводит контейнер в жизнь. Docker fork'ует (копирует) процесс и exec'ует (заменяет) его на ENTRYPOINT или CMD из образа — это становится PID 1 (первым процессом) в контейнере. Процессы стартуют в изолированном окружении: сеть подключается, порты expose'ятся, env-переменные устанавливаются.
В памяти: процессы контейнера появляются в хост-PS, но с метками cgroup. Overhead минимален — 1-2 МБ на контейнер плюс приложение.
Нюанс: запуск занимает миллисекунды, но если образ с init-скриптами (например, база данных), это может затянуться. Используйте healthchecks (docker run --health-cmd) для проверки готовности — это критично в оркестрации, чтобы не слать трафик на "холодный" контейнер.
Работа контейнера (Running): Контейнер выполняет свою задачу: ваше приложение бежит, обрабатывает запросы, пишет логи. Docker мониторит состояние: если PID 1 выходит (exit code 0 — успех, ненулевой — ошибка), контейнер останавливается. Логи доступны через docker logs.
В памяти: ресурсы потребляются динамически — cgroups enforced лимиты, так что при превышении памяти OOM-killer может убить процессы (приоритет по oom_score). Мониторьте с docker stats или Prometheus exporter; учитывайте, что restart-policy (docker run --restart=always) может перезапускать при сбоях, но это маскирует root-cause.
Пауза и возобновление (Pause/Unpause): Опционально, docker pause замораживает процессы (сигнал SIGSTOP), сохраняя состояние в памяти. Unpause (SIGCONT) продолжает. Полезно для maintenance.
Нюанс: пауза не освобождает ресурсы полностью — RAM все равно занята.
Остановка контейнера (Stop): Команда docker stop посылает SIGTERM (сигнал мягкой остановки) PID 1, дает grace-period (по умолчанию 10 секунд) на shutdown, затем SIGKILL (принудительное убийство). Это позволяет приложению gracefully закрыться: сохранить данные, завершить транзакции. Если PID 1 — Java или shell, который не ловит сигналы, используйте --init или tini для forwarding. В production настройте timeout (--time=30) для долгоживущих shutdown.
Удаление контейнера (Remove): Docker rm чистит все: удаляет writable-слой, освобождает namespaces/cgroups, detach'ит volumes/networks. Если --rm в run, удаление автоматическое.
Нюанс: stopped-контейнеры хранят состояние (файлы, логи) — используйте docker ps -a для просмотра. Dangling resources (неудаленные volumes) накапливаются — чистите с docker system prune; в скриптах автоматизируйте rm для избежания утечек диска.
Весь цикл обеспечивает воспроизводимость: контейнеры эфемерны (временны), данные persist в volumes. Подводный камень: в кластерах (Swarm/Kubernetes) lifecycle управляется оркестратором, с auto-restart и rolling updates.
#Java #middle #Docker
В памяти: процессы контейнера появляются в хост-PS, но с метками cgroup. Overhead минимален — 1-2 МБ на контейнер плюс приложение.
Нюанс: запуск занимает миллисекунды, но если образ с init-скриптами (например, база данных), это может затянуться. Используйте healthchecks (docker run --health-cmd) для проверки готовности — это критично в оркестрации, чтобы не слать трафик на "холодный" контейнер.
Работа контейнера (Running): Контейнер выполняет свою задачу: ваше приложение бежит, обрабатывает запросы, пишет логи. Docker мониторит состояние: если PID 1 выходит (exit code 0 — успех, ненулевой — ошибка), контейнер останавливается. Логи доступны через docker logs.
В памяти: ресурсы потребляются динамически — cgroups enforced лимиты, так что при превышении памяти OOM-killer может убить процессы (приоритет по oom_score). Мониторьте с docker stats или Prometheus exporter; учитывайте, что restart-policy (docker run --restart=always) может перезапускать при сбоях, но это маскирует root-cause.
Пауза и возобновление (Pause/Unpause): Опционально, docker pause замораживает процессы (сигнал SIGSTOP), сохраняя состояние в памяти. Unpause (SIGCONT) продолжает. Полезно для maintenance.
Нюанс: пауза не освобождает ресурсы полностью — RAM все равно занята.
Остановка контейнера (Stop): Команда docker stop посылает SIGTERM (сигнал мягкой остановки) PID 1, дает grace-period (по умолчанию 10 секунд) на shutdown, затем SIGKILL (принудительное убийство). Это позволяет приложению gracefully закрыться: сохранить данные, завершить транзакции. Если PID 1 — Java или shell, который не ловит сигналы, используйте --init или tini для forwarding. В production настройте timeout (--time=30) для долгоживущих shutdown.
Удаление контейнера (Remove): Docker rm чистит все: удаляет writable-слой, освобождает namespaces/cgroups, detach'ит volumes/networks. Если --rm в run, удаление автоматическое.
Нюанс: stopped-контейнеры хранят состояние (файлы, логи) — используйте docker ps -a для просмотра. Dangling resources (неудаленные volumes) накапливаются — чистите с docker system prune; в скриптах автоматизируйте rm для избежания утечек диска.
Весь цикл обеспечивает воспроизводимость: контейнеры эфемерны (временны), данные persist в volumes. Подводный камень: в кластерах (Swarm/Kubernetes) lifecycle управляется оркестратором, с auto-restart и rolling updates.
#Java #middle #Docker
👍2
Базовые настройки: volumes, networks и environment variables
После запуска контейнера важно настроить его взаимодействие с внешним миром. Эти настройки — как "провода" для данных, связи и конфигурации.
Volumes — механизм для хранения данных вне контейнера, чтобы они пережили удаление.
Есть два типа:
bind-mount (привязка к директории хоста, docker run -v /host/path:/container/path) и named volume (управляемый Docker, -v myvol:/path).
Volumes монтируются в FS контейнера, позволяя читать/писать persistently. Это как внешний жесткий диск для контейнера.
В памяти: данные на диске хоста, но доступ через namespace — нет overhead, кроме I/O.
Нюанс: bind-mounts делят permissions (права доступа) с хостом, что рискованно; используйте named volumes с docker volume create для изоляции.
В production: volume drivers (plugins) для облака, как AWS EBS, но следите за latency — медленные volumes замедляют app. Чистите unused volumes с prune, иначе диск заполнится.
Networks — для связи контейнеров между собой или с внешним миром. По умолчанию — bridge (локальная виртуальная сеть, контейнеры общаются по именам).
Другие:
host (делит сеть хоста, no isolation — быстро, но небезопасно), overlay (для multi-host в Swarm).
Docker создает network namespace: каждый контейнер имеет veth-интерфейс (virtual ethernet). Bridge использует NAT (network address translation) для внешнего доступа, с overhead 5-10% на трафик. Expose порты с -p 80:80 (host:container).
В production: custom networks для изоляции (docker network create mynet), и firewall (ufw/iptables) для безопасности.
Environment variables (переменные окружения, -e KEY=VALUE) — способ передать конфиг в контейнер, как API_KEY или DB_URL. Они устанавливаются в env процесса PID 1 и доступны в коде (System.getenv в Java). Это как настройки в панели управления.
В памяти: хранятся в process-env, минимум overhead.
Нюанс: не храните секреты в env — они видны в docker inspect или ps aux; используйте --secret или Docker Secrets в Swarm. Env влияют на эргономику (например, JAVA_OPTS), но перезапись в Dockerfile с ENV фиксирует их в слое — избегайте для sensitive данных.
Эти настройки комбинируются: например, volume для DB-data, network для связи с backend, env для creds.
Разница между образами для разработки и для production
Образы адаптируются под стадию: dev — для удобства, prod — для эффективности и безопасности.
В dev: используйте полный JDK (для компиляции), добавьте debug-tools (jdb, maven), volumes для mount кода (hot-reload). Образ большой (1ГБ+), с shell для exec (docker exec -it для отладки). Multi-stage build: stage1 — build с JDK, stage2 — copy artifacts в JRE.
В production: минимальный JRE или distroless (без shell, утилит — поверхность атаки меньше). Удалите dev-зависимости, оптимизируйте слои (unite RUN). Размер 100-200МБ, immutable (неизменяемый).
Нюанс: в prod учитывайте container-aware JVM (лимиты cgroups), signals для shutdown, entropy для crypto. Тестируйте под real limits; используйте scanning (Trivy) для vuln. Dev-образы для локали/CI, prod — для deploy.
Мини-пример: запуск hello-world и openjdk образов
Установите Docker, если его нет.
Сначала hello-world — простой тест:
Для Java: openjdk:21-jre (runtime):
#Java #middle #Docker
После запуска контейнера важно настроить его взаимодействие с внешним миром. Эти настройки — как "провода" для данных, связи и конфигурации.
Volumes — механизм для хранения данных вне контейнера, чтобы они пережили удаление.
Есть два типа:
bind-mount (привязка к директории хоста, docker run -v /host/path:/container/path) и named volume (управляемый Docker, -v myvol:/path).
Volumes монтируются в FS контейнера, позволяя читать/писать persistently. Это как внешний жесткий диск для контейнера.
В памяти: данные на диске хоста, но доступ через namespace — нет overhead, кроме I/O.
Нюанс: bind-mounts делят permissions (права доступа) с хостом, что рискованно; используйте named volumes с docker volume create для изоляции.
В production: volume drivers (plugins) для облака, как AWS EBS, но следите за latency — медленные volumes замедляют app. Чистите unused volumes с prune, иначе диск заполнится.
Networks — для связи контейнеров между собой или с внешним миром. По умолчанию — bridge (локальная виртуальная сеть, контейнеры общаются по именам).
Другие:
host (делит сеть хоста, no isolation — быстро, но небезопасно), overlay (для multi-host в Swarm).
Docker создает network namespace: каждый контейнер имеет veth-интерфейс (virtual ethernet). Bridge использует NAT (network address translation) для внешнего доступа, с overhead 5-10% на трафик. Expose порты с -p 80:80 (host:container).
В production: custom networks для изоляции (docker network create mynet), и firewall (ufw/iptables) для безопасности.
Environment variables (переменные окружения, -e KEY=VALUE) — способ передать конфиг в контейнер, как API_KEY или DB_URL. Они устанавливаются в env процесса PID 1 и доступны в коде (System.getenv в Java). Это как настройки в панели управления.
В памяти: хранятся в process-env, минимум overhead.
Нюанс: не храните секреты в env — они видны в docker inspect или ps aux; используйте --secret или Docker Secrets в Swarm. Env влияют на эргономику (например, JAVA_OPTS), но перезапись в Dockerfile с ENV фиксирует их в слое — избегайте для sensitive данных.
Эти настройки комбинируются: например, volume для DB-data, network для связи с backend, env для creds.
Разница между образами для разработки и для production
Образы адаптируются под стадию: dev — для удобства, prod — для эффективности и безопасности.
В dev: используйте полный JDK (для компиляции), добавьте debug-tools (jdb, maven), volumes для mount кода (hot-reload). Образ большой (1ГБ+), с shell для exec (docker exec -it для отладки). Multi-stage build: stage1 — build с JDK, stage2 — copy artifacts в JRE.
В production: минимальный JRE или distroless (без shell, утилит — поверхность атаки меньше). Удалите dev-зависимости, оптимизируйте слои (unite RUN). Размер 100-200МБ, immutable (неизменяемый).
Нюанс: в prod учитывайте container-aware JVM (лимиты cgroups), signals для shutdown, entropy для crypto. Тестируйте под real limits; используйте scanning (Trivy) для vuln. Dev-образы для локали/CI, prod — для deploy.
Мини-пример: запуск hello-world и openjdk образов
Установите Docker, если его нет.
Сначала hello-world — простой тест:
docker run hello-world
Pull'нет образ (~1МБ), запустит, выведет сообщение и выйдет. Проверьте docker ps -a — увидите stopped контейнер.
Для Java: openjdk:21-jre (runtime):
docker run -it --rm openjdk:21-jre java -version
-it — interactive terminal, --rm — auto-remove. Выведет версию. Добавьте --memory=512m — JVM увидит лимит и подстроит heap. Для senior: exec docker exec -it <id> bash (если shell есть) для инспекции.</id>
#Java #middle #Docker
👍3
Как вы думаете, если на собесе сказать - "я не этого не знаю, но готов изучить" - каковы шансы, что Вы пройдете?
Anonymous Poll
56%
Шансы отличные! Честность важна и ценится! 🙂
12%
Лучше попытаться что-то соврать, есть шанс, что интервьюер сам этого не знает ☺️
26%
Шансы резко падают! Нужно лучше готовиться! 👎
7%
Надо замереть и замолчать, изобразив дисконект. Или пустить слюну и упасть - могут взять из жалости.
👍1
Что выведет код?
#Tasks
public class Task290825 {
public static void main(String[] args) {
try {
System.out.print("A");
int result = 10 / 0;
System.out.print("B");
} catch (Exception e) {
System.out.print("C");
} finally {
System.out.print("D");
}
System.out.print("E");
}
}
#Tasks
👍2
👍4
Вопрос с собеседований
Что такое composition vs aggregation в деталях?🤓
Ответ:
Оба — отношения "has-a":
Composition: сильная зависимость, часть не существует без целого (например, комнаты в доме). Уничтожение дома уничтожает комнаты.
Aggregation: слабая зависимость, часть может существовать отдельно (например, студенты в классе).
Пример composition:
class House {
private List<Room> rooms = new ArrayList<>();
} // Rooms depend on House
Composition подразумевает ownership, aggregation — reference.
#собеседование
Что такое composition vs aggregation в деталях?
Ответ:
Composition: сильная зависимость, часть не существует без целого (например, комнаты в доме). Уничтожение дома уничтожает комнаты.
Aggregation: слабая зависимость, часть может существовать отдельно (например, студенты в классе).
Пример composition:
class House {
private List<Room> rooms = new ArrayList<>();
} // Rooms depend on House
Composition подразумевает ownership, aggregation — reference.
#собеседование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
Джон Уильям Мокли (англ. John William Mauchly, в русскоязычной литературе фамилия также транскрибируется как «Моучли») (30 августа 1907 года, Цинциннати, Огайо — 8 января 1980 года, Амблер, Пенсильвания) — со-создатель ENIAC/EDVAC; один из родоначальников электронных цифровых вычислений.
Гордон Стэнли Браун (30 августа 1907 г., Австралия — 23 августа 1996 г., Тусон, Аризона) — профессор MIT, внёс вклад в теорию управления и развитие цифровых вычислительных систем в инженерии.
1901 — английский изобретатель Хьюберт Сесил Бут (Hubert Cecil Booth) запатентовал электрический пылесос.
1995 — Йон Стефенсон фон Течнер и Гейр Иварсёй создали компанию Opera Software, которая продолжила разработку браузера. Этот день разработчики считают «днём рождения» Opera.
2001 — суд в Сан-Хосе официально выдвинул обвинение против российского программиста Дмитрия Склярова и московской компании «Элкомсофт», обвиняемых в снятии защиты с коммерческих продуктов фирмы Adobe.
#Biography #Birth_Date #Events #30Августа
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
С 23.08 по 29.08
Предыдущий пост(с 16.08 по 22.08)
Воскресный мотивационный пост:
Программист — это не тот, кто знает все. А тот, кто не боится не знать всего.
Выбранная голосованием тема:
не было
Запись встреч/видео:
Интеграционные тесты в Spring. Тестирование БД (Zonky, Testcontainers, SQL-скрипты, Liquibase)
Обучающие статьи:
Геттеры и сеттеры. Инкапсуляция как интерфейс класса
Расширение классов с extends
Переопределение и ключевое слово super
Docker Контейнеры, образы и сборка
Полезные статьи и видео:
Как я добился гибкости в приложении и при чем тут ссылки на методы?
10 Best Java Projects for Beginners 2025 [With Source Code]
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
#memory
Предыдущий пост(с 16.08 по 22.08)
Воскресный мотивационный пост:
Программист — это не тот, кто знает все. А тот, кто не боится не знать всего.
Выбранная голосованием тема:
не было
Запись встреч/видео:
Интеграционные тесты в Spring. Тестирование БД (Zonky, Testcontainers, SQL-скрипты, Liquibase)
Обучающие статьи:
Геттеры и сеттеры. Инкапсуляция как интерфейс класса
Расширение классов с extends
Переопределение и ключевое слово super
Docker Контейнеры, образы и сборка
Полезные статьи и видео:
Как я добился гибкости в приложении и при чем тут ссылки на методы?
10 Best Java Projects for Beginners 2025 [With Source Code]
Как и всегда, задачи можно найти под тегом - #Tasks, вопросы с собеседований - #собеседование
#memory
🔥4
Введение в NoSQL базы данных
Что такое NoSQL и почему они появились
NoSQL базы данных — это нереляционные системы, которые хранят информацию не в табличной форме. Они возникли в 2000-х годах благодаря компаниям вроде Google и Amazon, чтобы обрабатывать петабайты данных в распределенных системах. В отличие от реляционных баз, как MySQL или PostgreSQL, NoSQL не требуют предопределенной схемы данных, что упрощает разработку и изменения.
Отличия от реляционных баз
Реляционные базы используют таблицы, где данные организованы в строки и столбцы с отношениями через ключи. Они следуют ACID-принципам: атомарность (все или ничего), согласованность, изоляция и долговечность. NoSQL, напротив, часто следуют BASE-модели: базовая доступность, мягкое состояние и eventual consistency. Это значит, что данные могут быть временно несогласованными, но система всегда доступна. NoSQL лучше масштабируется горизонтально, добавляя дешевые серверы, в то время как SQL — вертикально, улучшая один сервер.
Что такое NoSQL базы данных?
NoSQL (от "not only SQL") — это класс баз данных, которые не придерживаются строгой реляционной модели. В отличие от классических баз, где данные хранятся в таблицах с фиксированными столбцами и строками, NoSQL позволяют работать с данными в более естественной форме. Термин "NoSQL" появился в конце 1990-х, но настоящий бум пришелся на 2000-е годы благодаря компаниям вроде Google (с их BigTable) и Amazon (Dynamo). Эти системы предназначены для обработки огромных объемов данных в распределенных средах, где традиционные базы дают сбой из-за масштаба.
NoSQL фокусируются на горизонтальной масштабируемости (sharding — разделение данных по серверам) и отказоустойчивости. Они часто реализуют распределенные архитектуры с репликацией (копированием данных на несколько узлов), что обеспечивает высокую доступность. Однако это требует понимания trade-off'ов, таких как потеря строгой consistency в пользу availability, как описано в CAP-теореме Эрика Брюера: в распределенной системе можно гарантировать только два из трех свойств — Consistency (согласованность), Availability (доступность) и Partition tolerance (устойчивость к разделению сети). Большинство NoSQL выбирают AP (availability + partition tolerance), жертвуя immediate consistency.
Где применяются NoSQL базы данных
NoSQL shine в сценариях с высокой нагрузкой и разнообразными данными. Они доминируют в web 2.0 и cloud-native приложениях.
- Big Data и аналитика: Для обработки петабайт данных, как в Hadoop-экосистемах. Пример: HBase для хранения логов в Facebook.
- Реал-тайм приложения: Социальные сети (Twitter использует Cassandra для timeline), рекомендации (Netflix с DynamoDB-подобными системами).
- IoT и сенсорные данные: Миллионы устройств генерируют неструктурированные данные; NoSQL справляется с velocity (скоростью поступления).
- E-commerce: Управление каталогами, сессиями, корзинами. Amazon DynamoDB для Black Friday трафика.
- Мобильные и гейминг apps: Redis для лидербордов, MongoDB для пользовательских профилей.
- Контент-менеджмент: CMS вроде WordPress на MongoDB для динамического контента.
В микросервисах NoSQL поддерживает polyglot persistence — разные сервисы используют разные базы. Например, key-value для caching в Redis, graph для fraud detection в Neo4j. Учитывайте latency: NoSQL часто использует in-memory storage для sub-millisecond отклика, но требует мониторинга quorum (кворума реплик) для consistency. В hybrid подходах сочетают SQL для транзакций и NoSQL для scale-out.
#Java #middle #on_request #no_sql_db
Что такое NoSQL и почему они появились
NoSQL базы данных — это нереляционные системы, которые хранят информацию не в табличной форме. Они возникли в 2000-х годах благодаря компаниям вроде Google и Amazon, чтобы обрабатывать петабайты данных в распределенных системах. В отличие от реляционных баз, как MySQL или PostgreSQL, NoSQL не требуют предопределенной схемы данных, что упрощает разработку и изменения.
Отличия от реляционных баз
Реляционные базы используют таблицы, где данные организованы в строки и столбцы с отношениями через ключи. Они следуют ACID-принципам: атомарность (все или ничего), согласованность, изоляция и долговечность. NoSQL, напротив, часто следуют BASE-модели: базовая доступность, мягкое состояние и eventual consistency. Это значит, что данные могут быть временно несогласованными, но система всегда доступна. NoSQL лучше масштабируется горизонтально, добавляя дешевые серверы, в то время как SQL — вертикально, улучшая один сервер.
Что такое NoSQL базы данных?
NoSQL (от "not only SQL") — это класс баз данных, которые не придерживаются строгой реляционной модели. В отличие от классических баз, где данные хранятся в таблицах с фиксированными столбцами и строками, NoSQL позволяют работать с данными в более естественной форме. Термин "NoSQL" появился в конце 1990-х, но настоящий бум пришелся на 2000-е годы благодаря компаниям вроде Google (с их BigTable) и Amazon (Dynamo). Эти системы предназначены для обработки огромных объемов данных в распределенных средах, где традиционные базы дают сбой из-за масштаба.
NoSQL фокусируются на горизонтальной масштабируемости (sharding — разделение данных по серверам) и отказоустойчивости. Они часто реализуют распределенные архитектуры с репликацией (копированием данных на несколько узлов), что обеспечивает высокую доступность. Однако это требует понимания trade-off'ов, таких как потеря строгой consistency в пользу availability, как описано в CAP-теореме Эрика Брюера: в распределенной системе можно гарантировать только два из трех свойств — Consistency (согласованность), Availability (доступность) и Partition tolerance (устойчивость к разделению сети). Большинство NoSQL выбирают AP (availability + partition tolerance), жертвуя immediate consistency.
Где применяются NoSQL базы данных
NoSQL shine в сценариях с высокой нагрузкой и разнообразными данными. Они доминируют в web 2.0 и cloud-native приложениях.
- Big Data и аналитика: Для обработки петабайт данных, как в Hadoop-экосистемах. Пример: HBase для хранения логов в Facebook.
- Реал-тайм приложения: Социальные сети (Twitter использует Cassandra для timeline), рекомендации (Netflix с DynamoDB-подобными системами).
- IoT и сенсорные данные: Миллионы устройств генерируют неструктурированные данные; NoSQL справляется с velocity (скоростью поступления).
- E-commerce: Управление каталогами, сессиями, корзинами. Amazon DynamoDB для Black Friday трафика.
- Мобильные и гейминг apps: Redis для лидербордов, MongoDB для пользовательских профилей.
- Контент-менеджмент: CMS вроде WordPress на MongoDB для динамического контента.
В микросервисах NoSQL поддерживает polyglot persistence — разные сервисы используют разные базы. Например, key-value для caching в Redis, graph для fraud detection в Neo4j. Учитывайте latency: NoSQL часто использует in-memory storage для sub-millisecond отклика, но требует мониторинга quorum (кворума реплик) для consistency. В hybrid подходах сочетают SQL для транзакций и NoSQL для scale-out.
#Java #middle #on_request #no_sql_db
👍7
Основные типы и виды NoSQL баз
NoSQL классифицируют по модели данных. Вот четыре основных типа с примерами и применениями.
1. Key-Value stores (хранилища ключ-значение)
Самые простые, как словарь в Python. Ключ — уникальный идентификатор, значение — любой blob данных (строка, объект). Нет сложных запросов, только get/set по ключу.
- Преимущества: Высокая скорость, простота, отличны для caching.
- Недостатки: Нет поддержки сложных поисков без индексов.
- Примеры: Redis (in-memory, поддерживает pub/sub), Amazon DynamoDB (managed, с auto-scaling).
- Применения: Сессии пользователей, временные данные, как в онлайн-играх.
2. Document stores (документные базы)
Хранят данные как документы (JSON, BSON, XML). Каждый документ — самодостаточный, с вложенными структурами.
- Преимущества: Гибкость, естественное маппинг на объекты в коде, поддержка индексов и aggregation.
- Недостатки: Могут быть неэффективны для глубоких joins.
- Примеры: MongoDB (с MQL-запросами, sharding), CouchDB (фокус на replication для offline-first apps).
- Применения: CMS, e-commerce каталоги, где схема эволюционирует.
3. Column-family stores (столбцовые или wide-column базы)
Данные в таблицах, но столбцы динамические и группируются в семьи. Эффективны для sparse data (много null).
- Преимущества: Масштабируемость для write-heavy нагрузок, compression столбцов.
- Недостатки: Сложные для ad-hoc запросов.
- Примеры: Apache Cassandra (ring-архитектура, tunable consistency), HBase (на Hadoop, для time-series).
- Применения: Логи, аналитика, социальные фиды.
4. Graph databases (графовые базы)
Данные как узлы (nodes), ребра (edges) и свойства. Идеальны для traversal (проход по связям).
- Преимущества: Быстрые запросы на отношения (e.g., "друзья друзей"), алгоритмы вроде shortest path.
- Недостатки: Меньше подходит для простых CRUD.
- Примеры: Neo4j (Cypher язык, ACID-транзакции), ArangoDB (multi-model, сочетает document+graph).
- Применения: Социальные сети, рекомендации, knowledge graphs в AI.
#Java #middle #on_request #no_sql_db
NoSQL классифицируют по модели данных. Вот четыре основных типа с примерами и применениями.
1. Key-Value stores (хранилища ключ-значение)
Самые простые, как словарь в Python. Ключ — уникальный идентификатор, значение — любой blob данных (строка, объект). Нет сложных запросов, только get/set по ключу.
- Преимущества: Высокая скорость, простота, отличны для caching.
- Недостатки: Нет поддержки сложных поисков без индексов.
- Примеры: Redis (in-memory, поддерживает pub/sub), Amazon DynamoDB (managed, с auto-scaling).
- Применения: Сессии пользователей, временные данные, как в онлайн-играх.
2. Document stores (документные базы)
Хранят данные как документы (JSON, BSON, XML). Каждый документ — самодостаточный, с вложенными структурами.
- Преимущества: Гибкость, естественное маппинг на объекты в коде, поддержка индексов и aggregation.
- Недостатки: Могут быть неэффективны для глубоких joins.
- Примеры: MongoDB (с MQL-запросами, sharding), CouchDB (фокус на replication для offline-first apps).
- Применения: CMS, e-commerce каталоги, где схема эволюционирует.
3. Column-family stores (столбцовые или wide-column базы)
Данные в таблицах, но столбцы динамические и группируются в семьи. Эффективны для sparse data (много null).
- Преимущества: Масштабируемость для write-heavy нагрузок, compression столбцов.
- Недостатки: Сложные для ad-hoc запросов.
- Примеры: Apache Cassandra (ring-архитектура, tunable consistency), HBase (на Hadoop, для time-series).
- Применения: Логи, аналитика, социальные фиды.
4. Graph databases (графовые базы)
Данные как узлы (nodes), ребра (edges) и свойства. Идеальны для traversal (проход по связям).
- Преимущества: Быстрые запросы на отношения (e.g., "друзья друзей"), алгоритмы вроде shortest path.
- Недостатки: Меньше подходит для простых CRUD.
- Примеры: Neo4j (Cypher язык, ACID-транзакции), ArangoDB (multi-model, сочетает document+graph).
- Применения: Социальные сети, рекомендации, knowledge graphs в AI.
#Java #middle #on_request #no_sql_db
👍6
Предлагаем темы для разбора и публикации! 📖
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
🟢 темы, не выше уровня middle, чтоб был интерес общим.
🟢 Один человек - одна тема.
🟢 Тема должна быть отдельным теоретически-практическим вопросом. Готовый проект - это не тема!
Жду Ваших предложений!👏
В комментариях к данному посту предлагайте вопросы, которые вы хотели бы увидеть максимально подробно разобранными в постах, а если будет интересно то и на видео.
Голосование будет проводиться всю неделю, а статья или видео - выходить по выходным.
Примерные правила:
Жду Ваших предложений!
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Выбираем темы для рассмотрения в следующие выходные! 🤨
Anonymous Poll
28%
AOP
15%
Введение в Camunda
31%
Введение в Kubernetes
26%
Введение в реактивное программирование в Java
👍1
Уиллис Уэр (31 августа 1920 г. Атлантик-Сити, Нью-Джерси – 22 ноября 2013 г. Санта-Моника, Калифорния) — повлиял на многие аспекты вычислений, включая инициирование и направление одного из первых компьютерных курсов в UCLA и автором некоторых из первые учебники в области компьютерной безопасности. Кроме того, он возглавлял несколько влиятельных исследований, в том числе одно, проведенное в 1967 году, в результате которого был подготовлен новаторский и трансформирующий отчет для Совета по оборонным наукам для ARPA (ныне DARPA ), который впоследствии был известен как «The Ware Report. "
Жан-Даниэль Нико (родился 31 августа 1938 года) — швейцарский пионер вычислительной техники и робототехники, автор ранних оптических мышей и учебных роботов.
1966 — В Нью-Йорке начался первый шахматный турнир между компьютерами. За три года до этого состоялся матч между советскими и американскими электронными шахматистами, в котором победила советская сторона. В 1974 году уже прошёл первый чемпионат мира, в котором победу также одержала советская программа «Каисса».
#Biography #Birth_Date #Events #31Августа
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Предлагаю сегодня собраться! Пообсуждать наболевшее и просто интересное. Часиков в 16 по МСК
Anonymous Poll
73%
Да я приду поболтать) 👍
9%
Не, не интересно 🗿
18%
Как я оказался в этой группе? 😱
👍1
Трекер времени: кандалы или инструмент свободы?
Условия которые мне предложили
Самый важный вопрос на котором девушка с милым голосом решила остановиться - а готов ли я вообще работать с трекером.
И это оказалось наверно самым сложным.
Я конечно безапелляционно соврал, что да. Но внутри все вопило - "БЕЖИМ, бл" 😂. Все таки интересно послушать условия.
Итак, что такое трекер:
- На Вашу или выданную компанией машину, устанавливается приложение в котором Вы при начале работы запускаете и при окончании отключаете трекинг.
- Руководитель и заинтересованные лица имеет к нему доступ.
- Кроме того оно в рандомном режиме делает скриншоты вашего экрана (тут от HR последовал рассказ о пойманных работников - обманщиков, но не тех кто писал код с LLM😂 )
- Включать и выключать трекинг рабочего времени можно в любое удобное для Вас время, главное чтобы по итогу в месяц набралось необходимое количество часов.
Трекает и скриншотит ли все остальное время это приложения - история умалчивает.
Затравка для размышлений
На мой взгляд, программист — не кассир и не водитель такси. Его работа творческая, её практически невозможно измерить только часами. Как будет считаться время на поиск "красивого", а не быстрого решения?
Ведь это окажется субъективной оценкой руководителя, на основе которой могут и уволить.
А что если я включил трекер и читаю книгу, к примеру по Спрингу? Работаю? - работаю. Видно результаты? - нет🤣 . Докажите обратное? Но в трудовом кодексе нет презумпции невиновности. Решит руководитель, что ты бездельничал - и здравствуй HH.
И понятно, что "Кампания" требует цифр: менеджеру нужны отчёты, заказчику — бюджеты, компании — предсказуемость и возможность рассчитать время на ту или иную фичу. И тотальный контроль по сути может это значительно ускорить.
Отсюда вопросы которые у меня возникли:
🔜 трекинг времени - это инструмент контроля или инструмент развития?
🔜 насколько законно увольнение на основе трекера?
🔜 и кто вообще согласен на такое?
HR конечно пыталась убедить меня, что к этому быстро привыкаешь, что еще никого не уволили за бездельничество и в целом никто не смотрит на результаты трекера, а важны лишь результаты работы.
Но отчего-то я ей не поверил...
Плюсы и минусы работы с трекером для разработчика
➕
Осознанность: видишь, куда реально утекает твой день. Иногда полдня жрут встречи и попытка понять документацию.
Фокус: легче отслеживать прокрастинацию и возвращать себя в работу, потому, что помнишь о надзоре.
Данные для переговоров: если лид говорит почему так долго - у тебя есть история: вот 12 часов тестов и багфиксов.
➖
Давление и стресс: ощущение, что за тобой следят каждую минуту. Убивает.
Фальшивая эффективность: начинаешь набивать часы, а не реально решать задачи.
Творчество под рубильник: сложно засечь, сколько времени ушло на придумку архитектуры или рефакторинг.
Неформальные задачи теряются: созвоны, менторство, обсуждения коллег — вроде бы работа, а в трекере пустота.
В целом для себя я решил, что пойду работать с трекером только если совсем прижмет.
И для каждого на самом деле это наверно личный выбор.
Кому - то не страшны скриншоты рабочего экрана, так как он честный и трудолюбивый😏
А кто-то (как сказала HR) - "привык работать по 3 часа и нам такие не нужны!". Вот же негодник какой😄
А что касается законности, читайте договор, должностную инструкцию или внутренний регламент:
Если компания документально закрепила за вами обязанность фиксировать время и его не нарушать, ознакомила под подпись, то в этом случае уволить могут за систематическое неисполнение обязанностей (ст. 81 ТК РФ).
А что вы думаете об этом?
Понравилась статья - поделись с другом, позови его на канал и будет тебе моя благодарность 🤝
😎
#motivation
Сегодня будет наверно не мотивационная статья, а больше статья - размышление...
Намедни в одном из созвонов с HR, мне предложили работу с трекером времени.
Скажу сразу, опыта работы с подобным у меня не было и я глубоко задумался, а каково это вообще?
Конечно, те кто вкусил этой организации работы могут в пух и прах разбить мои доводы, но я пожалуй поразмышляю.
Условия которые мне предложили
Самый важный вопрос на котором девушка с милым голосом решила остановиться - а готов ли я вообще работать с трекером.
И это оказалось наверно самым сложным.
Я конечно безапелляционно соврал, что да. Но внутри все вопило - "БЕЖИМ, бл" 😂. Все таки интересно послушать условия.
Итак, что такое трекер:
- На Вашу или выданную компанией машину, устанавливается приложение в котором Вы при начале работы запускаете и при окончании отключаете трекинг.
- Руководитель и заинтересованные лица имеет к нему доступ.
- Кроме того оно в рандомном режиме делает скриншоты вашего экрана (тут от HR последовал рассказ о пойманных работников - обманщиков, но не тех кто писал код с LLM
- Включать и выключать трекинг рабочего времени можно в любое удобное для Вас время, главное чтобы по итогу в месяц набралось необходимое количество часов.
Трекает и скриншотит ли все остальное время это приложения - история умалчивает.
Затравка для размышлений
На мой взгляд, программист — не кассир и не водитель такси. Его работа творческая, её практически невозможно измерить только часами. Как будет считаться время на поиск "красивого", а не быстрого решения?
Ведь это окажется субъективной оценкой руководителя, на основе которой могут и уволить.
А что если я включил трекер и читаю книгу, к примеру по Спрингу? Работаю? - работаю. Видно результаты? - нет
И понятно, что "Кампания" требует цифр: менеджеру нужны отчёты, заказчику — бюджеты, компании — предсказуемость и возможность рассчитать время на ту или иную фичу. И тотальный контроль по сути может это значительно ускорить.
Отсюда вопросы которые у меня возникли:
HR конечно пыталась убедить меня, что к этому быстро привыкаешь, что еще никого не уволили за бездельничество и в целом никто не смотрит на результаты трекера, а важны лишь результаты работы.
Но отчего-то я ей не поверил...
Плюсы и минусы работы с трекером для разработчика
Осознанность: видишь, куда реально утекает твой день. Иногда полдня жрут встречи и попытка понять документацию.
Фокус: легче отслеживать прокрастинацию и возвращать себя в работу, потому, что помнишь о надзоре.
Данные для переговоров: если лид говорит почему так долго - у тебя есть история: вот 12 часов тестов и багфиксов.
Давление и стресс: ощущение, что за тобой следят каждую минуту. Убивает.
Фальшивая эффективность: начинаешь набивать часы, а не реально решать задачи.
Творчество под рубильник: сложно засечь, сколько времени ушло на придумку архитектуры или рефакторинг.
Неформальные задачи теряются: созвоны, менторство, обсуждения коллег — вроде бы работа, а в трекере пустота.
В целом для себя я решил, что пойду работать с трекером только если совсем прижмет.
И для каждого на самом деле это наверно личный выбор.
Кому - то не страшны скриншоты рабочего экрана, так как он честный и трудолюбивый
А кто-то (как сказала HR) - "привык работать по 3 часа и нам такие не нужны!". Вот же негодник какой
А что касается законности, читайте договор, должностную инструкцию или внутренний регламент:
Если компания документально закрепила за вами обязанность фиксировать время и его не нарушать, ознакомила под подпись, то в этом случае уволить могут за систематическое неисполнение обязанностей (ст. 81 ТК РФ).
А что вы думаете об этом?
#motivation
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍2👎1