Как спарсить криптовалюту на бирже binance?

just_personConfig, только там по умолчанию включен очень строгий контроль данных. Если биржа вернет хотя бы один пропуск в данных (а это бывает), будет ошибка "Too many empty bars". Если такой строгий контроль не нужен, то его можно отключить, выполнив один раз:

import live_trading_indicators as lti
lti.config(max_empty_bars_fraction=-1, max_empty_bars_consecutive=-1)

Как спарсить криптовалюту на бирже binance?

just_personConfig, да, любые монеты на binance и других биржах.
Нужно просто правильно указать названия монет - биткоин btcusdt, эфир ethusdt и т.д.
Можно получить и фьючерсы на монеты, в начале названия будет "um/".

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

mayton2019, спасибо за помощь!)
Не зря я до этого докопался, узнал много нового, научился пользоваться sqlite3_analyzer, ну и sql lite маленько поковырял - тоже новая штука для меня...

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Экспериментально выяснил - если блоб 996 байт, он размещается нормально. 997 - размер базы сразу возрастает в разы, то есть, он идет в overflow.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

4096 / 1200 = 3.4133333333333336
Ну да, вот он - этот коэффициент. Просто каждый блоб идет на отдельной странице зачем-то.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Ага...
Overflow pages used............................... 0
Overflow pages used............................... 500

Уже интереснее... предполагаю, что одна база блобы разместила в обычных страницах, а вторая - в каких-то "Overflow".

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

