Как SQLite учили работать в распределенных системах
SQLite — пример для нас всех. Это маленькая и легкая СУБД, которая создавалась изначально для небольших проектов и мобильных приложений, но потенциал у нее огромный и использовать ее можно где угодно, было бы желание.
Например, в распределенных системах. Автор rqlite вспомнил, как создал свой проект и что было после него.
🔵В 2014 году ему понадобилось создать небольшое реляционное хранилище для кластерной системы. Он решил взять SQLite и прикрутить к ней протокол консенсуса Raft. В это системе В кластере был лидер, через которого новые записи принимались и реплицировались на остальные узлы. Запись должно было принять большинство, если какой-то узел не мог этого сделать, он изолировался. Так появился rqlite — один из первых проектов такого плана, но не последний.
🔵В 2017 компания Canonical разработала dqlite. Задача была похожей, а главное отличие было в способе использования. Если rqlite — это самостоятельный сервер БД, который запускается вместе с приложением, то dqlite — это встраиваемая библиотека.
🔵В 2021 году Litestream выбрали другой подход: не пытаться превратить SQLite в полноценную распределенную базу, а найти способ восстановить данные, если сервер выйдет из строя. Их решение — сохранять WAL SQLite в Amazon S3.
🔵В 2022 появилась cr-sqlite, где записи независимо вносятся на несколько узлов, а потом синхронизируются. В libSQL разработчики вообще переписали движок СУБД и за счет этого сильно расширили функционал. Из этого проекта потом выросла Turso, которую купили Supabase.
🔵Логичным следующим этапом стали облачные сервисы — например, Cloudflare D1.
В итоге можно сделать два ключевых вывода:
🔵Нет единого правильного способа создать распределенную систему. Подход зависит от задач и главной проблемы, которую вы хотите решить: например, обеспечить надежность, как в rqlite, или быстрое восстановление, как сделали Litestream.
🔵За 12 лет проекты с распределенной SQLite прошли путь от open source-решений до платных облачных сервисов от больших корпораций. Видимо, это неизбежно происходит со всеми идеями в IT.
20 лет отношений через призму данных
Если бы вам нужно было на графиках отобразить свою жизнь, как бы выглядел ваш дашборд?
В этом посте от 2014 года автор показывает жизнь как таблицу, где каждая клеточка — это год, месяц или неделя. Пост старй, вы наверняка видели раньше эти таблички хотя бы раз. Один разработчик и инженер тоже их видел, и они ему не понравились. Он решил сделать свою версию, отражающую не число прожитых дней, а то, чем они были наполнены: эмоциями и общением с людьми.
🔵Он собрал историю чатов и активности из разных соцсетей и мессенджеров за 20 лет, очистил от совсем уж бессмысленных сообщений и классифицировал: с кем разговаривал, о чем, какая была эмоциональная окраска у диалога. С классификацией помогали LLM, но даже с их участием работы было много.
🔵Данные вывел на графики, по которым стало видно, как эволюционировали отношения с разными людьми: снижалась или росла частота сообщений, менялось фоновое настроение и даже словарный запас. У близких людей он часто похожий за счет общих интересов, шуток и выражений, которые в ходу в их круге общения. Но если они отдаляются со временем, то и словарный запас меняется и в нем становится меньше пересечений.
🔵Частота, длина и содержание сообщений тоже отражают изменения в отношениях Например, с одним другом формат общения перешел от постоянных коротких переписок в течение дня к редким, но более содержательным диалогам несколько раз в месяц.
Зачем это все было надо?
Во-первых, это было интересный челлендж — структурировать 1.2 млн сообщений из нескольких разных источников.
Во-вторых, это была возможность не только посмотреть на свои отношения с людьми за 20 лет, но и на себя в них — например, автор заметил, что он любит давать советы.
Ну а в-третьих, это показало, из чего на самом деле складывается жизнь, кроме стандартной череды событий «родился, учился, женился».
Стали бы так заморачиватся? Какие метрики и данные вы выбрали бы для себя — тоже отношения или что-нибудь другое?
Clickhouse на больших объемах данных: опыт основателя Tinybird
Tinybird — аналитическая платформа для разработчиков. Один из ее создателей поделился опытом, как он развернул и 5 лет поддерживал кластер Clickhouse, где хранились и обрабатывались петабайты данных, и не сошел с ума.
В двух постах (первый, второй) он рассказал про архитектуру, хранение и загрузку данных, обновление и тестирование.
Несколько любопытных мыслей:
🔵Традиционный подход к работе с большими данными предполагает деление кластера на шарды, но автор считает, что с этим лучше не спешить и не усложнять архитектуру. Tinybirds долго обходились без шардирования: увеличивали мощность отдельных серверов и добавляли реплики, когда росла нагрузка.
🔵ClickHouse поддерживает zero-copy replication: реплики могут обращаться к данным, которые хранятся в других репликах, не копируя их. Хотя это экономит место в хранилище, в опен-сорсном ClickHouse этот подход реализован не слишком удачно и часто приводит к ошибкам или потере данных. Tinybird используют модифицированный вариант zero-copy replication, который разработали сами. Всем остальным автор рекомендует следить за сохранностью данных либо выбрать другой подход к хранению.
🔵Чтобы научиться обновлять кластер без критических ошибок, потери данных и падения производительности, команде проекта понадобилось 4 года. Это сложный процесс, который за один раз не построишь.
🔵Чтобы эффективно использовать ClickHouse (и заодно избежать неприятных сюрпризов во время обновления), надо читать исходный код.
PostgreSQL 19 откладывается на ноябрь
Новая версия должна была выйти в конце сентября/начале октября, но дату релиза сдвинули на 19 ноября. Также решили откатить почти 10 ранее анонсированных функций. Их перенесут, скорее всего, в PostgreSQL 20.
Почему так получилось, рассказал у себя в блоге один из главных контрибьюторов проекта Питер Айзентраут. Частично, конечно, в сложившейся ситуации можно обвинить человеческий фактор и банальные ошибки в коде, но повлияли и другие причины:
🔵ИИ нашел множество багов — намного больше, чем тестировщики выловили бы своими силами. Среди них были и серьезные архитектурные дефекты, и пограничные случаи, которые постепенно всплывали бы на протяжении лет после релиза. Даже при том, что часть их починить относительно легко, в целом объем работы получился слишком большой.
🔵Vulnpocalypse («апокалипсис уязвимостей», найденных в софте благодаря ИИ) отвлек часть разработчиков от работы над Postgres. Из-за этого многие баги были обнаружены так поздно. Если бы у команды было больше времени и ресурсов, они могли исправить часть недочетов и, возможно, им не пришлось бы откатывать так много функций сразу.
В общем, это был амбициозный релиз, который подвел неудачный тайминг. Но несмотря на эти сложности PostgreSQL 19 обещает быть интересным и привнесет несколько интересных новшеств — пусть и меньше, чем планировалось изначально (pg_plan_advice, кстати не порезали!).
До Claude и ChatGPT
Пару лет назад ИИ не мог посчитать, сколько букв a в strawberry, а теперь решает математические задачи тысячелетия — а что будет дальше, и представить сложно. Хотя некоторые представили и предсказали, что он нас всех уничтожит к 2030 году.
И чем быстрее развиваются современные технологии, Тем интереснее сравнить их с ранними попытками создать искусственный интеллект. Internet Archive сделали целую подборку старых программ с прото-ИИ: чат-ботов, демо-моделей, игр. Есть даже прародительница Sims и «Хоббит», где персонажи действуют самостоятельно и настолько непредсказуемо, что могут даже запороть игроку прохождение.
Конечно, этот ИИ ужасно далек от того, что есть сейчас, и даже от первых глуповатых версий современных LLM, но амбициозность некоторых проектов все равно впечатляет.
А как вы представляли себе ИИ до Claude, ChatGPT, Gemini и всех остальных?
Пользователь reddit проанализировал данные, собранные телескопом TESS, и обнаружил, что звезда на расстоянии 116 лет от нас каждые 3,18 дня становится на 0,05% тусклее. Вместе с Opus 5.5 и Fable 5.1 он прошерстил информацию за все годы наблюдений, начиная с 2018, и увидел, что этот цикл повторяется на протяжении всех этих лет.
Возможной причиной этих периодических затемнений может быть планета примерно в полтора раза больше Земли. А может и не быть — эта гипотеза пока не подтверждена, но, возможно, скоро мы узнаем об этом небесном теле чуть-чуть больше.
В ноябре NASA опять вернется к наблюдению за этим участком неба, и автор поста написал им о своей находке и попросил сделать несколько снимков этой звезды с промежутком в 2 минуты. И в NASA согласились! Автор (и Claude) уже сделал расчеты, когда должно быть видно мерцание звезды, и если на снимках его будет видно, это станет очередным подтверждением его теории.
Он даже сделал 3D-модель системы. На ней видно звезду и две предполагаемые планеты: А, про которую идет речь в посте, и B, про которую данных у него пока совсем мало.
Вот такой небанальный способ использовать ИИ, где никто никого не взломал.
4 уровня ИИ-осведомленности
Еще в апреле Андрей Карпаты (автор термина «вайбкодинг», если забыли) писал о том, как растет разница в понимании возможностей ИИ. Те, кто пользуется бесплатными версиями для простых задач, и те, кто пользуется платными моделями для работы и научной деятельности, говорят про ИИ на разных языках.
Сейчас разрыв только вырос, и это больше не две разных группы, а резко сужающаяся воронка. По его прикидкам, она выглядит так:
🔵~75% или 6 млрд людей с ИИ почти не сталкивались.
🔵~20% или 1-2 млрд — «казуалы», которые используют бесплатные продукты, с ИИ в общем знакомы, но глубоко в тему не погружены. Эти люди просят ChatPGT написать письмо, и больше им ничего особо не надо.
🔵~0,2% или или 20 млн — профессионалы, которые активно используют ИИ для работы и видят, как он быстро он меняется и каковы его возможности. Они с помощью ИИ решают за несколько дней задачи, которые раньше отняли бы у них недели или месяцы.
🔵~0,00006% или 5000 — это люди на самом острие ИИ-науки, у которых есть доступ к самым передовым системам. Они имеют дело с «роями» из множества агентов, решающих сложнейшие задачи, на которые у специалистов ушли бы годы.
Движение по воронке обуславливается сложностью задач, уровнем доступа и тем, что во всех сферах ИИ одинаково полезен. Он наиболее востребован в программировании и математике, именно потому что именно там он показывает лучшие (и наиболее измеримые) результаты.
Получается, что сегодня ИИ — это одновременно и глуповатый чатбот, и стремительно развивающаяся, меняющая мир технология.