సర్వర్‌లో DuckDB మరియు SQLite: ఏది ఎంచుకోవాలి?

సర్వర్‌లో DuckDB మరియు SQLite: ఒకే వాక్యంలో సమాధానం

SQLite అనేది ఒక OLTP (ఆన్‌లైన్ ట్రాన్సాక్షన్ ప్రాసెసింగ్) ఇంజిన్: ఇది డేటాను అడ్డు వరుసలుగా (rows) నిల్వ చేస్తుంది మరియు కొన్ని వరుసలను సురక్షితంగా, వేగంగా చదవడానికి లేదా రాయడానికి రూపొందించబడింది. DuckDB అనేది ఒక OLAP (ఆన్‌లైన్ అనలిటికల్ ప్రాసెసింగ్) ఇంజిన్: ఇది డేటాను నిలువు వరుసలుగా (columns) నిల్వ చేస్తుంది మరియు లక్షలాది వరుసలను స్కాన్ చేసి, ఒక సమగ్ర ఫలితాన్ని (aggregate) అందించడానికి రూపొందించబడింది. ఇవి రెండూ ఎంబెడెడ్ లైబ్రరీలు, రెండూ సాధారణ ఫైల్‌ను ఓపెన్ చేస్తాయి, మరియు వీటిలో దేనికీ మీరు పర్యవేక్షించాల్సిన సర్వర్ ప్రాసెస్ అవసరం లేదు.

కాబట్టి "ఏది ఎంచుకోవాలి" అనే ప్రశ్నకు నిజాయితీ గల సమాధానం దాదాపు ఎప్పుడూ "రెండూ, ఒకే VPSలో" అని ఉంటుంది. మీ అప్లికేషన్ దాని లైవ్ స్టేట్‌ను SQLiteలో ఉంచుకుంటుంది. మీ రిపోర్టింగ్ ప్రక్రియ DuckDBతో Parquet మరియు CSV ఫైళ్లను చదువుతుంది. ఇవి రెండూ వేర్వేరు పనులను చేస్తాయి కాబట్టి, వీటి మధ్య పోటీ ఉండదు.

రో స్టోరేజ్ మరియు కాలమ్ స్టోరేజ్ సమాధానాన్ని ఎందుకు మారుస్తాయి

SQLite ఒక రో (row)ను పేజీలో ఒకే వరుస క్రమంలో రాస్తుంది. ప్రైమరీ కీ ద్వారా ఒక ఆర్డర్‌ను పొందడానికి ఒక ఇండెక్స్ పేజీ మరియు ఒక డేటా పేజీ అవసరమవుతాయి, అంటే మొత్తం రెండు రీడ్ ఆపరేషన్లు జరుగుతాయి. ఒక అప్లికేషన్ సెకనుకు వేల సార్లు చేసే పని ఇదే: ఒక యూజర్‌ను చదవడం, సెషన్‌ను అప్‌డేట్ చేయడం, ఒక ఆర్డర్‌ను ఇన్సర్ట్ చేయడం.

DuckDB ప్రతి కాలమ్‌ను విడివిడిగా రాసి కంప్రెస్ చేస్తుంది. ఐదు మిలియన్ల రోలలో amount_cents మొత్తాన్ని లెక్కించడానికి amount_cents కాలమ్‌ను మాత్రమే చదువుతుంది, ఫైల్‌లోని మిగిలిన అన్ని బైట్‌లను వదిలేస్తుంది, మరియు విలువల బ్యాచ్‌లపై వెక్టరైజ్డ్ కోడ్ ద్వారా మొత్తాన్ని లెక్కిస్తుంది. ఇతర కాలమ్‌లను డిస్క్ నుండి చదవదు, దీని వల్లే వేగం లభిస్తుంది.

ఇప్పుడు ప్రతి ఇంజిన్‌ను మరొకదాని పనిభారం (workload) కోసం ఉపయోగించి చూడండి. SQLite ఒక కాలమ్ మొత్తాన్ని లెక్కించాలంటే ప్రతి రోను పరిశీలించి, ఒక ఫీల్డ్ కోసం మొత్తం రోను పేజీ నుండి బయటకు తీయాలి, కాబట్టి అది అవసరమైన దానికంటే ఎక్కువ డిస్క్ రీడ్ చేస్తుంది. DuckDB ఒక ఆర్డర్‌ను ఇన్సర్ట్ చేయాలంటే ఒకే విలువ కోసం ప్రతి కాలమ్ స్టోరేజ్‌ను తాకాలి, మరియు అలా చేయడానికి మొత్తం డేటాబేస్ ఫైల్‌పై రైట్ లాక్ (write lock) తీసుకోవాలి. ఏ ఇంజిన్ లోపభూయిష్టమైనది కాదు. ప్రతిదీ అది రూపొందించబడని పనికి సమాధానం ఇస్తోంది.

