Hacker News Digest

Исследователь обнаружил критические уязвимости в системах крупнейшего индийского автопроизводителя Tata Motors. Два открытых ключа AWS на публичных сайтах позволили получить доступ к более чем 70 ТБ чувствительных данных. На сайте E-Dukaan (маркетплейс запчастей) ключи были в открытом виде, раскрывая базы данных клиентов, финансовые отчеты и административные документы. На платформе FleetEdge ключи были зашифрованы, но легко расшифрованы на стороне клиента для загрузки всего 4 КБ налоговых кодов.

Также были найдены серьезные проблемы безопасности в системе Tableau с бэкдором, позволявшим входить без пароля от имени любого пользователя, включая администратора, и скомпрометированный ключ API Azuga, затронувший систему управления тестовым автопарком. Все уязвимости были исправлены, и данных не было похищено. Tata Motors, несмотря на статус крупнейшего автопроизводителя Индии, остается малоизвестным в США.

• Tata Motors, TCS и другие компании группы Tata оказались в центре скандала из-за утечки ключей AWS, что, по слухам, могла стоить экономике Великобритании 2.5 млрд фунтов.
• Проблема в том, что ключи были в открытом доступе на сайтах этих компаний, и, несмотря на то, что их обнаружили и сообщили о них, Tata Motors не проявила никакой инициативы по их отзыву до тех пор, пока не прошло 3 месяца.
• В обсуждении также поднимается вопрос о том, что в Индии в целом и в компаниях Tata в частности культура безопасности оставляет желать лучшего.
• Кроме того, обсуждается влияние этой ситуации на восприятие Индийских компаний в технологическом секторе и на рынке труда.

Компания EvE Bio создала первую всеобъемлющую базу данных о побочных эффектах всех одобренных FDA лекарств, охватывающую взаимодействия примерно 1600 препаратов с ключевыми человеческими клеточными рецепторами. Этот уникальный ресурс, доступный под CC-NA лицензией, представляет собой прорыв в понимании того, как лекарства влияют на организм помимо своих основных механизмов действия. Традиционно фармацевтические компании фокусируются исключительно на основном эффекте препаратов, игнорируя побочные взаимодействия, если они не мешают основному терапевтическому действию.

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

• Авторы статьи подразумевают, что фармкомпании не учитывают побочные эффекты, хотя на практике токсикологические исследования являются критическим этапом разработки любого препарата.
• Набор данных не включает контролируемые вещества, что ставит под сомнение его полноту и честность.
• Данные не покрывают такие важные параметры, как объем распределения, метаболизм CYP450, транспорт через BBB и т.д., что ограничивает его полезность для исследователей.
• Набор данных не содержит структур: самые важные вещества, такие как тестостерон, ампетамины или метилфенидат, что ставит под сомнение его полезность для исследований.

/dev/null в Unix-системах с юмором представлена как база данных, полностью соответствующая принципам ACID. Атомарность обеспечивается тем, что любые записанные данные либо полностью исчезают, либо не записываются вовсе. Согласованность поддерживается инвариантом пустоты — файл всегда остаётся в одинаковом состоянии, независимо от операций. Изолированность проявляется в том, что множественные процессы могут одновременно писать в /dev/null без конфликтов, так как данные никогда не сохраняются. Долговечность гарантирует, что после сбоя система сохраняет своё главное свойство — полное отсутствие данных.

Эта шуточная статья подчёркивает, что /dev/null идеально соответствует всем требованиям ACID-совместимой базы данных, с единственным недостатком — нулевым объёмом хранения. Автор иронизирует, что для расширения пространства нужно обратиться в "корпоративные продажи", которые на самом деле являются им самим. Этот пример демонстрирует, как технические концепции можно рассматривать с неожиданной и забавной стороны.