/** Disk-Space Utilization Report For test2.db

Page size in bytes................................ 4096      
Pages in the whole file (measured)................ 573       
Pages in the whole file (calculated).............. 573       
Pages that store data............................. 573        100.0% 
Pages on the freelist (per header)................ 0            0.0% 
Pages on the freelist (calculated)................ 0            0.0% 
Pages of auto-vacuum overhead..................... 0            0.0% 
Number of tables in the database.................. 2         
Number of indices................................. 0         
Number of defined indices......................... 0         
Number of implied indices......................... 0         
Size of the file in bytes......................... 2347008   
Bytes of user payload stored...................... 603000      25.7% 

*** Page counts for all tables with their indices *****************************

TEST.............................................. 572         99.83% 
SQLITE_SCHEMA..................................... 1            0.17% 

*** Page counts for all tables and indices separately *************************

TEST.............................................. 572         99.83% 
SQLITE_SCHEMA..................................... 1            0.17% 

*** All tables ****************************************************************

Percentage of total database...................... 100.0%    
Number of entries................................. 501       
Bytes of storage consumed......................... 2347008   
Bytes of payload.................................. 603121      25.7% 
Bytes of metadata................................. 6972         0.30% 
Average payload per entry......................... 1203.83   
Average unused bytes per entry.................... 3466.90   
Average metadata per entry........................ 13.92     
Average fanout.................................... 7.00      
Maximum payload per entry......................... 1206      
Entries that use overflow......................... 500         99.80% 
Index pages used.................................. 9         
Primary pages used................................ 64        
Overflow pages used............................... 500       
Total pages used.................................. 573       
Unused bytes on index pages....................... 5694        15.4% 
Unused bytes on primary pages..................... 43721       16.7% 
Unused bytes on overflow pages.................... 1687500     82.4% 
Unused bytes on all pages......................... 1736915     74.0% 

*** Table SQLITE_SCHEMA *******************************************************

Percentage of total database......................   0.17%   
Number of entries................................. 1         
Bytes of storage consumed......................... 4096      
Bytes of payload.................................. 121          3.0% 
Bytes of metadata................................. 112          2.7% 
B-tree depth...................................... 1         
Average payload per entry......................... 121.00    
Average unused bytes per entry.................... 3863.00   
Average metadata per entry........................ 112.00    
Maximum payload per entry......................... 121       
Entries that use overflow......................... 0            0.0% 
Primary pages used................................ 1         
Overflow pages used............................... 0         
Total pages used.................................. 1         
Unused bytes on primary pages..................... 3863        94.3% 
Unused bytes on overflow pages.................... 0         
Unused bytes on all pages......................... 3863        94.3% 

*** Table TEST ****************************************************************

Percentage of total database......................  99.83%   
Number of entries................................. 500       
Bytes of storage consumed......................... 2342912   
Bytes of payload.................................. 603000      25.7% 
Bytes of metadata................................. 6860         0.29% 
B-tree depth...................................... 3         
Average payload per entry......................... 1206.00   
Average unused bytes per entry.................... 3466.10   
Average metadata per entry........................ 13.72     
Average fanout.................................... 7.00      
Non-sequential pages.............................. 0            0.0% 
Maximum payload per entry......................... 1206      
Entries that use overflow......................... 500        100.0% 
Index pages used.................................. 9         
Primary pages used................................ 63        
Overflow pages used............................... 500       
Total pages used.................................. 572       
Unused bytes on index pages....................... 5694        15.4% 
Unused bytes on primary pages..................... 39858       15.4% 
Unused bytes on overflow pages.................... 1687500     82.4% 
Unused bytes on all pages......................... 1733052     74.0%

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Ну да, дело в заполнении страниц. В одной базе 87.1%, а в другой 25.7%.
Вод вывод sqlite3_analyzer для обоих баз.

/** Disk-Space Utilization Report For test1.db

Page size in bytes................................ 4096      
Pages in the whole file (measured)................ 169       
Pages in the whole file (calculated).............. 169       
Pages that store data............................. 169        100.0% 
Pages on the freelist (per header)................ 0            0.0% 
Pages on the freelist (calculated)................ 0            0.0% 
Pages of auto-vacuum overhead..................... 0            0.0% 
Number of tables in the database.................. 2         
Number of indices................................. 0         
Number of defined indices......................... 0         
Number of implied indices......................... 0         
Size of the file in bytes......................... 692224    
Bytes of user payload stored...................... 603000      87.1% 

*** Page counts for all tables with their indices *****************************

TEST.............................................. 168         99.41% 
SQLITE_SCHEMA..................................... 1            0.59% 

*** Page counts for all tables and indices separately *************************

TEST.............................................. 168         99.41% 
SQLITE_SCHEMA..................................... 1            0.59% 

*** All tables ****************************************************************

Percentage of total database...................... 100.0%    
Number of entries................................. 501       
Bytes of storage consumed......................... 692224    
Bytes of payload.................................. 603080      87.1% 
Bytes of metadata................................. 5619         0.81% 
Average payload per entry......................... 1203.75   
Average unused bytes per entry.................... 166.72    
Average metadata per entry........................ 11.22     
Average fanout.................................... 167.00    
Maximum payload per entry......................... 1206      
Entries that use overflow......................... 0            0.0% 
Index pages used.................................. 1         
Primary pages used................................ 168       
Overflow pages used............................... 0         
Total pages used.................................. 169       
Unused bytes on index pages....................... 2798        68.3% 
Unused bytes on primary pages..................... 80727       11.7% 
Unused bytes on overflow pages.................... 0         
Unused bytes on all pages......................... 83525       12.1% 

*** Table SQLITE_SCHEMA *******************************************************

Percentage of total database......................   0.59%   
Number of entries................................. 1         
Bytes of storage consumed......................... 4096      
Bytes of payload.................................. 80           2.0% 
Bytes of metadata................................. 112          2.7% 
B-tree depth...................................... 1         
Average payload per entry......................... 80.00     
Average unused bytes per entry.................... 3904.00   
Average metadata per entry........................ 112.00    
Maximum payload per entry......................... 80        
Entries that use overflow......................... 0            0.0% 
Primary pages used................................ 1         
Overflow pages used............................... 0         
Total pages used.................................. 1         
Unused bytes on primary pages..................... 3904        95.3% 
Unused bytes on overflow pages.................... 0         
Unused bytes on all pages......................... 3904        95.3% 

*** Table TEST ****************************************************************

Percentage of total database......................  99.41%   
Number of entries................................. 500       
Bytes of storage consumed......................... 688128    
Bytes of payload.................................. 603000      87.6% 
Bytes of metadata................................. 5507         0.80% 
B-tree depth...................................... 2         
Average payload per entry......................... 1206.00   
Average unused bytes per entry.................... 159.24    
Average metadata per entry........................ 11.01     
Average fanout.................................... 167.00    
Non-sequential pages.............................. 0            0.0% 
Maximum payload per entry......................... 1206      
Entries that use overflow......................... 0            0.0% 
Index pages used.................................. 1         
Primary pages used................................ 167       
Overflow pages used............................... 0         
Total pages used.................................. 168       
Unused bytes on index pages....................... 2798        68.3% 
Unused bytes on primary pages..................... 76823       11.2% 
Unused bytes on overflow pages.................... 0         
Unused bytes on all pages......................... 79621       11.6%

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Свободных боков, похоже, тоже нет.

$ sqlite3 test2.db .dbinfo
database page size:  4096
write format:        1
read format:         1
reserved bytes:      0
file change counter: 501
database page count: 573
freelist page count: 0
schema cookie:       1
schema format:       4
default cache size:  0
autovacuum top root: 0
incremental vacuum:  0
text encoding:       1 (utf8)
user version:        0
application id:      0
software version:    3037002
number of tables:    1
number of indexes:   0
number of triggers:  0
number of views:     0
schema size:         100
data version         1

freelist page count - по видимому, это количество свободных блоков

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

1. Результат выполнения для миллиона записей: 1305 МБ / 4464 МБ. Соотношение то же: 3.42
2. Заменил данные на случайную последовательность. Результат в точности как был - 692kb / 2347kb. Данные точно случайные пишутся, проверил в файле базы.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

mayton2019, 4 килобайта. В хекс 0x1000

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

А описание внутренних форматов на этот вопрос ответа не дает. В обоих случаях структура блока одинаковая. Записи занимают тоже одинаковое место. Почти одинаковое - в первом варианте запись даже длиннее на несколько байт. Но в то же время этот вариант на диске занимает в 3.4 раза меньше.

Блоки заполняются по разному. В одном случае записей в каждом блоке больше. Вопрос - почему так)

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

А, то старый тест. Новый вот https://github.com/hal9000cc/live_trading_indicato...

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Да я решил, в общем-то все проблемы и по скорости доступа, и по упаковке. Просто выгружаю серию (столбец), сжимаю и пишу в блоб. 31 миллион записей у меня загружаются за 3.8 секунды. Вот тут перформанс тест: https://github.com/hal9000cc/live_trading_indicato...

Суть вопроса - почему при почти одинаковой структуре и одинаковых данных занимаемый размер различается в разы. У меня нет никаких, даже примерных объяснений.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Такая:
CREATE TABLE test(
key INT,
data BLOB
)

Или такая?
CREATE TABLE test(
key INT,
data BLOB,
PRIMARY KEY (key)
) WITHOUT ROWID

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

mayton2019, про дедупликацию очень интересно. Сегодня сделаю тест с рандомными данными.

А структура таблицы какая в тесте - обычная (с rowId на двух деревьях) или without rowid на одном дереве? Это важно, собственно, в этом суть вопроса.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

mayton2019, а почему такой тест - в начале insert с пустыми данными, а потом их апдейт? Так точно сплитится будет...

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

mayton2019, я не правильно константу задал b'0xFE'. Хотя это не важно, просто размер записи не 300 байт, а 1200. Сейчас исправлю код, что бы был адекватным.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Вообще, я с чего ковыряться стал. У меня был первый вариант. Ну, думаю, зачем мне rowID, если можно сделать "правильный" индекс. Сделал, а размер базы стал в 3 раза больше. Можно, конечно, забить и вернуться к старому варианту. Но я не люблю непонятных вещей, очень хочется понять причину.

Завтра поищу утилиты.

Создаю таблицу в sql lite в обычном варианте, и в варианте c WITHOUT ROWID получается огромная разница в размерах. Почему размеры так отличаются?

Запустил миллион. Хотя не думаю, что что-то изменится.

Тут либо внутри sqlite файла нерационально распределяется место между сегментом таблицы индекса либо сам индес в блоках постоянно сплиттится.

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