SQLite ఎక్కడ ఉత్తమమైనది: లావాదేవీల అప్లికేషన్ స్థితి

రైట్‌లు (writes) చిన్నవిగా, తరచుగా జరుగుతూ, మరియు ఏమాత్రం కోల్పోకూడదు అనుకున్నప్పుడు SQLiteని ఎంచుకోండి. సెషన్‌లు, ఆర్డర్‌లు, క్యూ అడ్డు వరుసలు, సెట్టింగ్‌లు, వెబ్ అభ్యర్థన ద్వారా సృష్టించబడే ఏదైనా సరే దీనికి సరిపోతాయి.

sudo apt update && sudo apt install -y sqlite3
sudo install -d -o "$USER" -g "$USER" /srv/app

టేబుల్‌ను సృష్టించి, అదే దశలో రైట్-అహెడ్ లాగింగ్‌ను (write-ahead logging) ఆన్ చేయండి.

sqlite3 /srv/app/app.db <<'SQL'
PRAGMA journal_mode = WAL;
CREATE TABLE IF NOT EXISTS orders (
  id           INTEGER PRIMARY KEY,
  customer     TEXT    NOT NULL,
  placed_at    TEXT    NOT NULL,
  amount_cents INTEGER NOT NULL
);
CREATE INDEX IF NOT EXISTS orders_customer ON orders (customer);
INSERT INTO orders (customer, placed_at, amount_cents)
  VALUES ('ana', '2026-07-30T09:14:00Z', 4200);
SQL

అవుట్‌పుట్‌లోని మొదటి లైన్ wal. ఇది PRAGMA తాను మారిన మోడ్‌ను తెలియజేస్తుంది, మరియు సర్వర్‌లో ఇది అత్యంత ఉపయోగకరమైన సెట్టింగ్. డిఫాల్ట్ రోల్‌బ్యాక్ జర్నల్ మోడ్‌లో, ఒక రైటర్ ప్రతి రీడర్‌ను బ్లాక్ చేస్తుంది. WAL మోడ్‌లో, ఒక రైటర్ డేటాను జోడిస్తున్నప్పుడు కూడా రీడర్‌లు చివరిగా కమిట్ అయిన స్థితిని చదువుతూనే ఉంటారు, కాబట్టి నెమ్మదిగా జరిగే రిపోర్ట్ వెబ్ అభ్యర్థనను ఆపివేయదు.

అడ్డు వరుస (row) వచ్చిందో లేదో తనిఖీ చేయండి:

sqlite3 /srv/app/app.db "SELECT * FROM orders WHERE customer = 'ana';"

మీకు 1|ana|2026-07-30T09:14:00Z|4200 వస్తుంది. డేటాబేస్ పక్కన మరో రెండు ఫైళ్లు app.db-wal మరియు app.db-shm కనిపిస్తాయి, ఇవి రెండూ దానికి చెందినవే. అప్లికేషన్ రన్ అవుతున్నప్పుడు కేవలం app.dbని మాత్రమే కాపీ చేస్తే అది అసంపూర్ణమైన బ్యాకప్‌ను ఇస్తుంది, దీని గురించి కింద మరింత వివరించబడింది.

SQLite ఒక సమయంలో ఒక రైటర్‌ను మాత్రమే అనుమతిస్తుంది. ఆ పరిమితి ఒక లాక్, క్యూ కాదు, కాబట్టి ఎక్కువ సమయం వేచి ఉన్న రెండవ రైటర్ ఎప్పటికీ బ్లాక్ అవ్వకుండా database is lockedతో విఫలమవుతుంది. మీ అప్లికేషన్ తెరిచే ప్రతి కనెక్షన్‌పై PRAGMA busy_timeout = 5000;తో వేచి ఉండే సమయాన్ని పెంచండి. ఐదు సెకన్ల నిరీక్షణ సాధారణ వెబ్ వర్క్‌లోడ్‌లో ఇటువంటి చాలా లోపాలను తొలగిస్తుంది.