• Обсуждение вокруг /dev/null как "база данных" выявило, что это скорее метафора, чем реальная технология, и подчеркнуло важность различать хранилище и СУБД.
• Участники обсуждали, что /dev/null не является базой данных, но при этом подчеркнули, что он обеспечивает ACID-свойства и масштабируемость.
• Были подняты вопросы о масштабируемости, отказоустойчивости и соответствии с ACID, а также о том, что такое "база данных" и как она отличается от просто носителя.
• Участники также обсудили, что /dev/null действительно обеспечивает высокую доступность и согласованность, но не является базой данных в строгом смысле.

Статья представляет пошаговое руководство по созданию простой key-value базы данных с нуля. Начальный подход предполагает хранение данных в обычном файле, где каждая строка содержит пару ключ-значение. Однако такой метод неэффективен для обновлений и удалений, так как требует перемещения всех последующих данных. Решением становится использование append-only файла, где записи являются неизменяемыми, а обновления и удаления обрабатываются через добавление новых записей и специальные "надгробные" метки.

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

• Обсуждение охватывает вопросы от дизайна и UX до фундаментальных концепций, таких как ACID, индексы и LSM-деревья, и даже до того, что не стоит писать свою СУБД, если можно использовать готовую.
• Участники обмениваются советами по инструментам вроде riak_core и Bitcask, обсуждают проблемы репликации и отказоустойчивости, и делятся личными историями о том, как они писали свои собственные базы данных.
• Некоторые комментарии поднимают вопросы о правильном подходе к обучению и документации, а также о том, как сделать так, чтобы читатели могли бы легко следить за обсуждением и не теряли нитку.
• Некоторые участники делятся ссылками на полезные ресурсы, такие как "Designing Data-Intensive Applications" и "Build Your Own Database".
• Некоторые участники поднимают вопросы о том, как лучше всего подавать контент, чтобы он был интерактивным и в то же время не перегружал читателя, и обсуждают, как лучше всего структурировать и визуализировать информацию.
• Некоторые участники делятся личными историями о том, как они писали свои собственные базы данных, и обсуждают, какие вызовы они встретились и как они их преодолели.

• Проблема с DISTINCT часто указывает на плохое моделирование данных или непонимание теории множеств.
• Использование DISTINCT для "исправления" дубликатов часто является симптомом плохой архитектуры БД или неправильного использования JOIN.
• Создание вьюх на вьюхах может привести к проблемам с производительностью и читаемости кода.
• Использование CASE WHEN вместо отдельной таблицы для статусов может усложнить поддержку и интернационализацию.
• Не используйте SELECT * в продакшене; это может сломать код, если схема изменится.

PostgreSQL может быть как чтением, так и записью интенсивной в зависимости от бизнес-логики приложения. Для социальных сетей характерно чтение интенсивное, а для IoT логгеров — запись интенсивная. Определение профиля нагрузки критично для эффективной настройки: чтение интенсивные БД выигрывают от индексации, кэширования запросов и реплик, тогда как запись интенсивные требуют оптимизации хранилищ, управления WAL и дизайна таблиц.

Чтения и записи в PostgreSQL не равны по стоимости: чтение происходит 8kb блоками, часто из памяти, в то время как запись включает WAL, индексы, TOAST таблицы и требует больше ресурсов. Автор предлагает запрос для оценки соотношения чтения/записи на основе внутренних метаданных PostgreSQL, где по умолчанию используется соотношение 5:1 (чтение:запись).

• Обсуждение критикует статью за то, что она не сравнивает PostgreSQL с другими СУБД и не дает практических советов по тюнингу под конкретную нагрузку.
• Участники обсуждают, что статья не учитывает, что большинство приложений имеют смешанную нагрузку на чтение и запись, а не чисто чтение или запись.
• Некоторые комментаторы отмечают, что статья не упоминает OLTP и OLAP, что делает ее менее полезной для практического использования.
• Также обсуждается, что статья не дает ясного определения, что считается "read-heavy" или "write-heavy" в контексте PostgreSQL.
• Наконец, участники обсуждают, что статья не предоставляет конкретных советов по тюнингу PostgreSQL под конкретную нагрузку.

