Hacker News Digest

AWS S3 достигает экстремальной производительности в 1 петабайт в секунду и 150 миллионов запросов в секунду, несмотря на использование медленных жёстких дисков (HDD). Ключ к масштабированию — дешёвая экономика HDD: их цена за байт упала в 6 миллиардов раз с поправкой на инфляцию, а ёмкость выросла в 7,2 миллиона раз. Однако физические ограничения — механическое движение считывающих головок и скорость вращения пластин (~7200 оборотов в минуту — держат IOPS на уровне всего ~120 на диск уже 30 лет.

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

• Обсуждается архитектура AWS S3, включая использование HDD для хранения данных и SSD для метаданных и кеширования, а также применение эратур-кодирования и шардинга для повышения надежности и производительности.
• Поднимается вопрос о том, как S3 достигает высокой пропускной способности благодаря массовому параллелизму миллионов дисков, что позволяет превысить производительность отдельного HDD.
• Участники обсуждают возможные альтернативы S3 для развертывания в homelab или частных облаках, такие как Ceph, MinIO, SeaweedFS, Garage и Gluster, отмечая их особенности и требования к железу.
• Затрагивается экономический аспект: несмотря на падение цен на HDD, стоимость S3 остается стабильной годами, что связывают с недостатком конкуренции и высокой рентабельностью для AWS.
• В комментариях уточняются технические детали, например, расчет среднего времени поиска на диске и использование различных схем шардинга, отличных от упомянутых в исходной статье.

PlanetScale запустил общедоступную версию своей управляемой базы данных для Postgres, завершив этап приватного тестирования. Сервис предлагает миграцию с других провайдеров Postgres через гайды и поддержку sales-команды для сложных случаев. Компания уже пять лет развивает Vitess для MySQL, а теперь переносит этот опыт на Postgres, объединяя производительность своей платформы Metal с гибкостью Postgres.

Сотни компаний, включая Convex и Supermemory, уже используют PlanetScale для Postgres в продакшене, отмечая улучшение скорости и масштабируемости. Анонсирован также будущий инструмент Neki — решение для шардинга Postgres, построенное на принципах Vitess, но спроектированное с нуля для специфики Postgres; его открытую версию планируют выпустить позже.

• Успешная миграция на PlanetScale Postgres с улучшением производительности запросов и оперативной поддержкой команды, включая помощь в решении возникших проблем.
• Критика недостаточной ясности описания продукта и цен на сайте для новых пользователей, а также отсутствия бесплатного тарифа для тестирования.
• Вопросы о технических деталях: масштабировании записи (горизонтальное шардирование через Neki), использовании эфемерных дисков NVMe в GCP, поддержке расширений Postgres и сравнении с конкурентами (Aurora, Supabase).
• Положительные отзывы от пользователей бета-тестирования о высокой производительности и надежности продукта в production-среде.
• Объяснения от команды PlanetScale о архитектуре (репликация для надежности вместо сетевых дисков) и планах по развитию (горизонтальное масштабирование через Neki).

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

Хотя размер UUID остаётся 128-битным (больше, чем INT или BIGINT), современные CPU эффективно обрабатывают такие значения через SIMD-инструкции. Важно использовать бинарное представление UUID, а не строковое, для оптимизации производительности. UUIDv7 также подходит для публичных идентификаторов, так как их сложно угадать, в отличие от автоинкрементных чисел. Это делает его идеальным выбором для шардированных баз данных и сред с минимальной серверной координацией.

• Обсуждаются проблемы безопасности UUIDv7 из-за экспозиции времени создания в публичных идентификаторах, что может упростить угадывание соседних записей.
• Предлагаются решения для сокрытия времени создания на границе API, например, преобразование UUIDv7 в UUIDv4 или шифрование временной метки.
• Отмечается, что 62 бита случайности в UUIDv7 при наличии лимита запросов обеспечивают достаточную безопасность для большинства веб-приложений.
• Поднимается вопрос о негативном влиянии UUID (по сравнению с последовательными целыми числами) на производительность БД из-за отсутствия оптимизаций для последовательных ключей.
• Утверждается, что безопасность не должна зависеть от формата первичного ключа, а проблемы угадывания ID указывают на ошибки в проектировании системы.

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

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

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

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