DuckDB ఎక్కడ మెరుగ్గా పనిచేస్తుంది: మీ వద్ద ఉన్న ఫైళ్లపై అనలిటిక్స్

ప్రశ్న "ఎన్ని" (how many), "ఎంత" (how much) లేదా "టాప్ టెన్ ఏవి" (which top ten) అని మొదలై, ఇన్‌పుట్ CSV లేదా Parquet ఫైళ్ల సమూహంగా ఉన్నప్పుడు DuckDBని ఎంచుకోండి. జూలై 2026 నాటికి అందుబాటులో ఉన్న 1.5.5 వెర్షన్ కమాండ్ లైన్ క్లయింట్‌ను ఇన్‌స్టాల్ చేయండి:

curl https://install.duckdb.org | sh

ఈ స్క్రిప్ట్ బైనరీని ~/.duckdb/cli/latest/duckdb కింద ఇన్‌స్టాల్ చేస్తుంది మరియు దానిని మీ PATH లో చేర్చే లైన్‌ను ప్రింట్ చేస్తుంది. అది రన్ అవుతుందో లేదో నిర్ధారించుకోండి:

~/.duckdb/cli/latest/duckdb :memory: "SELECT version();"

క్వరీ చేయడానికి ఒక వాస్తవిక ఫైల్‌ను రూపొందించండి. ఇది ఐదు మిలియన్ల ఆర్డర్ల వరుసలను zstdతో కంప్రెస్ చేసి Parquet ఫైల్‌లోకి రాస్తుంది:

mkdir -p /srv/data
duckdb :memory: "
COPY (
  SELECT i                                                     AS id,
         'cust_' || (i % 5000)                                 AS customer,
         TIMESTAMP '2026-01-01 00:00:00' + INTERVAL (i) MINUTE AS placed_at,
         (i * 37) % 20000                                      AS amount_cents
  FROM range(5000000) t(i)
) TO '/srv/data/orders.parquet' (FORMAT parquet, COMPRESSION zstd);"

ఇప్పుడు అనలిటికల్ ప్రశ్నను అడగండి. షెల్‌ను ఓపెన్ చేసి, టైమర్‌ను ఆన్ చేసి, ఎటువంటి ఇంపోర్ట్ దశ లేకుండా నేరుగా ఫైల్‌ను క్వరీ చేయండి:

.timer on
SELECT customer,
       count(*)                AS orders,
       sum(amount_cents)/100.0 AS revenue
FROM '/srv/data/orders.parquet'
GROUP BY customer
ORDER BY revenue DESC
LIMIT 5;

ప్రచురించబడిన సంఖ్యను నమ్మే బదులు, మీ స్వంత సంఖ్యను .timer నుండి చదవండి, ఎందుకంటే ఫలితం మీ డిస్క్ మరియు కోర్ల సంఖ్యపై ఆధారపడి ఉంటుంది. ఇక్కడ ముఖ్యమైనది దాని పనితీరు తీరు. అక్కడ ఎటువంటి CREATE TABLE, INSERT మరియు లోడ్ దశ లేదు: DuckDB Parquet ఫుటర్‌ను చదివి, క్వరీకి ఏ కాలమ్ చంక్స్ అవసరమో గుర్తించి, వాటిని మాత్రమే చదివింది. ఒక పూర్తి డైరెక్టరీ కూడా గ్లోబ్ (glob), FROM '/srv/data/orders-*.parquet' తో ఇదే విధంగా పనిచేస్తుంది, దీని ద్వారానే నెల రోజుల రోజువారీ ఎగుమతులు ఒకే క్వరీగా మారుతాయి.

వీటన్నింటికీ డిస్క్ వేగం ప్రాతిపదికగా ఉంటుంది, మరియు కాలమ్ స్కాన్ అనేది సుదీర్ఘమైన సీక్వెన్షియల్ రీడ్, కాబట్టి VPSలో NVMe మరియు పాత SATA స్టోరేజ్ మధ్య వ్యత్యాసం SQLite యొక్క చిన్న రాండమ్ రీడ్స్ కంటే ఇక్కడ స్పష్టంగా కనిపిస్తుంది.

