У нас есть несколько пользователей из финансовой и криптовалютной торговли. В основном QuestDB используется как low latency хранилище в трейдинг системах где размещение заказа должно происходить за меньше чем 15 микросекунд.

Мы подвигаем через общение с разработчиками, помогаем им решать задачи в замен на внедрение QuestDB.

Бумбараш,

QuestDB используется в имплементации движка OUCH, похожего на FIX, только производительнее. В неё сохраняются все входные и исходящие сообщения. Когда нарушается связь между клиентом и торговой системы из QuestDB достаются ответы (execution reports) по номерам последовательностей. QuestDB встроенная в такой ситуации.

Дополнительно из QuestDB используются библиотеки доступа к сети, вместо Java NIO, логирования и обмена сообщениями между потоками.

В других приложениях QuestDB используется как основание lossless multicast шины сообщений, все те же библиотеки как для ouch движка и ещё библиотека, которая заворачивает epoll/kqueue/select и работает быстрее чем Java/netty и позволяет конфигурировать несимметричное количество пользователей и потоков.

Аналитика потом делается из данных которые консолидируются по сети через эту multicast шину.

KDB тоже используется как в торговых системах, в конфигурации ticker—plant как система сообщений и генерации алгоритмических заказов, так и для аналитики естественно.

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

Постгрес форкает процесс для каждого accept() и все уважают и не гы—гыкают.

Dimitry Sibiryakov,

Это не только epoll это еще все парсеры написаны как state—machine и оттестироаны с невменяемым количеством комбинаций когда парсер прерывается из-за инертного сокета и восстанавливается по сигналам epoll. Я здесь говорю о рабочем продукте а не заявке на патент или Нобелевскую премию.

Говорить а блин это же epoll это очень упрощённый взгляд на вещи.

Dimitry Sibiryakov,

15 микросекунд это не теоретический полёт света, это разбор протокола, валидация, проверка риска и ограничений, конвертация протоколов, два сохранения, четыре сетевых хопа и поиск в order book. Вот это все между двумя серверами и 300м интерконнектом. Не на локалхосте а на solarflare картах и mellanox layer 3 свич. Все это 10микро 99.99 percentile

Dimitry Sibiryakov,

Бывают, большенство ленивые, чтобы им в рот все сразу мама положила

kealon(Ruslan),

Да, все парсеры вручную :(

mayton,

Спасибо за конструктивные вопросы.

Я себе представляю таймсерию как журнал событий, в котором как было бы удобно человеку, данные хранятся в столбик. Как вы понимаете в таком способе представления есть преимущества и недостатки.

Из преимуществ:

— Данные очень легко добавлять — записываем всегда в конец, отсюда огромная скорость добавления и так же очень недорогая атомичность.
— данные всегда выбираются в той же последовательности в которой они добавлены, либо в строго противоположной если нужно.
— данные не мутируют, отсюда возможна реализация инкрементальных запросов о которых я уже говорил
— новые данные всегда в конце журнала
— время хранится в порядке возрастания, отсюда сложность хранения О(1) и временная сложность O(log n). Дерево по сравнению O(log n) хранение и поиск, плюс место на диске

Из недостатков:

— сложность удаления индивидуальных записей, в случае QuestDB — невозможность, данные удаляютя удаляются через партиции
— невозможность физического изменения записей; изменения виртуальные и реализуются через select

По поводу доступа, он действительно только через memory mapped file. Здесь предположение что ва сервере субд достаточно памяти. Со своей стороны QuestDB выполняет запись и чтение через отдельные страницы. При записи таблицы используется одна страница, которая двигается вниз по мере поступления данных. При чтении, страницы мапятся лениво, по мере необходимости. Также группы таких страниц помещаются во внутренний LRU кэш. QuestDB старается быть эффективной с памятью.

Dimitry Sibiryakov,

Вы прямо мировой чемпион по прыжкам к умозаключениям?

Неленивый человек может найти «commit» в репо ра минуту. Durability будет конфигурируемый — msync() синхронный, асинхронный и отсутствующий. Данные полностью атомичны и все чтения полностью изолированы. Причём размер транзакции не ограничен.