DuckDB ці SQLite: аналітыка паскараецца, але запісы становяцца вузкім месцам

Для агрэгацый па вялікіх наборах і працы з файламі выбірайце DuckDB: яго калоначнае вектарызаванае выкананне разлічана на запыты, якія праходзяць праз значную частку даных. Для лакальнай праграмы, дзе пераважаюць кароткія змены асобных радкоў і пошук па ключы, звычайна лепш пачынаць з SQLite. Такі выбар вызначае характар запытаў, а не толькі аб’ём файла базы.

Калі патрэбныя абодва тыпы працы, SQLite можа захоўваць актуальны стан праграмы, а DuckDB — будаваць справаздачы па выгрузцы або чытаць яе файл базы. Афіцыйныя рэкамендацыі SQLite адносяць лакальныя даныя праграм да яе асноўных ужыванняў і ўдакладняюць, што запіс у адзін файл у пэўны момант выконвае толькі адзін аўтар. Таму перавага SQLite для транзакцый не азначае неабмежаваных адначасовых запісаў.

Чаму аналітычныя запыты схіляюць выбар да DuckDB

Аналітычны запыт чытае шмат радкоў, але нярэдка толькі частку палёў: напрыклад, дату, катэгорыю і суму для групавання аперацый. DuckDB апрацоўвае значэнні пакетамі і выконвае аперацыі па слупках. Гэта скарачае накладныя выдаткі на апрацоўку кожнага радка і дапамагае, калі трэба прасканаваць значную частку табліцы ці злучыць вялікія наборы.

Умоўны прыклад: праграма выгрузіла аперацыі ў CSV, а аналітыку патрэбныя месячныя сумы па катэгорыях. DuckDB можа звярнуцца да CSV непасрэдна з SQL-запыту; для Parquet ён таксама падтрымлівае працу з файлам без пераўтварэння ў асноўную базу. Для звычайнага шляху SQLite з CSV файл спачатку трэба загрузіць у табліцу, таму пры разавым падліку час імпарту ўваходзіць у чаканне адказу.

З гэтага не вынікае, што любую справаздачу варта пераносіць у іншую сістэму. SQLite сама дазваляе аналізаваць імпартаваныя даныя і будаваць зводкі. Калі яны ўжо знаходзяцца ў лакальнай базе, а справаздача кароткая і рэдкая, дадатковы рухавік можа ўскладніць працу без прыкметнай карысці; DuckDB асабліва дарэчная там, дзе сканаванне і групаванне становяцца асноўнай нагрузкай.

Што сапраўды вымераў тэст на CSV

У апублікаваным тэсце Markaicode на сінтэтычным CSV з 6 млн радкоў прамы запыт DuckDB заняў 1,30 секунды, а імпарт файла ў SQLite разам з агрэгацыяй — 13,87 секунды. Суадносіны каля 10,7 раза адлюстроўваюць поўны шлях да выніку, калі кожнаму рухавіку далі найбольш прыдатны для яго спосаб працы з зыходным файлам. Гэта не суадносіны хуткасці саміх SQL-запытаў па ўжо падрыхтаваных табліцах.

Калі даныя папярэдне загрузілі ў абедзве базы, запыт у тым жа тэсце заняў 0,24 секунды ў DuckDB і 1,86 секунды ў SQLite — каля 7,8 раза розніцы. Гэта таксама вынік пэўнай агрэгацыі, а не мера хуткасці ўсіх аперацый. Тэст праводзілі ў адным асяроддзі на сінтэтычным наборы; адначасовыя запісы і пошук асобнага радка ў ім не вымяралі. Таму сцвярджэнне пра перавагу SQLite ў запісах абапіраецца на архітэктуру доступу, а не на гэтыя секунды.

Калі запісы становяцца абмежаваннем

SQLite прымае транзакцыйныя змены ад розных патокаў і працэсаў, але аўтары аднаго файла працуюць па чарзе. Для лакальнай праграмы з кароткімі транзакцыямі гэта звычайна прымальна: захаванне налады, даданне запісу і чытанне гісторыі не патрабуюць адначасовага выканання некалькіх аперацый запісу. Калі ж многія аўтары павінны пісаць у той самы файл без чакання, патрэбная іншая архітэктура, звычайна серверная база.