DuckDB నుండి మీ SQLite డేటాబేస్‌ను చదవడం

DuckDB యొక్క sqlite ఎక్స్‌టెన్షన్ ద్వారా ఈ రెండు ఇంజిన్‌లు అనుసంధానించబడతాయి. అప్లికేషన్ డేటాబేస్‌ను 'read only' మోడ్‌లో అటాచ్ చేయండి, తద్వారా అనలిటిక్స్ క్వెరీ లైవ్ స్టేట్‌లోకి ఎటువంటి డేటాను రాయలేదు:

INSTALL sqlite;
LOAD sqlite;
ATTACH '/srv/app/app.db' AS app (TYPE sqlite, READ_ONLY);
SELECT customer, count(*) AS orders
FROM app.orders
GROUP BY customer
ORDER BY orders DESC;

ఇది డేటాను కాపీ చేయకుండా, క్వెరీ సమయంలోనే SQLite ఫైల్ నుండి వరుసలను (rows) చదువుతుంది. ఇది సౌకర్యవంతంగా ఉంటుంది కానీ వేగంగా ఉండదు, ఎందుకంటే డిస్క్‌లోని డేటా ఇంకా రో స్టోరేజ్ (row storage) రూపంలోనే ఉంటుంది మరియు DuckDB దానిని స్కాన్ చేయాల్సి ఉంటుంది. దీనిని ఎగుమతి (export) కోసం మాత్రమే ఉపయోగించండి, ప్రతి ముప్పై సెకన్లకు రీలోడ్ అయ్యే డాష్‌బోర్డ్ కోసం కాదు:

COPY (SELECT * FROM app.orders)
  TO '/srv/data/orders-2026-07.parquet' (FORMAT parquet, COMPRESSION zstd);

ఈ ఒక్క స్టేట్‌మెంట్‌తోనే మొత్తం ప్రక్రియ పూర్తవుతుంది. ఇటీవలి లైవ్ రోస్ (rows) SQLite ఆధీనంలో ఉంటాయి. షెడ్యూల్ చేసిన ఎగుమతి ద్వారా పూర్తయిన కాలపరిమితి డేటాను Parquet ఫార్మాట్‌లోకి మారుస్తుంది. నెలల తరబడి ఉండే డేటాపై వచ్చే ప్రశ్నలకు DuckDB సమాధానమిస్తుంది, అప్లికేషన్ డేటాబేస్ పరిమాణం తక్కువగా ఉంటుంది, దీనివల్ల రైట్ ఆపరేషన్లు వేగంగా జరుగుతాయి.

ఎగుమతిని మాన్యువల్‌గా కాకుండా షెడ్యూల్ ప్రకారం రన్ చేయండి. దీని కోసం systemd service and timer pair సరైన పద్ధతి: ఒకటి COPYని రన్ చేసే యూనిట్, మరొకటి ప్రతి రాత్రి దానిని ట్రిగ్గర్ చేసే టైమర్.

ఒకే VPSలో రెండింటినీ రన్ చేయడం

ఇక్కడ దేనికీ కంటైనర్ అవసరం లేదు, దేనికీ పోర్ట్ అవసరం లేదు. రెండు ఇంజిన్లు లైబ్రరీలు మాత్రమే, కాబట్టి ఇన్‌స్టాలేషన్ అనేది ఒక ప్యాకేజీ మరియు ఫైల్ పాత్ మాత్రమే. మీ స్టాక్‌లోని మిగిలిన భాగాలు ఇప్పటికే ఒకే VPSలో Docker Compose కింద రన్ అవుతుంటే, డేటాబేస్ సర్వీస్‌ను జోడించే బదులు, డేటా డైరెక్టరీని అవసరమైన కంటైనర్‌లోకి మౌంట్ చేయండి, ఎందుకంటే జోడించడానికి అక్కడ ఎటువంటి సర్వీస్ లేదు.

ఈ అమరికలో సమస్యలు రాకుండా ఉండటానికి రెండు నియమాలు ఉన్నాయి.

ప్రతి ఇంజిన్‌కు దాని స్వంత డైరెక్టరీని కేటాయించండి: అప్లికేషన్ వ్రాసే SQLite ఫైల్ కోసం /srv/app, అనలిటిక్స్ చదివే Parquet ఫైళ్ల కోసం /srv/data. అవి ఒకే డైరెక్టరీని పంచుకున్నప్పుడు, ఒకదానిని స్నాప్‌షాట్ చేసే బ్యాకప్ జాబ్ మరొకదానితో పోటీ పడుతుంది.

