Иван Мельников

лить в таблицу (ticker, price, quantity, oper) ежесекундно ~1 млн. строк

колись, у какого брокера и за какие деньги ты получаешь эти данные такого объема?

Есть данные типа level2/3 (когда вместе с событиями trade тебе льют depth update, изменения в стакане или сами события в стакане, это данные дорогие, доступ на большом рынке тебе дадут только с машины в датацентре брокера, где надо платить еще и дорогую аренду сервера. В мире криптовалют эти данные пока бесплатны, к примеру один binance (крупнейший поставщик биржевых событий, сравним с ними coinbase точнее gdax остальные в сумме наверное от силы столько же дадут) и тот дает порядка 4 тысяч событий в секунду, максимум что я от них видел.

По теме вопроса, всегда, в первую очередь нужно задавать вопрос не как и где хранить данные а как ты их будешь читать. Судя по теме с высокой вероятностью тебе не нужены отдельные случайные события, а нужны данные блоками, на интервале, поэтому и в базе хранить данные лучше этим блоками (вот тут уже надо считать, проводить бенчи на основе твоих данных и твоих мощностей), скорее всего тебе хватит почасовые массивы, тогда при любом запросе потока на момент времени x-y тебе нужно читать минимум две записи, это сотни миллисекунд, плюс фильтрация, на эту уходят десятки миллисекунд даже на php, если в базе данные удобно сериализованы, дольше передавать и обрабатывать будешь.

Голову потока данных (текущая минута-час) храни в локальном кеше бакэнда, в памяти, чтобы эти данные выдавать сразу но маловероятно что тебе это нужно, обычно нужна агрегация а не сырые данные.

Так вот, хранить данные можно буквально в файлах, файловая система - отличная key value база данных (дели по файлам и каталогам на основе валютной пары, биржи, и временного интервала, но на время лучше индекс заводить), работать с такой базой неудобно только при обслуживании (backup/restore) но если изначально организовать хранилище в отдельном разделе, то и работать с ним напрямую.

Одно время я хранил данные в gzip json, но недавно открыл для себя igbinary, чудесная вещь, бинарный при этом тоже пакуется, файлы храни на btrfs со включенным сжатием zstd ultra.

Во-первых, упаковка там несколько другая. Каждые полная девятка цифр занимает четыре байта, неполная меньше (есть таблица). Целая и дробная части упаковываются отдельно. Ваш формат 13,6 должен занимать 7 байт.
https://dev.mysql.com/doc/refman/8.0/en/precision-...

Во-вторых, функция LENGTH принимает на вход строку, так что значение DECIMAL приводится к строке, отсюда и 14 символов.
https://dev.mysql.com/doc/refman/8.0/en/string-fun...

Подход абсолютно неграмотный. MySQL при вставке в таблицу (как и при большинстве операций) автоматически приводит данные к нужному типу.
А поля DATA и ENUM вообще всегда передаются как строки, только DATA должно быть в правильном формате, 'YYYY-MM-DD'.

Потому что то, что вы видите, это не строковое представление для строки(простите за тавтологию), а ее "техническое" представление. Попробуйте сделать
>>> print('"Isn\'t," they said.')
Дело в том, что каждый объект в python может иметь 2 метода: __repr__ и __str__. Первый отвечает за "техническое" представление, которое помогает однозначно идентифицировать объект и используется для отладки и в том числе в REPL, а второй за строковое представление, удобное для чтения человеком. Например, в случае с datetime.date(2021, 6, 1), __repr__ вернет 'datetime.date(2021, 6, 1)', а __str__: '2021-06-01'.

UPD: увидел обсуждение в комментариях касательно ' и "
> Почему в вышеуказанном примере бэкслэш выводится, в примере ниже - нет?

>>> "\"Yes,\" they said."
'"Yes," they said.'

Тут штука в том, что двойные кавычки это что-то вроде синтаксического сахара, который позволяет нам вставлять всякие непечатаемые символы, а также использовать переменные(как f-строки или r-строки). В итоге их отображение все равно приводит их к виду одинарных кавычек с соответствующим форматированием. Для одинарных кавычек обратный слеш при работе с двойными не нужен, поэтому он и не отображается.

d3 = [i2 for i1,i2 in zip(d1,d2) if i1]

d1 = [1, 0, 1, 0]
d2 = ['qwe', 'asd', 'zxc', 'wer']
print([d2[i] for i, _ in enumerate(d2) if d1[i]])

itertools.compress

d3 = list(compress(d2, d1))

d1 = [1, 0, 1, 0]
d2 = ['qwe', 'asd', 'zxc', 'wer']

d3 = [x[1] for x in filter(lambda x:x[0] == 1, zip(d1, d2))]

print (d3)

Ещё короче:

d3 = [d2[i] for i in range(0,len(d1)) if d1[i] == 1]

df.rolling(6).mean().shift(-5)

df.groupby(['client_id', 'phone_number']).count().reset_index()

Посчитать количество уникальных client_id проще так:

df.client_id.value_counts()
df.client_id.value_counts().to_frame(name='count')

Способов решить вашу задачу много. Например, можно просто переименовать индекс:
new_df.index.name = 'my_index'

Или задать имена колонкам:
new_df.columns = ['count']