When you're asking AI chatbots for answers, they're data-mining you
- Security: киберпреступность, патчи, исследования, CSO
- Off-Prem: edge + IoT, канал, PaaS/IaaS, SaaS
- On-Prem: системы, хранение, сети, HPC, персональные технологии, CxO, госсектор
- Software: ИИ + ML, приложения, БД, DevOps, ОС, виртуализация
- Offbeat: дебаты, колонки, наука, юмор, юр. новости, блоги
- Спецпроекты: месяц облачной инфраструктуры, сети ЦОД, хранение, европейские суперкомпьютеры, ИИ-инфраструктура, RSAC, разработка ИИ, аварийное восстановление, GTC Nvidia, ransomware, будущее ЦОД, кибербезопасность, VMware Explore
- Vendor Voice: Siemens + AWS, Mendix + AWS, финансовые потоки, BigQuery, AWS Global Partner Security, GE Vernova
- Ресурсы: whitepapers, вебинары, рассылки
Комментарии (53)
- Все, что вы отправляете в онлайн-сервисы (AI, почта, соцсети), сохраняется навсегда и может быть использовано против вас.
- Большинству пользователей всё равно: удобство «бесплатных» сервисов перевешивает риски.
- Есть альтернатива — локальные модели (Ollama, LM Studio, Oobabooga), но они требуют мощного железа и навыков.
- Даже если вы не пользуетесь сервисом, друзья могут передать ваши данные через чат-ботов.
- Пока не появится жёсткое регулирование, единственный надёжный способ — не делиться чувствительной информацией и минимизировать использование облачных AI.
ClickHouse matches PG for single-row UPDATEs and 4000 x faster for bulk UPDATEs
ClickHouse vs PostgreSQL: UPDATE-скорость
- Коротко: на одном железе ClickHouse догоняет PostgreSQL в одиночных UPDATE и в 4 000 раз быстрее при массовых.
- Почему: колоночное хранилище + параллелизм ClickHouse выигрывает у строкового PostgreSQL при поиске и перезаписи миллионов строк.
- Но: PostgreSQL всегда транзакционен; ClickHouse — нет, поэтому сравнение по «родным» режимам, а не по ACID.
Что мерили
- 1 строка:
UPDATE orders SET status='shipped' WHERE id=1234567 - 1 млн строк:
UPDATE orders SET discount=0.1 WHERE order_date<'2023-01-01'
Аппаратура
- c6i.8xlarge (32 vCPU, 64 ГБ RAM, gp3 SSD)
- PostgreSQL 16.4 (дефолт +
fillfactor=90,checkpoint_timeout=30 min) - ClickHouse 25.7 (дефолт)
Результаты
| метрика | PostgreSQL | ClickHouse |
|---|---|---|
| 1 строка, мс | 0.12 | 0.11 |
| 1 млн строк, сек | 120 | 0.03 |
| CPU, % | 100 | 2800 |
| чтение, ГБ | 30 | 0.8 |
Почему так
- Поиск: ClickHouse читает только нужные колонки, фильтрует за счёт индексов и распараллеливает на все ядра.
- Запись: обе СУБД пишут новые версии строк (MVCC), но PostgreSQL переписывает целые страницы, а ClickHouse — только изменённые куски колонок.
- Фоновая работа: PostgreSQL ждёт checkpoint’а, ClickHouse сразу сортирует и сжимает куски.
Когда выбирать
- Нужны транзакции и row-level locks → PostgreSQL.
- Нужны массовые обновления аналитических данных → ClickHouse.
Код и данные
Комментарии (33)
- ClickHouse показывает огромный выигрыш в скорости обновлений, но это «яблоки-к-апельсинам»: PostgreSQL по умолчанию полностью транзакционен, а CH — нет.
- Если данные можно терять или обновления редки, CH идеален; если нужна строгая согласованность, PostgreSQL остаётся безальтернативным.
- Многие пользователи CH считают обновления адом: приходится использовать ReplacingMergeTree, версии или event-sourcing; прямых UPDATE-ов до недавнего времени вообще не было.
- Часть комментаторов предлагает сравнивать CH с DuckDB, Vertica или ScyllaDB, а также настроить PostgreSQL (synchronous_commit = off, COPY) для более честного бенчмарка.
- Авторы поста подчёркивают: цель не «победить» PostgreSQL, а показать, как каждая СУБД решает задачу в своей «родной» модели исполнения.