రెండు ప్రాసెస్‌లను ఒకే DuckDB డేటాబేస్ ఫైల్‌కు రీడ్-రైట్ మోడ్‌లో పాయింట్ చేయవద్దు. కేవలం ఒక ప్రాసెస్ మాత్రమే DuckDB ఫైల్‌ను రైటింగ్ కోసం ఉంచుకోగలదు, రెండవది దానిని ఓపెన్ చేయడంలో విఫలమవుతుంది. ప్రతి ఒక్కటి access_mode = 'READ_ONLY' సెట్ చేసినప్పుడు, అనేక రీడర్లు ఉండటం సమస్య కాదు. SQLite నుండి వచ్చే వారికి ఇది ఆశ్చర్యం కలిగించవచ్చు, అక్కడ సాధారణంగా అనేక ప్రాసెస్‌లు ఒక ఫైల్‌ను పంచుకుంటాయి. మీ అనలిటిక్స్ కేవలం Parquet ఫైళ్లను మాత్రమే చదువుతుంటే, ఈ ప్రశ్న తలెత్తదు, అందుకే డ్యూరబుల్ స్టేట్‌ను SQLiteలో ఉంచడానికి ఇది మరొక కారణం.

బ్యాకప్‌లు భిన్నంగా ఉంటాయి, ఈ వ్యత్యాసం సమస్యలను కలిగిస్తుంది

నడుస్తున్న SQLite డేటాబేస్ మూడు ఫైళ్లను కలిగి ఉంటుంది. cp ఉపయోగించి వాటిని కాపీ చేసేటప్పుడు, రైటింగ్ జరుగుతుంటే, ఆ ఫైల్ ఓపెన్ అవుతుంది కానీ డేటా తప్పుగా ఉంటుంది. అప్లికేషన్ డేటాను రాస్తున్నప్పుడు కూడా స్థిరమైన స్నాప్‌షాట్‌ను తీసుకునే ఇంజిన్ యొక్క సొంత బ్యాకప్ కమాండ్‌ను ఉపయోగించండి:

sqlite3 /srv/app/app.db ".backup '/srv/backup/app-$(date -u +%Y%m%dT%H%M%SZ).db'"
sqlite3 /srv/backup/app-20260730T091400Z.db "PRAGMA integrity_check;"

కాపీ సరిగ్గా జరిగినప్పుడు integrity_check అనేది ok అని ప్రింట్ చేస్తుంది. వేరే ఏదైనా వస్తే, ఆ స్నాప్‌షాట్‌ను తొలగించి మరొకటి తీసుకోండి.

Parquet ఫైళ్లు ఒకసారి రాసిన తర్వాత మారవు, కాబట్టి వాటికి ప్రత్యేక హ్యాండ్లింగ్ అవసరం లేదు: ఆ డైరెక్టరీని బ్యాకప్ చేయండి. మీ VPS నుండి restic బ్యాకప్‌లు ఉపయోగించి రెండు పాత్‌లను సర్వర్ నుండి పంపండి, అప్పుడు మొత్తం డేటా లేయర్ ఒకే బ్యాకప్ జాబ్‌లో రెండు డైరెక్టరీలుగా ఉంటుంది.

వైఫల్య రీతులు మరియు మీరు చూసే ఖచ్చితమైన స్ట్రింగ్‌లు

SQLite నుండి వచ్చే Error: database is locked అంటే మరొక కనెక్షన్ మీ టైమ్‌అవుట్ అనుమతించిన దానికంటే ఎక్కువ సమయం రైట్ లాక్‌ను కలిగి ఉందని అర్థం. ఇది డేటా కరప్షన్ కాదు. ప్రతి కనెక్షన్‌పై PRAGMA busy_timeoutని సెట్ చేయండి, ఆపై అనేక చిన్న లావాదేవీలుగా ఉండాల్సిన సుదీర్ఘ లావాదేవీ కోసం వెతకండి.