PostgreSQL 18 представляет поддержку UUIDv7, нового типа универсально уникальных идентификаторов, решающего проблемы производительности традиционных UUIDv4. В отличие от полностью случайного UUIDv4, UUIDv7 включает временную метку как наиболее значимую часть своей 128-битной структуры, обеспечивая естественную сортировку по времени создания. Это открывает возможности для более эффективного использования UUID в качестве первичных ключей в базах данных.

В статье демонстрируется сравнительный анализ производительности между UUIDv4 и UUIDv7 через создание двух таблиц для "магазина крабов" с использованием Aiven for PostgreSQL. Авторы предоставляют практические примеры кода для создания сервиса и таблиц, а также функцию для вставки случайных данных. Тесты показывают, что UUIDv7 может значительно улучшить производительность операций вставки по сравнению с UUIDv4, особенно при работе с большими объемами данных.

• UUIDv7 раскрывает время создания записи, что может быть критично для приватности и безопасности, особенно если первичный ключ публично доступен.
• Эксперты рекомендуют использовать UUIDv7 только для внутренних ключей и выставлять отдельный UUIDv4 как публичный идентификатор.
• Но в большинстве случаев, когда выбор между UUIDv7 и v4, важно учитывать, что v7 предоставляет лучшую производительность при вставке и сортировке, но требует дополнительных усилий для защиты приватности.

