Главная особенность DuckDB была и её главным узким местом
DuckDB заслужила репутацию мощной аналитической базы данных, ориентированной на работу с файлами. Как и SQLite, она работает встроенной в приложение, избавляя от необходимости отдельной настройки сервера. Такая конструкция сделала её очень привлекательной для лёгких аналитических нагрузок внутри процесса.
Однако у этой встроенной природы был существенный недостаток: конкурентность. Каждый процесс приложения хранит в памяти собственное кэшированное состояние базы данных. Это эффективно для одного процесса, но означает, что в файл базы данных одновременно может записывать только один процесс. DuckDB не могла синхронизировать кэшированные состояния нескольких процессов.
Представьте команду, которая запускает несколько сервисов, дашбордов и приложений, и всем им нужно обращаться к одним и тем же аналитическим данным и обновлять их. С традиционной DuckDB они сталкивались с дилеммой: либо самостоятельно создавать сложный слой совместного доступа для координации записей, либо выбрать совсем другую базу данных.
Это узкое место вынуждало многих обходить сильные стороны DuckDB. Некоторые пользователи даже запускали DuckDB внутри PostgreSQLQL, чтобы получить общий доступ. Именно то свойство, которое делало DuckDB такой доступной — встроенная работа без сервера, — стало её главным ограничением для совместной работы.
Quack даёт DuckDB «парадный вход», а не новый механизм хранения
Quack, впервые представленный экспериментально в мае, даёт DuckDB «парадный вход». Один экземпляр DuckDB открывает файл базы данных и выступает в роли сервера. Другие экземпляры DuckDB подключаются к нему по обычному HTTP, отправляя свои запросы на чтение и запись. Это позволяет нескольким приложениям работать с базой данных одновременно.
Принципиально важно, что сервер остаётся единственным процессом, напрямую обращающимся к файлу базы данных. Такая архитектура позволяет избежать проблем неограниченной многопроцессной записи в файл, при которой параллельные кэши могли бы привести к повреждению данных. Вместо этого клиенты получают доступ через координатор, что обеспечивает целостность данных и расширяет доступность.
Команда DuckDB отметила, что многие пользователи уже создавали собственные обёртки или даже запускали DuckDB внутри PostgreSQLQL для лёгкого совместного доступа. Quack, ставший в DuckDB 2.0 доработанной функцией, предоставляет нативное, официально поддерживаемое решение для этого распространённого случая. Он позволяет разработчикам включить многоклиентский доступ без самодельных, зачастую хрупких обходных решений.
Эта новая серверная возможность не меняет сути DuckDB как аналитической базы данных, ориентированной на файлы. Она просто добавляет надёжный нативный вариант для координированного доступа. Например, DuckDB может передать 60 миллионов строк между двумя машинами менее чем за 5 секунд с помощью Quack, значительно опережая протокол PostgreSQLQL, которому для той же задачи потребовалось более 2,5 минут. Хотя мелкие записи выходят на плато около 5.500 в секунду при 8 потоках, этого достаточно для нескольких сервисов, совместно использующих дашборд.
Шестьдесят миллионов строк за пять секунд — самый впечатляющий результат
Самая наглядная демонстрация Quack связана со скоростью передачи данных. В видео Better Stack команда DuckDB передала 60 миллионов строк между двумя машинами менее чем за пять секунд с помощью Quack. Для сравнения, протокол PostgreSQLQL затратил на ту же операцию более двух с половиной минут (более 150 секунд).
Этот тест показывает преимущество Quack для аналитических нагрузок. В отличие от традиционных строковых протоколов баз данных, Quack передаёт нативные колоночные векторные пакеты DuckDB напрямую по HTTP. Это позволяет избежать значительных издержек на преобразование колоночных данных в построчный формат и обратно, типичных для многих сетевых протоколов баз данных.
Ускорение существенно для аналитических передач, где важно эффективно перемещать большие наборы данных. Несмотря на впечатляющий результат, помните, что это заявленный тест. Реальная производительность может отличаться в зависимости от:
- вашей конкретной нагрузки
- сетевых условий
- конфигурации оборудования
- формы запросов
Подробнее о том, как Quack достигает этого, включая принципы его устройства, можно узнать в официальной документации Quack: The DuckDB Client-Server Protocol. Этот протокол меняет правила игры, но важно понимать его сильные стороны и ограничения применительно к вашему случаю.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Потолок в 5.500 записей подсказывает, когда стоит остановиться
Quack отлично справляется с перемещением больших аналитических наборов данных, но важно понимать его ограничения для транзакционных нагрузок. Тесты показывают, что серверный режим DuckDB превосходит PostgreSQLQL при мелких записях примерно до восьми параллельных потоков. Далее производительность выходит на плато около 5.500 записей в секунду.
Этот потолок существует потому, что сервер DuckDB, хотя и поддерживает несколько клиентов, по-прежнему полагается на один процесс для всех записей в файл. Представьте одного очень эффективного кассира, обслуживающего множество покупателей: он может обработать лишь ограниченное число операций в секунду.
Такая архитектура хорошо подходит для совместной аналитики, дашбордов и сервисов, которым выгоден простой центральный узел DuckDB, особенно когда приоритетом является быстрое массовое перемещение данных. Она упрощает загрузку данных и выполнение сложных запросов из разных приложений.
Однако для высокочастотных транзакционных систем, где каждая запись должна обрабатываться мгновенно и параллельно, это узкое место в виде одного процесса станет ограничением. Для таких требовательных сценариев OLTP (Online Transaction Processing) PostgreSQLQL или другая специализированная OLTP-база данных остаётся более подходящим выбором. DuckDB 2.0 также включает другие улучшения хранения и обработки запросов, но ключевым фактором для параллельной записи остаётся устройство Quack.
Часто задаваемые вопросы
Что такое Quack в DuckDB 2.0?
Quack — это клиент-серверный протокол DuckDB. Он позволяет клиентским экземплярам отправлять запросы и операции записи по HTTP процессу DuckDB, который владеет файлом базы данных.
Могут ли несколько приложений записывать в одну базу данных DuckDB?
Да. С Quack несколько клиентов могут отправлять задачи на один экземпляр сервера, который является единственным процессом, напрямую обращающимся к файлу базы данных.
Заменяет ли DuckDB 2.0 PostgreSQL?
Нет. Серверный режим DuckDB подходит для совместной аналитики и умеренной нагрузки на запись; PostgreSQL, как правило, лучше подходит для требовательных транзакционных нагрузок с высокой конкурентностью.
Насколько быстр DuckDB Quack?
В видео сообщается о передаче 60 миллионов строк между двумя машинами менее чем за пять секунд. Пропускная способность при мелких записях, по имеющимся данным, выходит на плато около 5.500 записей в секунду.