У DuckDB абмежаванне мае іншую мяжу. Паводле правілаў паралельнай працы DuckDB, некалькі патокаў у адным працэсе могуць запісваць у базу, пакуль яны не змяняюць адзін і той жа радок; пры канфлікце адна аперацыя атрымлівае памылку. У звычайным рэжыме запісу ва ўласны файл працэс працуе з ім адзін. Для запісу з некалькіх працэсаў патрэбна асобная каардынацыя.

Такім чынам, абедзве базы маюць межы паралельнага запісу, але яны розныя. SQLite серыялізуе аўтараў на ўзроўні файла і дапускае доступ з некалькіх працэсаў; DuckDB дазваляе паралельную працу патокаў у працэсе, які валодае запісам ва ўласны файл. Для выбару істотна, адкуль прыходзяць змены: з аднаго працэсу аналітычнай праграмы, з некалькіх лакальных працэсаў або ад многіх сеткавых кліентаў.

Кропкавыя запыты і стан лакальнай праграмы

Калі карыстальнік адкрывае канкрэтны заказ або мяняе адзін параметр, праграма чытае ці абнаўляе мала радкоў. Тут важнейшыя індэксаваны пошук, кароткая транзакцыя і надзейнае захаванне стану, чым хуткасць поўнага сканавання гісторыі. SQLite добра адпавядае ролі файла даных настольнай ці мабільнай праграмы, у якой такія дзеянні складаюць асноўны шлях працы.

DuckDB таксама падтрымлівае транзакцыі і другасныя індэксы, таму адсутнасцю гэтых функцый выбар не тлумачыцца. Адрозніваецца прыярытэт архітэктуры: яе перавагі найбольш раскрываюцца, калі запыт апрацоўвае шмат значэнняў адразу. Калі затрымку праграмы ў асноўным вызначае адкрыццё аднаго запісу і захаванне яго змены, хуткая агрэгацыя не дае самастойнай прычыны пераносіць асноўнае сховішча.

Як сумясціць абедзве базы без міграцыі

Для змешанай нагрузкі можна пакінуць транзакцыі ў SQLite, а справаздачы перадаць DuckDB. Пашырэнне DuckDB для SQLite дазваляе падключыць існы файл праз ATTACH з тыпам sqlite і запытваць яго табліцы непасрэдна. Даныя пры гэтым чытаюцца з табліц SQLite падчас запыту: падключэнне не пераносіць іх аўтаматычна ў калоначнае сховішча.

Калі справаздачы паўтараюцца і кожны раз перачытваюць вялікую частку базы, можна зрабіць асобную выгрузку ў CSV або Parquet і запускаць аналітыку па ёй. Умоўны прыклад: лакальная праграма захоўвае асобныя аперацыі ў SQLite, а рэгулярны падлік месячных вынікаў выконваецца ў DuckDB па выгрузцы. Для такой схемы трэба вызначыць момант абнаўлення выгрузкі, інакш справаздача можа адставаць ад актуальнага стану праграмы.

Выбар зводзіцца да галоўнай нагрузкі: сканаванне файлаў і масавыя агрэгацыі вядуць да DuckDB, змены асобных запісаў і лакальны стан — да SQLite. Калі адной праграме патрэбныя абодва рэжымы, спалучэнне захоўвае транзакцыйны шлях і дадае аналітычны без поўнай міграцыі. Калі патрабуецца шмат адначасовых аўтараў аднаго агульнага сховішча, пытанне ўжо ў мадэлі доступу да даных, а не ў хуткасці аналітычнага рухавіка.

Чытайце таксама:

• Чарга на мяжы пераедзе ў праграму — але платформы яшчэ не названыя
• GPT-6 Sol і Luna сталі таннейшымі, але прызначаны для розных задач
• Першыя крыптабанкі Беларусі зарэгістраваныя, але працаваць яшчэ нельга