2020-09-22 22:00 hours CST (UTC+8) and 3:00 pm CST (UTC+8) respectively. They are the same as 2019-08-31 15:00:00 UTC+8 (UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+8:00 UTC+16:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 UTC+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32:00 TV+32

dddddddddddddddddduuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuhuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuhuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuu.uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu1uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuu uuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuu

SQLite использует составные индексы слева направо, без пропусков, останавливаясь на первом диапазонном условии. Например, если индекс включает столбцы A, B, C, а запрос содержит A BETWEEN x AND y AND B = z, оптимизатор сможет использовать только A для фильтрации по диапазону, затем просканирует все подходящие строки для B, игнорируя C. Это объясняет, почему добавление отдельных индексов на каждый столбец бесполезно — SQLite редко объединяет их.

Ключевой вывод: порядок столбцов в индексе критичен. Первым должен идти самый селективный столбец, но если на нём используется диапазон (например, BETWEEN или <=), последующие столбцы в индексе не будут эффективно фильтроваться. Для запросов с несколькими условиями лучше создать индекс, где диапазонные условия стоят последними, чтобы максимизировать использование индекса.

• Критика статьи за отсутствие технической глубины и общие заблуждения о работе индексов, не специфичных для SQLite.
• Обсуждение ментальных моделей индексов как вложенных карт или отсортированных списков, объясняющих важность порядка колонок и ограничения диапазонных запросов.
• Замечания о простоте планировщика запросов SQLite по сравнению с другими СУБД, но признание его адекватности для базовых сценариев.
• Рекомендации по использованию официальной документации SQLite и инструментов вроде .expert для анализа индексов.
• Предостережения против автоматического добавления индексов из-за затрат на дисковое пространство и замедления записи.

PostgreSQL 18 добавляет нативную поддержку UUID v7 через функцию uuidv7(), что позволяет использовать UUID в качестве первичных ключей без потери производительности благодаря их последовательной природе. Это устраняет необходимость в сторонних расширениях или реализации генерации на уровне приложения.

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

• Участники обсуждают преимущества вычисляемых столбцов в базах данных, отмечая их полезность для миграций схем и единообразия логики между разными клиентами.
• Поднимается вопрос о производительности: выполнение вычислений на стороне БД может быть эффективнее, чем в клиентских приложениях, особенно при использовании индексов.
• Высказываются опасения о возможном злоупотреблении этой функцией и усложнении схемы, но признаётся, что иногда это единственное решение.
• Упоминается конкретный пример использования для преобразования временных зон, чтобы упростить запросы.
• Обсуждение начинается с упоминания функции pg_get_acl() и сложности составления запросов для проверки привилегий.

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

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

• Обсуждаются альтернативы Redis, такие как kvrocks, Garnet и Redka, с поддержкой хранения данных на диске и работой в условиях ограниченной памяти.
• Участники дискутируют о стабильности языка Zig для реальных проектов, отмечая частые изменения в стандартной библиотеке и отсутствие версии 1.0.
• Поднимается вопрос о названии проекта "RiiZ" и возможном нарушении торговой марки Redis из-за схожести имен.
• Отмечается, что проект является учебным для изучения Zig, а не коммерческим продуктом, и пока не поддерживает все функции Redis (например, аутентификацию, поиск ключей).
• Обсуждаются технические детали реализации памяти и деструкторов в Zig, а также возможность использования LLM для генерации кода на этом языке.

• Шутка: глиняная табличка 3100 г до н. э. — «база данных» с 5000-летним аптаймом.
• Проверил, какие даты принимают MySQL, Postgres, SQLite:
  – MySQL: мин. 1000 г н. э.
  – Postgres/SQLite: 4713 г до н. э. (юлианский календарь).
• Пример: INSERT … '4713-01-01 BC'::date работает, 4714 г до н. э. — уже ошибка.
• Вопрос: как хранить ещё более древние даты (например, экспонаты Британского музея)? Текстом, эпохой, кастомным типом?

• Самая ранняя письменность — это не литература, а счёты и квитанции: глиняные таблички фиксируют выдачу зерна и другие транзакции ~3300 г. до н. э.
• Для музейных дат «около X» нет единого числового стандарта; хранят как текст либо диапазон «start/end», а сортировку и поиск делает прикладной код.
• PostgreSQL ограничен 4713 до н. э. технически (4-байтный Julian day), но SQLite и кастомные схемы позволяют любые тексты или большие целые.
• Подавляющее большинство записей погибло: дошедшие таблички — пример survivor bias; цифровые носители вряд ли протянут 5000 лет.
• Пиво/ферментация упоминаются как возможный первичный двигатель оседлости и учёта задолго до клинописи.

Если бы OpenDocument использовал SQLite

Мысленный эксперимент: заменить ZIP-контейнер в формате ODP на базу SQLite.
Плюсы: компактнее, быстрее открытие/сохранение, меньше памяти, встроенная версионность.

Текущий ODP

ODP-файл — это ZIP-архив с XML-файлами (content.xml, styles.xml, meta.xml, settings.xml) и папкой Pictures с ресурсами.
Пример: 49-слайдовая презентация — 78 файлов, 11 МБ.

Недостатки ZIP-контейнера

1. Сложное инкрементальное обновление
   При каждом «Сохранить» перезаписывается весь архив, что медленно и «съедает» ресурс SSD.
2. Медленный старт
   При открытии нужно распаковать и распарсить большой XML.
3. Отсутствие версионности
   Нет простого способа хранить историю изменений.
4. Избыточные данные
   Каждая картинка — отдельный файл, даже если она используется многократно.

Преимущества SQLite

• Инкрементальные изменения
  Обновляются только нужные строки; сохранение происходит мгновенно и безопасно (благодаря транзакциям).
• Мгновенный старт
  Данные уже структурированы; нет необходимости распаковывать и парсить XML.
• Встроенная версионность
  Таблицы slide_history, image_versions позволяют откатываться к любому состоянию.
• Дедупликация ресурсов
  Один и тот же рисунок хранится единожды; ссылки через image_id.
• Сжатие и индексы
  SQLite сжимает данные и строит индексы по ключам (номера слайдов, идентификаторы объектов).

Схема SQLite-документа (упрощённо)

CREATE TABLE slides(
  slide_id INTEGER PRIMARY KEY,
  title TEXT,
  xml_content BLOB,
  z_order INTEGER
);
CREATE TABLE images(
  image_id INTEGER PRIMARY KEY,
  data BLOB,
  mime_type TEXT,
  sha256 BLOB UNIQUE
);
CREATE TABLE slide_images(
  slide_id INTEGER REFERENCES slides,
  image_id INTEGER REFERENCES images,
  x REAL, y REAL, width REAL, height REAL
);
CREATE TABLE history(
  change_id INTEGER PRIMARY KEY,
  timestamp DATETIME,
  sql BLOB
);

Итог

SQLite превращает «кучу файлов» в реляционную базу: быстрее, надёжнее, экономнее.
Это не предложение переделать ODP, а идея для следующих форматов.

• SQLite как формат файла приложений: удобен для запросов, хранит всё в одном файле, но требует осторожности с безопасностью и сетевыми ФС.
• Ключевые советы: включать secure_delete, не хранить больше 2 ГиБ в BLOB, избегать работы по сети без надёжных блокировок.
• Плюсы: SQL-запросы, простота API, лёгкость инспектировать и мигрировать данные (пример — Anki).
• Минусы: сложно версионировать бинарные вставки, проблемы синхронизации/коллаборации, перезапись всего файла при малом изменении.
• Альтернативы: разделение текста и бинарников, JSON + Git, XML для обмена, CRDT-структуры для офлайн-редактирования.

Формат файла SQLite

SQLite хранит всё состояние БД в одном файле.
Размер страницы — степень двойки 512–65 536 байт; номера страниц начинаются с 1, максимум 2³²-2.
Первая страница (512–100 байт) — заголовок:

• 16 байт: «SQLite format 3\000»
• 2 байт: размер страницы
• 1 байт: версия формата, 1 байт: версия для записи
• 1 байт: резервировано под расширения
• 1 байт: макс. доля переполнения
• 4 байт: счётчик изменений
• 4 байт: размер БД (страниц)
• 4 байт: свободные страницы
• 4 байт: схема-cookie
• 4 байт: формат схемы
• 4 байт: рекомендованный кэш
• 4 байт: vacuum-настройки
• 4 байт: кодировка текста
• 4 байт: пользовательская версия
• 4 байт: ID приложения
• 4 байт: версия библиотеки, 4 байт: «valid-for»
• 20 байт: резерв

Страницы бывают:

• b-tree (таблица/индекс, внутр./лист)
• freelist (trunk/leaf)
• переполнение payload
• pointer-map (ptrmap)

Схема
SQL-таблицы → b-tree, строки — последовательность записей (varint длина + payload).
WITHOUT ROWID → ключ в b-tree, дубли в PK убираются.
Индексы → отдельный b-tree, ключи с rowid.
Системные таблицы: sqlite_master (DDL), sqlite_sequence, sqlite_stat1-4.

Журналы
Rollback-journal: старая страница + заголовок.
WAL: кадры с новыми страницами, контрольная сумма, индекс в памяти.

• SQLite хвалят за идею «один файл = база» — она перекрывает недостатки форматов и SQL.
• Формат задокументирован до байта, работает по HTTP-диапазонам и читается с NFS, если только чтение.
• Предел 281 ТБ пока недостижим; реальные ограничения — файловая система и сбои железа.
• Повреждение страницы убивает весь файл, починить нельзя — нужна обратная совместимость.
• Для «пишем один раз» советуют Parquet + DuckDB: колонковый, неизменяемый, читается любым движком.

Булево значение почти всегда маскирует более точный тип.
Проверь, не дата-время ли это: is_confirmed лучше заменить на nullable confirmed_at. Вы получите момент подтверждения и сможете анализировать баги по времени.

Если поле описывает роль или статус (is_admin, failed), превращайте в enum.

enum UserRole { User, Admin, Guest, SuperAdmin }
enum JobStatus { Queued, Started, Failed, Done }

Enum упрощает добавление новых состояний и защищает от забытых веток.

Проверка прав тоже не должна возвращать bool.

enum PermissionCheck { Allowed, NotPermitted(reason: String) }

Так код читабельнее и можно вернуть причину отказа.

Когда же использовать bool? Только как временную переменную-флаг для сложного условия, чтобы не вычислять его дважды или дать имя.

• Основной спор: стоит ли хранить «события» как булевы флаги или как nullable-даты/enum’ы, чтобы не терять данные (время события).
• Противники: это нарушает KISS, раздувает схему и вводит двусмысленность (null = не случилось или ошибка?).
• Сторонники: булевы поля не «помнят» контекст, легко образуют недопустимые комбинации флагов, а дата или enum выразительнее.
• Для параметров функций булевы флаги считаются плохо читаемыми; спасают именованные аргументы, отдельные функции или бит-маски.
• Встраиваемые/индустриальные системы часто считают булевы типы оптимальными по памяти и не применяют совет к себе.

Всё, что я знаю о хорошем системном дизайне

Системный дизайн — это то, как мы собираем сервисы, а не строки кода. Его примитивы: серверы, БД, кэши, очереди, прокси и т.д.

Хороший дизайн выглядит скучно: ничего не ломается, задачи решаются проще, чем ожидалось. Сложные системы с CQRS, консенсусом и прочими фокусами часто компенсируют плохие решения. Сложное должно расти из простого, а не строиться сразу.

Состояние и его минимизация
Сложность — в управлении состоянием. Stateless-сервисы (например, конвертер PDF → HTML) перезапускаются и живут вечно. Stateful-сервисы могут «испортиться» и требуют ручного лечения. Поэтому:

• Один сервис пишет в БД, остальные общаются с ним по API/событиям.
• Чтение иногда проще делать напрямую, но писать — только через «владельца» данных.

Базы данных
Главный компонент.

• Схема: читаемая человеком, достаточно гибкая, но не «всё в JSON».
• Индексы: под самые частые запросы, не больше.
• Узкие места: обращения к БД часто тормозят всё.

• Сложность ≠ хороший дизайн: большинство участников согласны, что переусложнённые системы часто свидетельствуют о слабом проектировании, но на собеседованиях это лучше не озвучивать.
• Главный критерий — пригодность (fit for purpose): универсальных «правильных» архитектур не существует, нужно исходить из задач команды и бизнеса.
• Простота и KISS ценятся выше модных паттернов; монолит или «скучные» технологии часто эффективнее микросервисов и самописных очередей.
• Ключевые боли — синхронизация состояний и транзакционность между сервисами; чем меньше распределённого состояния, тем проще жить.
• Не забывать людей: Conway’s Law и топология команд влияют на архитектуру не меньше, чем технические решения.

Neki — шардированный Postgres от создателей Vitess.
Vitess уже масштабирует MySQL для сотен тысяч пользователей; теперь та же мощь переходит к Postgres.

Neki не форк Vitess. Мы строим с нуля, опираясь на опыт работы в экстремальных нагрузках, и откроем проект как open-source, когда он будет готов к самым требовательным задачам.

Следите за новостями и регистрируйтесь на neki.dev.

• Пользователи обсуждают анонс PlanetScale о «Vitess для Postgres», но код ещё не выложен, что вызывает скепсис.
• Всплывает конкуренция: Supabase уже работает над своим проектом Multigres, а автор Vitess, Сугу Сугумаран, теперь в Supabase.
• Вопросы о самостоятельном хостинге, необходимости шард-ключей и сравнении с YugabyteDB, CockroachDB и другими «PostgreSQL-совместимыми» решениями.
• Некоторые считают, что PostgreSQL устарел и нуждается в замене; другие отмечают, что сам PostgreSQL постоянно эволюционирует.

Police should be held to the highest standard: as they have a monopoly on legal force. The end of 'qualified immunity' and the start of personal insurance akin to what surgeons have would do a lot to reform the police.They should also be trained better (certainly longer than 1 se