#time-series #questdb
Вопрос:
При работе с обычными базами данных SQL индексы полезны для извлечения нескольких строк, но не так полезны, когда вы извлекаете большой объем данных из таблицы. Например, представьте, что у вас есть таблица с оценкой акций 10 акций с течением времени:
|------ -------- -------
| time | stock | value |
|------ -------- -------
| ... | stock1 | ... |
| ... | stock2 | ... |
| ... | ... | ... |
|------ -------- -------
Насколько я могу судить, индексирование по запасам (даже с перечислением/int/внешним ключом) обычно не очень полезно в базе данных, такой как Postgres, если вы хотите получать данные в течение большого периода времени. В итоге вы получаете индекс, охватывающий большую часть таблицы, и в конечном итоге база данных быстрее выполняет последовательное сканирование, например, чтобы получить среднее значение по всему набору данных для каждой акции:
SELECT stock, avg(value) FROM stock_values GROUP BY stock
Учитывая, что база данных QuestDB ориентирована на строки, я бы предположил, что это приведет к повышению производительности, если для каждого запаса будет отдельный столбец.
Итак, какая схема рекомендуется в базе данных QuestDB для подобной ситуации? Один столбец для каждой акции или столбец символов для каждого символа акции будет таким же хорошим (или достаточно хорошим), даже если для каждой строки есть миллионы результатов?
Ответ №1:
В базе данных QuestDB нелегко создать столбец для каждого запаса. Если вы создадите таблицу, подобную этой
|----------------------------------|
| time | stock1 | stock1 | stock3 |
|----------------------------------|
Затем вам придется вставить все значения вместе в одну строку, иначе вы получите пробелы
|----------------------------------|
| time | stock1 | stock1 | stock3 |
|----------------------------------|
| t1 | 1.1 | | |
| t2 | | 3.45 | |
| t3 | | | 103.45 |
|----------------------------------|
Даже t1 == t2 == t3
если вы выполните операцию вставки как 3, она все равно приведет к 3 строкам.
Так что символы здесь-лучший выбор.
Символ может быть проиндексирован и не проиндексирован, и вы можете воспользоваться преимуществами неиндексированных символов, когда их количество невелико. Чтение полной таблицы по сравнению с чтением по индексу-это вопрос избирательности индекса, а не диапазона данных. Если избирательность высока (например, количество отдельных символов составляет, скажем, 10 кб), выборка по индексу выполняется быстрее, чем сканирование диапазона.
Комментарии:
1. Отличный ответ, особенно в этой части:
Reading full table vs reading by index is the matter of index selectivity, not data range. If the selectivity is high (e.g. distinct symbol count is say 10k) fetching by index is faster than range scans.