అనుమతి మార్పు తర్వాత వచ్చే Error: unable to open database file అంటే సాధారణంగా ప్రాసెస్ ఫైల్‌ను రాయగలదు కానీ దాని డైరెక్టరీని రాయలేదు అని అర్థం. SQLite డేటాబేస్ పక్కన app.db-wal మరియు app.db-shmలను సృష్టిస్తుంది, కాబట్టి .db ఫైల్ మాత్రమే కాకుండా డైరెక్టరీ కూడా రైటబుల్ అయి ఉండాలి.

DuckDB నుండి వచ్చే IO Error: Could not set lock on file అంటే మరొక ప్రాసెస్ ఇప్పటికే ఆ డేటాబేస్‌ను రైటింగ్ కోసం ఓపెన్ చేసి ఉంచింది అని అర్థం. ఇతర షెల్‌ను క్లోజ్ చేయండి లేదా మీ దానిని రీడ్-ఓన్లీ మోడ్‌లో ఓపెన్ చేయండి.

చిన్న VPSలో DuckDB నుండి వచ్చే Out of Memory Error అంటే క్వెరీకి అందుబాటులో ఉన్న దానికంటే ఎక్కువ వర్కింగ్ మెమరీ అవసరమైందని అర్థం. DuckDB వీలైనప్పుడు డిస్క్‌లోకి డేటాను పంపుతుంది (spill), కాబట్టి :memory:కి బదులుగా డిస్క్‌లోని డేటాబేస్ ఫైల్‌ను ఓపెన్ చేయడం ద్వారా దానికి కొంత స్థలాన్ని ఇవ్వండి మరియు SET memory_limit = '2GB';తో దాని మెమరీ వినియోగాన్ని పరిమితం చేయండి. ఇతర సర్వీసులు నడుస్తున్న బాక్స్‌లో, ఈ పరిమితి అడ్-హాక్ క్వెరీ మీ అప్లికేషన్‌ను RAM నుండి బయటకు నెట్టకుండా ఆపుతుంది.

Parquetని క్వెరీ చేసేటప్పుడు వచ్చే Binder Error: Referenced column "amount" not found అంటే దాదాపు ఎల్లప్పుడూ ఫైల్ స్కీమా మీరు గుర్తుంచుకున్నది కాదని అర్థం. DESCRIBE SELECT * FROM '/srv/data/orders.parquet';ని రన్ చేసి అసలైన కాలమ్ పేర్లను సరిచూసుకోండి.

ఆచరణలో ఎలా ఎంచుకోవాలి

రైట్ ప్యాటర్న్ (write pattern) ఏమిటో అడగండి. పవర్ కట్ అయినా డేటా భద్రంగా ఉండాల్సిన అనేక చిన్న రైట్ ఆపరేషన్లు ఉంటే, SQLite వాడండి. రీడ్ ప్యాటర్న్ (read pattern) ఏమిటో అడగండి. సుదీర్ఘ చరిత్రపై అగ్రిగేట్లతో కూడిన పూర్తి స్కాన్‌లు అవసరమైతే, DuckDB వాడండి. చాలా నిజమైన సిస్టమ్‌లు ఈ రెండు ప్రశ్నలకు అవును అని సమాధానం ఇస్తాయి. అప్పుడు సరైన పద్ధతి ఏమిటంటే, ఒక ఇంజిన్‌పై భారం వేయకుండా, ప్రతి ఇంజిన్‌కు దేనిలో అది సమర్థవంతంగా పనిచేస్తుందో ఆ భాగాన్ని కేటాయించడం.

లైవ్ అప్లికేషన్ స్టేట్‌ను DuckDBకి తరలించడం వంటి మైగ్రేషన్‌ను నివారించాలి, ఎందుకంటే ఒక రిపోర్ట్ నెమ్మదిగా ఉందని మీరు భావించవచ్చు. స్టోరేజ్ లేఅవుట్ కారణంగా రిపోర్ట్ నెమ్మదిగా ఉండవచ్చు, కాబట్టి దానికి పరిష్కారం డేటాను ఎగుమతి (export) చేయడం, మీ రైట్ పాత్‌ను తిరిగి రాయడం కాదు.

FAQ

నా అప్లికేషన్ డేటాబేస్ కోసం SQLite స్థానంలో DuckDBని ఉపయోగించవచ్చా?

