Ок. Задачка номер 2. Два коннекта одновременно добавляют по миллиарду записей. Как будут
расположены эти записи в базе:
а) Сначала миллиард первого, потом миллиард второго.
б) Вперемешку.

Каково поведение твоей базы?


Если оба миллиарда содержат один commit() в конце - то сначала первый потом второй.

Если в таблице не определён timestamp, то обе транзакции войдут без проблем. Если timestamp определён, то база проверяет что данные в хронологическом порядке. Если нет - второй коннект получит ошибку.

То есть полная сериализация: пока одна транзакция не завершилась - вторая не стартует?


Если по одной таблице - да. Таблицы разные - заливаются полностью параллельно.

И если первый клиент впал в кому или тихо скончался от электрической недостаточности на
100500-й записи из миллиона, вторая транзакция будет ждать... сколько?


Это кстати интересно. Сейчас транзакция откатывается если сокет отконнектился. Если впал в кому, то есть idle timeout, т.е. сервер закроет сокет со своей стороны и транзакцию с миллиардом откатит. Можно ещё ввести ограничения снизу на скорость заливки и длину открытой транзакции - это по запросам если необходимо.

Если на ваш вопрос ответить коротко, то — получится, потому как время должно быть больше или равно... Убивать не надо.

Если по длиннее, то мы говорим о разных вещах. В OLTP системах когда данные вводятся в рукопашную, происходят ой и ай, время может быть просто системным а ключ записи органическим. В таких условиях поменять все ой и ай можно будет без проблем. Повторяйте ключ при вставке, задавайте новые значения полей, время шагает вперёд и все вставляется.




Понимаете правильно. Здесь проблема идеологического характера. Отторгать данные это плохая идея. Данные нужно собирать все что идут. Даже плохие данные могут быть полезно использованы. Я придерживаюсь мнения что ссылочная целостность с субд — устаревшее понятие. По этому в QuestDB отсутствует как класс

mayton,

Представьте что у вас есть таймсерия событий которые побуждают механизм, организм, устройство к действию. Так же у вас есть таймсерия действий этого устройства.

As of join позволяет соединить в одну запись действия устройства с событиями которые непосредственно предшествовали этим действиям.

Финансовый пример это котировки — события; и сделки — действия

Leonid Kudryavtsev,

4.
Не очень понятно, как работают(должны работать) JOIN двух и более time series.

Вообще, отличает ли СУБД join'ы:
1) time series с не time series (пример из туториала соединение справочника датчиков и измерений)
2) join time series с time series одинаковой размерности
3) join двух time series с разными размерностями, приводить размерность одних тайм серий к другим


Я надеюсь с join достаточно было ссылки на доку? Сообщите если нет...

Leonid Kudryavtsev,


Например есть тайм серия минутных баров, есть времени работы биржи, есть сплит акций

Мы хотим выбрать данные за 2015 год и получить максимальную цену на каждый день, на момент закрытия биржи, при этом с учетом сплита который произошел 01.03.2015 9:00.
(т.е. цену до 01.03.2015 9:00 нужно умножить в два раза)

Как должны выглядеть таблицы и какой должен быть запрос?



Если цены top of book, то таблица могла бы выглядеть так:


Если мы предположим что QuestDB может использовать произвольный календарь, то запрос был бы:


Но поскольку calendar(‘my fancy calendar’, ‘1d’) пока нет, замените на 1d

Вот об этом я и говорил: полное отсутствие фич, которые делают другие СУБД сложными,
упрощает разработку узкоспециализированного решения до тривиальности.

Опять же к вопросу о транзакциях:
одна делает insert into a, inset into b, commit;
вторая делает insert into b, insert into a, commit;
получаем полный дедлок?..


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

По поводу дедлок — блокировки, включая бесконечные, в questdb тоже отсутствуют как класс. Ваш пример вернёт ошибку даже без тайм-аута.

Вы сделали вывод о дедлоке потому что я сказал транзакции по одной таблице сериализованы?

mayton,

Давайте попробую, например событие это цена инструмента на рынке:


У вас есть электронная система которая формирует свои цены на основе рыночных. Задача такой системы не зевать и менять цены как только рынок изменился.

Например ваша система опубликовала:





Т.е на момент публикации цены вашей системой мы получаем самую свежую котировку (15:04)

mayton,

Это как удобно, некоторые организации хранят все символы в одной таблице. Суть джоина не меняется (‘on’ не нужен в вашем случае)

Dimitry Sibiryakov,

QuestDB поддерживает индексы и оптимизатор вырулит правильный план если они есть...

Логика работы с таблицами такая: есть один writer и неограниченное количество reader‘ов, мы их оставим в покое, они никогда не блокируются.

Контекст, который получает writer для транзакции от engine хранит его у себя в списке, если контексту нужен ещё один writer то он опять лезет в engine с запросом. Engine может сказать «writer занят», в этом случае у контекста есть два варианта. Первый — жаловаться пользователю, второй — ждать.


Ожидание


1. Хотим добавить имя writer в список ожидания
2. Проверим что все writers которые у контекста уже есть не находятся в списке ожидания.
3. Не находятся — добавим наш writer в этот список
4. Какой-то «наш» writer в списке ожидания — ошибка, откат всего на свете

mayton,

В отличий от реляционных join “asof” не использует равенство «=« для объединения. Совпадать ни количество записей ни значения времени в обоих таблицах не должно (необязательно). Так же нет округления времени.

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

Вы разрушили мой стеклянный мир :( приведите пример пожалуйста