తరచుగా డేటాను రాసే అప్లికేషన్లకు ఇది సరిపోదు. DuckDB మొత్తం డేటాబేస్ ఫైల్‌పై రైట్ లాక్ (write lock) వేస్తుంది, ఒక సమయంలో ఒక రీడ్-రైట్ ప్రాసెస్‌ను మాత్రమే అనుమతిస్తుంది, మరియు ఇది సింగిల్-రో ఇన్సర్ట్‌ల కంటే బల్క్ మార్పుల కోసం రూపొందించబడింది. ట్రాన్సాక్షనల్ స్టేట్‌ను SQLiteలోనే ఉంచండి మరియు రిపోర్ట్ అవసరమైనప్పుడు ATTACH '/srv/app/app.db' AS app (TYPE sqlite, READ_ONLY); ద్వారా DuckDBతో దాన్ని చదవండి.

అనలిటిక్స్ కోసం SQLite కంటే DuckDB నిజంగా వేగంగా పనిచేస్తుందా?

పెద్ద టేబుల్స్‌పై స్కాన్‌లు మరియు అగ్రిగేట్‌ల కోసం, అవును. దీనికి కారణం ట్యూనింగ్ ట్రిక్ కాదు, స్టోరేజ్ లేఅవుట్. DuckDB క్వెరీలో పేర్కొన్న కాలమ్స్‌ను మాత్రమే చదువుతుంది మరియు విలువలను బ్యాచ్‌లలో ప్రాసెస్ చేస్తుంది, కానీ SQLite ఒక ఫీల్డ్‌ను చేరుకోవడానికి మొత్తం రోలను స్కాన్ చేయాల్సి ఉంటుంది. ప్రైమరీ కీ ద్వారా ఒకే ఒక రోను పొందాల్సి వచ్చినప్పుడు పరిస్థితి మారుతుంది, ఎందుకంటే SQLite రెండు పేజీలను మాత్రమే తాకుతుంది, కానీ DuckDB ప్రతి కాలమ్ స్టోరేజ్‌ను తాకాల్సి ఉంటుంది.

VPSలో DuckDBని రన్ చేయడానికి ఎక్కువ RAM అవసరమా?

అవసరం లేదు, కానీ దానికి ఒక పరిమితిని మరియు డిస్క్ స్పేస్‌ను కేటాయించండి. :memory:కి బదులుగా డేటాబేస్ ఫైల్‌ను ఓపెన్ చేయండి, తద్వారా DuckDB మధ్యంతర ఫలితాలను డిస్క్‌లోకి పంపగలదు (spill). ఆపై SET memory_limit = '2GB';ని మీ VPS భరించగలిగే విలువకు సెట్ చేయండి. పరిమితి లేకపోతే, ఒక పెద్ద GROUP BY వల్ల Out of Memory Error రావచ్చు లేదా ఇతర సర్వీసులు RAM నుండి తొలగించబడవచ్చు.

నా SQLite డేటాను Parquet ఫార్మాట్‌లోకి ఎలా మార్చాలి?

DuckDB నుండి SQLite ఫైల్‌ను అటాచ్ చేయండి మరియు COPY (SELECT * FROM app.orders) TO '/srv/data/orders.parquet' (FORMAT parquet, COMPRESSION zstd); ఉపయోగించి క్వెరీని నేరుగా కాపీ చేయండి. గత నెల రోస్ వంటి పూర్తయిన కాలాల కోసం దీన్ని షెడ్యూల్ ప్రకారం రన్ చేయండి, మరియు అప్లికేషన్ ఇంకా రాస్తున్న ఇటీవలి రోస్‌ను SQLiteలోనే ఉంచండి.

దేనిని బ్యాకప్ చేయాలి, ఎలా చేయాలి?

రెండింటినీ వేర్వేరు పద్ధతుల్లో బ్యాకప్ చేయాలి. SQLite స్నాప్‌షాట్‌లను cpకి బదులుగా sqlite3 app.db ".backup '/srv/backup/app.db'" ఉపయోగించి తీసుకోండి, ఎందుకంటే రన్ అవుతున్న డేటాబేస్ ఒక -wal మరియు -shm ఫైల్ కూడా, కాబట్టి సాధారణ కాపీ డేటాను దెబ్బతీయవచ్చు (torn). Parquet ఫైల్స్ ఒకసారి రాసిన తర్వాత మారవు, కాబట్టి ఆ డైరెక్టరీని కాపీ చేయడం సరిపోతుంది.