SQLite – chatgpz.de – KI-Tools & Praxiswissen https://chatgpz.de Unabhängige Tests, Anleitungen und Hintergründe zu KI-Tools. Sat, 18 Oct 2025 04:54:39 +0000 de-DE hourly 1 https://wordpress.org/?v=6.4.2 234900186 Erstellen einer Textual content-to-SQL-App mit OpenAI + FastAPI + SQLite https://chatgpz.de/data-analytics/erstellen-einer-textual-content-to-sql-app-mit-openai-fastapi-sqlite/ https://chatgpz.de/data-analytics/erstellen-einer-textual-content-to-sql-app-mit-openai-fastapi-sqlite/#respond Sat, 18 Oct 2025 04:54:39 +0000 http://chatgpz.de/data-analytics/erstellen-einer-text-to-sql-app-mit-openai-fastapi-sqlite/ [ad_1]

Erstellen einer Text-to-SQL-App mit OpenAI + FastAPI + SQLiteErstellen einer Text-to-SQL-App mit OpenAI + FastAPI + SQLiteBild vom Autor

# Einführung

Daten sind zu einer unverzichtbaren Ressource für jedes erfolgreiche Unternehmen geworden, da sie wertvolle Erkenntnisse für eine fundierte Entscheidungsfindung liefern. Angesichts der Bedeutung von Daten bauen viele Unternehmen Systeme zur Speicherung und Analyse dieser Daten auf. Allerdings kommt es oft vor, dass es schwierig ist, die notwendigen Daten zu erfassen und zu analysieren, insbesondere angesichts der zunehmenden Komplexität des Datensystems.

Mit dem Aufkommen der generativen KI ist die Datenverarbeitung erheblich einfacher geworden, da wir jetzt einfache natürliche Sprache verwenden können, um eine weitgehend genaue Ausgabe zu erhalten, die der von uns bereitgestellten Eingabe genau entspricht. Es ist auch auf die Datenverarbeitung und -analyse mit SQL anwendbar, wo wir die Entwicklung von Abfragen anfordern können.

In diesem Artikel entwickeln wir eine einfache API-Anwendung, die natürliche Sprache in SQL-Abfragen übersetzt, die unsere Datenbank versteht. Wir werden drei Hauptwerkzeuge verwenden: OpenAI, FastAPIUnd SQLite.

Hier ist der Plan.

# Entwicklung von Textual content-to-SQL-Apps

Zunächst bereiten wir alles vor, was wir für unser Projekt benötigen. Alles, was Sie angeben müssen, ist die OpenAI-API-Schlüsselmit dem wir auf das generative Modell zugreifen. Um die Anwendung zu containerisieren, verwenden wir Dockerdie Sie für die lokale Implementierung mit erwerben können Docker-Desktop.

Andere Komponenten wie SQLite sind bereits bei der Set up von Python verfügbar und FastAPI wird später installiert.

Für die Gesamtprojektstruktur verwenden wir Folgendes:

text_to_sql_app/
├── app/
│   ├── __init__.py          
│   ├── database.py           
│   ├── openai_utils.py       
│   └── predominant.py               
├── demo.db                   
├── init_db.sql               
├── necessities.txt          
├── Dockerfile                
├── docker-compose.yml        
├── .env

Erstellen Sie die Struktur wie oben, oder verwenden Sie Folgendes Repository um die Dinge einfacher zu machen. Wir werden weiterhin jede Datei durchgehen, um zu verstehen, wie die Anwendung entwickelt wird.

Beginnen wir mit dem Auffüllen der .env Datei mit dem OpenAI-API-Schlüssel, den wir zuvor erworben haben. Das können Sie mit dem folgenden Code machen:

OPENAI_API_KEY=YOUR-API-KEY

Dann gehen Sie zu necessities.txt um die notwendigen Bibliotheken auszufüllen, die wir verwenden werden

fastapi
uvicorn
sqlalchemy
openai
pydantic
python-dotenv

Als nächstes gehen wir weiter zum __init__.py Datei, und wir werden den folgenden Code einfügen:

from pathlib import Path
from dotenv import load_dotenv

load_dotenv(dotenv_path=Path(__file__).resolve().mum or dad.mum or dad / ".env", override=False)

Der obige Code stellt sicher, dass die Umgebung alle notwendigen Schlüssel enthält, die wir benötigen.

Dann werden wir Python-Code entwickeln database.py Datei zum Herstellen einer Verbindung mit der SQLite-Datenbank, die wir später erstellen werden (genanntdemo.db) und bieten eine Möglichkeit zum Ausführen von SQL-Abfragen.

from sqlalchemy import create_engine, textual content
from sqlalchemy.orm import Session

ENGINE = create_engine("sqlite:///demo.db", future=True, echo=False)

def run_query(sql: str) -> checklist(dict):
    with Session(ENGINE) as session:
        rows = session.execute(textual content(sql)).mappings().all()
    return (dict(r) for r in rows)

Danach bereiten wir die vor openai_utils.py Datei, die das Datenbankschema und die Eingabefragen akzeptiert. Die Ausgabe erfolgt im JSON-Format und enthält die SQL-Abfrage (mit einem Schutz, der Schreibvorgänge verhindert).

import os
import json
from openai import OpenAI        

consumer = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

_SYSTEM_PROMPT = """
You exchange natural-language questions into read-only SQLite SQL.
By no means output INSERT / UPDATE / DELETE.
Return JSON: { "sql": "..." }.
"""

def text_to_sql(query: str, schema: str) -> str:
    response = consumer.chat.completions.create(
        mannequin="gpt-4o-mini",        
        temperature=0.1,
        response_format={"kind": "json_object"},
        messages=(
            {"function": "system", "content material": _SYSTEM_PROMPT},
            {"function": "consumer",
             "content material": f"schema:n{schema}nnquestion: {query}"}
        )
    )
    payload = json.hundreds(response.selections(0).message.content material)
    return payload("sql")

Wenn sowohl der Code als auch die Verbindung bereit sind, bereiten wir die Anwendung mithilfe von FastAPI vor. Die Anwendung akzeptiert Fragen in natürlicher Sprache und das Datenbankschema und konvertiert sie in SQL SELECT Abfragen durchführen, sie über die SQLite-Datenbank ausführen und die Ergebnisse als JSON zurückgeben. Bei der Anwendung handelt es sich um eine API, auf die wir über die CLI zugreifen können.

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from sqlalchemy import examine
from .database import ENGINE, run_query
from .openai_utils import text_to_sql

app = FastAPI(title="Textual content-to-SQL Demo")

class NLRequest(BaseModel):
    query: str

@app.on_event("startup")
def capture_schema() -> None:
    insp = examine(ENGINE)
    international SCHEMA_STR
    SCHEMA_STR = "n".be part of(
        f"CREATE TABLE {t} ({', '.be part of(c('identify') for c in insp.get_columns
        for t in insp.get_table_names()
    )

@app.publish("/question")
def question(req: NLRequest):
    strive:
        sql = text_to_sql(req.query, SCHEMA_STR)
        if not sql.lstrip().decrease().startswith("choose"):
            elevate ValueError("Solely SELECT statements are allowed")
        return {"sql": sql, "end result": run_query(sql)}
    besides Exception as e:
        elevate HTTPException(status_code=400, element=str(e))

Das ist alles, was wir für die Hauptanwendung benötigen. Als nächstes bereiten wir die Datenbank vor. Nutzen Sie die Datenbank unten im init_db.sql B. für Zwecke, aber Sie können es jederzeit ändern, wenn Sie möchten.


DROP TABLE IF EXISTS order_items;
DROP TABLE IF EXISTS orders;
DROP TABLE IF EXISTS funds;
DROP TABLE IF EXISTS merchandise;
DROP TABLE IF EXISTS clients;

CREATE TABLE clients (
    id INTEGER PRIMARY KEY,
    identify TEXT NOT NULL,
    nation TEXT,
    signup_date DATE
);

CREATE TABLE merchandise (
    id INTEGER PRIMARY KEY,
    identify TEXT NOT NULL,
    class TEXT,
    value REAL
);

CREATE TABLE orders (
    id INTEGER PRIMARY KEY,
    customer_id INTEGER,
    order_date DATE,
    whole REAL,
    FOREIGN KEY (customer_id) REFERENCES clients(id)
);

CREATE TABLE order_items (
    order_id INTEGER,
    product_id INTEGER,
    amount INTEGER,
    unit_price REAL,
    PRIMARY KEY (order_id, product_id),
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES merchandise(id)
);

CREATE TABLE funds (
    id INTEGER PRIMARY KEY,
    order_id INTEGER,
    payment_date DATE,
    quantity REAL,
    technique TEXT,
    FOREIGN KEY (order_id) REFERENCES orders(id)
);

INSERT INTO clients (id, identify, nation, signup_date) VALUES
 (1,'Alice','USA','2024-01-05'),
 (2,'Bob','UK','2024-03-10'),
 (3,'Choi','KR','2024-06-22'),
 (4,'Dara','ID','2025-01-15');

INSERT INTO merchandise (id, identify, class, value) VALUES
 (1,'Laptop computer Professional','Electronics',1500.00),
 (2,'Noise-Canceling Headphones','Electronics',300.00),
 (3,'Standing Desk','Furnishings',450.00),
 (4,'Ergonomic Chair','Furnishings',250.00),
 (5,'Monitor 27"','Electronics',350.00);

INSERT INTO orders (id, customer_id, order_date, whole) VALUES
 (1,1,'2025-02-01',1850.00),
 (2,2,'2025-02-03',600.00),
 (3,3,'2025-02-05',350.00),
 (4,1,'2025-02-07',450.00);

INSERT INTO order_items (order_id, product_id, amount, unit_price) VALUES
 (1,1,1,1500.00),
 (1,2,1,300.00),
 (1,5,1,350.00),
 (2,3,1,450.00),
 (2,4,1,250.00),
 (3,5,1,350.00),
 (4,3,1,450.00);

INSERT INTO funds (id, order_id, payment_date, quantity, technique) VALUES
 (1,1,'2025-02-01',1850.00,'Credit score Card'),
 (2,2,'2025-02-03',600.00,'PayPal'),
 (3,3,'2025-02-05',350.00,'Credit score Card'),
 (4,4,'2025-02-07',450.00,'Financial institution Switch');

Führen Sie dann den folgenden Code in Ihrer CLI aus, um eine SQLite-Datenbank für unser Projekt zu erstellen.

sqlite3 demo.db < init_db.sql  

Wenn die Datenbank fertig ist, erstellen wir eine Dockerfile um unsere Anwendung zu containerisieren.

FROM python:3.12-slim
WORKDIR /code

COPY necessities.txt .
RUN pip set up --no-cache-dir -r necessities.txt

COPY . .

CMD ("uvicorn", "app.predominant:app", "--host", "0.0.0.0", "--port", "8000")

Wir werden auch eine erstellen docker-compose.yml Datei für eine reibungslosere Ausführung der Anwendung.

providers:
  text2sql:
    construct: .
    env_file: .env    
    ports:
      - "8000:8000"    
    restart: unless-stopped
    volumes:
      - ./demo.db:/code/demo.db

Wenn alles fertig ist, starten Sie Ihren Docker Desktop und führen Sie den folgenden Code aus, um die Anwendung zu erstellen.

docker compose construct --no-cache   
docker compose up -d 

Wenn alles intestine gemacht ist, können Sie die Anwendung mithilfe des folgenden Codes testen. Wir werden fragen, wie viele Kunden wir in den Daten haben.

curl -X POST "http://localhost:8000/question" -H "Content material-Sort: software/json" -d "{"query":"What number of clients?"}"

Die Ausgabe wird so aussehen.

{"sql":"SELECT COUNT(*) AS customer_count FROM clients;","end result":({"customer_count":4})}

Wir können etwas Komplexeres ausprobieren, beispielsweise die Anzahl der Bestellungen für jeden Kunden:

curl -X POST "http://localhost:8000/question" -H "Content material-Sort: software/json" -d "{"query":"What's the variety of orders positioned by every buyer"}"

Mit Ausgabe wie unten.

{"sql":"SELECT customer_id, COUNT(*) AS number_of_orders FROM orders GROUP BY customer_id;","end result":({"customer_id":1,"number_of_orders":2},{"customer_id":2,"number_of_orders":1},{"customer_id":3,"number_of_orders":1})}

Das ist alles, was Sie zum Erstellen einer einfachen Textual content-to-SQL-Anwendung benötigen. Sie können es mit einer Entrance-Finish-Schnittstelle und einem komplexeren, auf Ihre Bedürfnisse zugeschnittenen System weiter ausbauen.

# Zusammenfassung

Daten sind das Herzstück jeder Datenarbeit und Unternehmen nutzen sie, um Entscheidungen zu treffen. Oft ist das System, das wir haben, zu komplex und wir müssen uns auf generative KI verlassen, um uns darin zurechtzufinden.

In diesem Artikel haben wir gelernt, wie man eine einfache Textual content-to-SQL-Anwendung mit dem OpenAI-Modell, FastAPI und SQLite entwickelt.

Ich hoffe, das hat geholfen!

Cornellius Yudha Wijaya ist stellvertretender Supervisor und Datenautor im Bereich Information Science. Während er Vollzeit bei Allianz Indonesia arbeitet, teilt er gerne Python- und Datentipps über soziale Medien und Schreibmedien. Cornellius schreibt über eine Vielzahl von Themen zu KI und maschinellem Lernen.

[ad_2]

]]>
https://chatgpz.de/data-analytics/erstellen-einer-textual-content-to-sql-app-mit-openai-fastapi-sqlite/feed/ 0 13261
Wir haben DuckDB, SQLite und Pandas in 1 Million Zeilen verglichen: Folgendes ist passiert https://chatgpz.de/data-analytics/wir-haben-duckdb-sqlite-und-pandas-in-1-million-zeilen-verglichen-folgendes-ist-passiert/ https://chatgpz.de/data-analytics/wir-haben-duckdb-sqlite-und-pandas-in-1-million-zeilen-verglichen-folgendes-ist-passiert/#respond Fri, 10 Oct 2025 22:25:18 +0000 http://chatgpz.de/data-analytics/wir-haben-duckdb-sqlite-und-pandas-in-1-million-zeilen-verglichen-folgendes-ist-passiert/ [ad_1]

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas
Bild vom Autor

# Einführung

Es gibt heute zahlreiche Instruments zur Verarbeitung von Datensätzen. Sie alle behaupten – und das tun sie natürlich auch –, dass sie die beste und richtige Wahl für Sie sind. Aber sind sie es? Es gibt zwei Hauptanforderungen, die diese Instruments erfüllen sollten: Sie sollten alltägliche Datenanalysevorgänge einfach und schnell durchführen, selbst unter dem Druck großer Datenmengen.

Um das beste Werkzeug zu ermitteln DuckDB, SQLiteUnd Pandaswir haben sie unter diesen Bedingungen getestet.

Zunächst gaben wir ihnen nur alltägliche Analyseaufgaben: Summieren von Werten, Gruppieren nach Kategorien, Filtern mit Bedingungen und Aggregationen mehrerer Felder. Dies spiegelte wider, wie Analysten tatsächlich mit realen Datensätzen arbeiten, im Vergleich zu Szenarien, die darauf ausgelegt sind, die besten Eigenschaften eines Instruments darzustellen.

Zweitens haben wir diese Operationen an einem Kaggle-Datensatz mit über 1 Million Zeilen durchgeführt. Es ist ein realistischer Wendepunkt – klein genug, um auf einem einzelnen Laptop ausgeführt zu werden, aber groß genug, dass Speicherdruck und Abfragegeschwindigkeit deutliche Unterschiede zwischen den Instruments erkennen lassen.

Mal sehen, wie diese Exams verlaufen sind.

# Der von uns verwendete Datensatz

// Datensatzübersicht

Wir haben den Bankdatensatz von verwendet Kaggle. Dieser Datensatz enthält über 1 Million Zeilen, bestehend aus fünf Spalten:

Spaltenname Beschreibung
Datum Das Datum, an dem die Transaktion stattgefunden hat
Area Die Unternehmenskategorie oder -art (EINZELHANDEL, RESTAURANT)
Standort Geografische Area (Goa, Mathura)
Wert Transaktionswert
Transaktionsanzahl Die Gesamtzahl der Transaktionen an diesem Tag

Dieser Datensatz wird mit Python generiert. Auch wenn es möglicherweise nicht ganz den realen Daten ähnelt, reichen Größe und Struktur aus, um die Leistungsunterschiede zwischen den Instruments zu testen und zu vergleichen.

// Mit Pandas einen Blick in die Daten werfen

Wir haben verwendet Pandas um den Datensatz in ein Jupyter-Notizbuch zu laden und seine allgemeine Struktur, Abmessungen und Nullwerte zu untersuchen. Hier ist der Code.

import pandas as pd
df = pd.read_excel('bankdataset.xlsx')

print("Dataset form:", df.form)

df.head()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

Wenn Sie einen schnellen Überblick über gängige Vorgänge beim Durchsuchen von Datensätzen benötigen, schauen Sie sich dieses praktische Handbuch an Pandas-Spickzettel.

Sehen wir uns vor dem Benchmarking an, wie die Umgebung eingerichtet wird.

# Einrichten einer fairen Testumgebung

Alle drei Instruments – DuckDB, SQLite und Pandas – wurden in derselben Jupyter Pocket book-Umgebung eingerichtet und ausgeführt, um sicherzustellen, dass der Check truthful battle. Dadurch wurde sichergestellt, dass die Bedingungen zur Laufzeit und die Speichernutzung durchgehend konstant blieben.

Zuerst haben wir die notwendigen Pakete installiert und geladen.

Hier sind die Instruments, die wir brauchten:

  • Pandas: für Normal DataFrame Operationen
  • duckdb: für die SQL-Ausführung auf a DataFrame
  • sqlite3: zum Verwalten einer eingebetteten SQL-Datenbank
  • Zeit: zum Erfassen der Ausführungszeit
  • Memory_profiler: um die Speicherzuordnung zu messen
# Set up if any of them should not in your surroundings
!pip set up duckdb --quiet

import pandas as pd
import duckdb
import sqlite3
import time
from memory_profiler import memory_usage

Bereiten wir nun die Daten in einem Format vor, das von allen drei Instruments gemeinsam genutzt werden kann.

// Daten in Pandas laden

Wir verwenden Pandas, um den Datensatz einmal zu laden, und geben ihn dann für DuckDB und SQLite frei oder registrieren ihn.

df = pd.read_excel('bankdataset.xlsx')

df.head()

Hier ist die zu validierende Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Registrieren von Daten bei DuckDB

Mit DuckDB können Sie direkt auf Pandas zugreifen DataFrameS. Sie müssen nichts umrechnen – einfach registrieren und abfragen. Hier ist der Code.

# Register DataFrame as a DuckDB desk
duckdb.register("bank_data", df)

# Question through DuckDB
duckdb.question("SELECT * FROM bank_data LIMIT 5").to_df()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Vorbereiten von Daten für SQLite

Da SQLite Excel-Dateien nicht direkt liest, haben wir zunächst die Pandas hinzugefügt DataFrame an eine In-Reminiscence-Datenbank. Anschließend verwendeten wir eine einfache Abfrage, um das Datenformat zu untersuchen.

conn_sqlite = sqlite3.join(":reminiscence:")

df.to_sql("bank_data", conn_sqlite, index=False, if_exists="change")

pd.read_sql_query("SELECT * FROM bank_data LIMIT 5", conn_sqlite)

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

# Wie wir die Instruments bewertet haben

Wir haben dieselben vier Abfragen für DuckDB, SQLite und Pandas verwendet, um ihre Leistung zu vergleichen. Jede Abfrage wurde für eine allgemeine Analyseaufgabe entwickelt, die widerspiegelt, wie die Datenanalyse in der realen Welt angewendet wird.

// Sicherstellung einer konsistenten Einrichtung

Der In-Reminiscence-Datensatz wurde von allen drei Instruments verwendet.

  • Pandas befragte die DataFrame direkt
  • DuckDB führte SQL-Abfragen direkt gegen die aus DataFrame
  • SQLite hat eine Kopie davon gespeichert DataFrame in einer In-Reminiscence-Datenbank und führte darauf SQL-Abfragen aus

Diese Methode stellte sicher, dass alle drei Instruments dieselben Daten verwendeten und mit denselben Systemeinstellungen arbeiteten.

// Messung der Ausführungszeit

Um die Abfragedauer zu verfolgen, verwendet Python time Das Modul verpackte jede Abfrage in einen einfachen Begin-/Finish-Timer. Es wurde nur die Ausführungszeit der Abfrage aufgezeichnet; Datenlade- und Vorbereitungsschritte wurden ausgeschlossen.

// Verfolgen der Speichernutzung

Zusammen mit der Verarbeitungszeit zeigt die Speichernutzung an, wie intestine jede Engine bei großen Datenmengen funktioniert.

Bei Bedarf kann die Speichernutzung unmittelbar vor und nach jeder Abfrage abgetastet werden, um den inkrementellen RAM-Verbrauch abzuschätzen.

// Die Benchmark-Abfragen

Wir haben jede Engine anhand derselben vier alltäglichen Analyseaufgaben getestet:

  1. Gesamttransaktionswert: Summieren einer numerischen Spalte
  2. Nach Domäne gruppieren: Aggregieren der Transaktionszahlen professional Kategorie
  3. Nach Standort filtern: Zeilen werden vor der Aggregation nach einer Bedingung gefiltert
  4. Gruppieren nach Domäne und Standort: Mehrfeldaggregation mit Durchschnittswerten

# Benchmark-Ergebnisse

// Abfrage 1: Gesamttransaktionswert

Hier messen wir, wie Pandas, DuckDB und SQLite bei der Summierung abschneiden Worth Spalte im gesamten Datensatz.

// Pandas-Leistung

Wir berechnen den Gesamttransaktionswert anhand von .sum() auf der Worth Spalte. Hier ist der Code.

pandas_results = ()

def pandas_q1():
    return df('Worth').sum()

mem_before = memory_usage(-1)(0)
begin = time.time()
pandas_q1()
finish = time.time()
mem_after = memory_usage(-1)(0)

pandas_results.append({
    "engine": "Pandas",
    "question": "Complete transaction worth",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})
pandas_results

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// DuckDB-Leistung

Wir berechnen den Gesamttransaktionswert mithilfe einer Vollspaltenaggregation. Hier ist der Code.

duckdb_results = ()

def duckdb_q1():
    return duckdb.question("SELECT SUM(worth) FROM bank_data").to_df()

mem_before = memory_usage(-1)(0)
begin = time.time()
duckdb_q1()
finish = time.time()
mem_after = memory_usage(-1)(0)

duckdb_results.append({
    "engine": "DuckDB",
    "question": "Complete transaction worth",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})
duckdb_results

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// SQLite-Leistung

Wir berechnen den gesamten Transaktionswert durch Summieren worth Spalte. Hier ist der Code.

sqlite_results = ()

def sqlite_q1():
    return pd.read_sql_query("SELECT SUM(worth) FROM bank_data", conn_sqlite)

mem_before = memory_usage(-1)(0)
begin = time.time()
sqlite_q1()
finish = time.time()
mem_after = memory_usage(-1)(0)

sqlite_results.append({
    "engine": "SQLite",
    "question": "Complete transaction worth",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})
sqlite_results

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Gesamtleistungsanalyse

Vergleichen wir nun die Ausführungszeit und die Speichernutzung. Hier ist der Code.

import matplotlib.pyplot as plt


all_q1 = pd.DataFrame(pandas_results + duckdb_results + sqlite_results)

fig, axes = plt.subplots(1, 2, figsize=(10,4))

all_q1.plot(x="engine", y="time", form="barh", ax=axes(0), legend=False, title="Execution Time (s)")
all_q1.plot(x="engine", y="reminiscence", form="barh", colour="salmon", ax=axes(1), legend=False, title="Reminiscence Utilization (MB)")

plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

Pandas ist bei weitem das schnellste und speichereffizienteste hier und wird bei minimaler RAM-Nutzung quick sofort ausgeführt. DuckDB ist etwas langsamer und benötigt mehr Speicher, bleibt aber effizient, während SQLite sowohl am langsamsten als auch am höchsten im Hinblick auf den Speicherverbrauch ist.

// Abfrage 2: Nach Domäne gruppieren

Hier messen wir die Leistung von Pandas, DuckDB und SQLite beim Gruppieren von Transaktionen Area und summieren ihre Zählungen.

// Pandas-Leistung

Wir berechnen die Gesamttransaktionszahl professional Area anhand von .groupby() auf der Area Spalte.

def pandas_q2():
    return df.groupby('Area')('Transaction_count').sum()

mem_before = memory_usage(-1)(0)
begin = time.time()
pandas_q2()
finish = time.time()
mem_after = memory_usage(-1)(0)

pandas_results.append({
    "engine": "Pandas",
    "question": "Group by area",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})
(p for p in pandas_results if p("question") == "Group by area")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// DuckDB-Leistung

Wir berechnen die Gesamtzahl der Transaktionen professional Area mithilfe einer SQL-Anweisung GROUP BY auf der area Spalte.

def duckdb_q2():
    return duckdb.question("""
        SELECT area, SUM(transaction_count) 
        FROM bank_data 
        GROUP BY area
    """).to_df()

mem_before = memory_usage(-1)(0)
begin = time.time()
duckdb_q2()
finish = time.time()
mem_after = memory_usage(-1)(0)

duckdb_results.append({
    "engine": "DuckDB",
    "question": "Group by area",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in duckdb_results if p("question") == "Group by area")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// SQLite-Leistung

Wir berechnen die Gesamtzahl der Transaktionen professional Area mithilfe von SQL GROUP BY auf der In-Reminiscence-Tabelle.

def sqlite_q2():
    return pd.read_sql_query("""
        SELECT area, SUM(transaction_count) AS total_txn
        FROM bank_data
        GROUP BY area
    """, conn_sqlite)

mem_before = memory_usage(-1)(0)
begin = time.time()
sqlite_q2()
finish = time.time()
mem_after = memory_usage(-1)(0)

sqlite_results.append({
    "engine": "SQLite",
    "question": "Group by area",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in sqlite_results if p("question") == "Group by area")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Gesamtleistungsanalyse

Vergleichen wir nun die Ausführungszeit und die Speichernutzung. Hier ist der Code.

import pandas as pd
import matplotlib.pyplot as plt

groupby_results = (r for r in (pandas_results + duckdb_results + sqlite_results) 
                   if "Group by" in r("question"))

df_groupby = pd.DataFrame(groupby_results)

fig, axes = plt.subplots(1, 2, figsize=(10,4))

df_groupby.plot(x="engine", y="time", form="barh", ax=axes(0), legend=False, title="Execution Time (s)")
df_groupby.plot(x="engine", y="reminiscence", form="barh", colour="salmon", ax=axes(1), legend=False, title="Reminiscence Utilization (MB)")

plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

DuckDB ist am schnellsten, Pandas benötigt etwas mehr Zeit für weniger Speicher, während SQLite sowohl am langsamsten als auch am speicherintensivsten ist.

// Abfrage 3: Nach Standort filtern (Goa)

Hier messen wir die Leistung von Pandas, DuckDB und SQLite beim Filtern des Datensatzes Location = 'Goa' und Summieren der Transaktionswerte.

// Pandas-Leistung

Wir filtern Zeilen nach Location == 'Goa' und summieren ihre Werte. Hier ist der Code.

def pandas_q3():
    return df(df('Location') == 'Goa')('Worth').sum()

mem_before = memory_usage(-1)(0)
begin = time.time()
pandas_q3()
finish = time.time()
mem_after = memory_usage(-1)(0)

pandas_results.append({
    "engine": "Pandas",
    "question": "Filter by location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in pandas_results if p("question") == "Filter by location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// DuckDB-Leistung

Wir filtern Transaktionen nach Location = 'Goa' und berechnen Sie ihren Gesamtwert. Hier ist der Code.

def duckdb_q3():
    return duckdb.question("""
        SELECT SUM(worth) 
        FROM bank_data 
        WHERE location = 'Goa'
    """).to_df()

mem_before = memory_usage(-1)(0)
begin = time.time()
duckdb_q3()
finish = time.time()
mem_after = memory_usage(-1)(0)

duckdb_results.append({
    "engine": "DuckDB",
    "question": "Filter by location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in duckdb_results if p("question") == "Filter by location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// SQLite-Leistung

Wir filtern Transaktionen nach Location = 'Goa' und summieren ihre Werte. Hier ist der Code.

def sqlite_q3():
    return pd.read_sql_query("""
        SELECT SUM(worth) AS total_value
        FROM bank_data
        WHERE location = 'Goa'
    """, conn_sqlite)

mem_before = memory_usage(-1)(0)
begin = time.time()
sqlite_q3()
finish = time.time()
mem_after = memory_usage(-1)(0)

sqlite_results.append({
    "engine": "SQLite",
    "question": "Filter by location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in sqlite_results if p("question") == "Filter by location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Gesamtleistungsanalyse

Vergleichen wir nun die Ausführungszeit und die Speichernutzung. Hier ist der Code.

import pandas as pd
import matplotlib.pyplot as plt

filter_results = (r for r in (pandas_results + duckdb_results + sqlite_results)
                  if r("question") == "Filter by location")

df_filter = pd.DataFrame(filter_results)

fig, axes = plt.subplots(1, 2, figsize=(10, 4))

df_filter.plot(x="engine", y="time", form="barh", ax=axes(0), legend=False, title="Execution Time (s)")
df_filter.plot(x="engine", y="reminiscence", form="barh", colour="salmon", ax=axes(1), legend=False, title="Reminiscence Utilization (MB)")

plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

DuckDB ist die schnellste und effizienteste; Pandas ist bei höherer Speichernutzung langsamer; und SQLite ist am langsamsten, benötigt aber weniger Speicher.

// Abfrage 4: Gruppieren nach Domäne und Standort

// Pandas-Leistung

Wir berechnen den durchschnittlichen Transaktionswert gruppiert nach beiden Area Und Location. Hier ist der Code.

def pandas_q4():
    return df.groupby(('Area', 'Location'))('Worth').imply()

mem_before = memory_usage(-1)(0)
begin = time.time()
pandas_q4()
finish = time.time()
mem_after = memory_usage(-1)(0)

pandas_results.append({
    "engine": "Pandas",
    "question": "Group by area & location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in pandas_results if p("question") == "Group by area & location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// DuckDB-Leistung

Wir berechnen den durchschnittlichen Transaktionswert gruppiert nach beiden area Und location. Hier ist der Code.

def duckdb_q4():
    return duckdb.question("""
        SELECT area, location, AVG(worth) AS avg_value
        FROM bank_data
        GROUP BY area, location
    """).to_df()

mem_before = memory_usage(-1)(0)
begin = time.time()
duckdb_q4()
finish = time.time()
mem_after = memory_usage(-1)(0)

duckdb_results.append({
    "engine": "DuckDB",
    "question": "Group by area & location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in duckdb_results if p("question") == "Group by area & location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// SQLite-Leistung

Wir berechnen den durchschnittlichen Transaktionswert gruppiert nach beiden area Und location. Hier ist der Code.

def sqlite_q4():
    return pd.read_sql_query("""
        SELECT area, location, AVG(worth) AS avg_value
        FROM bank_data
        GROUP BY area, location
    """, conn_sqlite)

mem_before = memory_usage(-1)(0)
begin = time.time()
sqlite_q4()
finish = time.time()
mem_after = memory_usage(-1)(0)

sqlite_results.append({
    "engine": "SQLite",
    "question": "Group by area & location",
    "time": spherical(finish - begin, 4),
    "reminiscence": spherical(mem_after - mem_before, 4)
})

(p for p in sqlite_results if p("question") == "Group by area & location")

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

// Gesamtleistungsanalyse

Vergleichen wir nun die Ausführungszeit und die Speichernutzung. Hier ist der Code.

import pandas as pd
import matplotlib.pyplot as plt

gdl_results = (r for r in (pandas_results + duckdb_results + sqlite_results)
               if r("question") == "Group by area & location")

df_gdl = pd.DataFrame(gdl_results)

fig, axes = plt.subplots(1, 2, figsize=(10, 4))

df_gdl.plot(x="engine", y="time", form="barh", ax=axes(0), legend=False,
            title="Execution Time (s)")
df_gdl.plot(x="engine", y="reminiscence", form="barh", ax=axes(1), legend=False,
            title="Reminiscence Utilization (MB)", colour="salmon")

plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

DuckDB verarbeitet Mehrfeld-Gruppierungen am schnellsten bei mäßiger Speichernutzung, Pandas ist bei sehr hoher Speichernutzung langsamer und SQLite ist bei erheblichem Speicherverbrauch am langsamsten.

# Endgültiger Vergleich aller Abfragen

Wir haben diese drei Engines hinsichtlich Speicher und Geschwindigkeit miteinander verglichen. Schauen wir uns noch einmal die Ausführungszeit an. Hier ist der Code.

import pandas as pd
import matplotlib.pyplot as plt

all_results = pd.DataFrame(pandas_results + duckdb_results + sqlite_results)

measure_order = (
    "Complete transaction worth",
    "Group by area",
    "Filter by location",
    "Group by area & location",
)
engine_colors = {"Pandas": "#1f77b4", "DuckDB": "#ff7f0e", "SQLite": "#2ca02c"}

fig, axes = plt.subplots(2, 2, figsize=(12, 8))
axes = axes.ravel()

for i, q in enumerate(measure_order):
    d = all_results(all_results("question") == q)
    axes(i).barh(d("engine"), d("time"), 
                 colour=(engine_colors(e) for e in d("engine")))
    for y, v in enumerate(d("time")):
        axes(i).textual content(v, y, f" {v:.3f}", va="heart")
    axes(i).set_title(q, fontsize=10)
    axes(i).set_xlabel("Seconds")

fig.suptitle("Per-Measure Comparability — Execution Time", fontsize=14)
plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

Dieses Diagramm zeigt, dass DuckDB bei quick allen Abfragen durchweg die niedrigsten Ausführungszeiten aufweist, mit Ausnahme des Gesamttransaktionswerts, bei dem Pandas die Nase vorn hat. SQLite ist auf der ganzen Linie mit Abstand das langsamste. Lassen Sie uns als nächstes den Speicher überprüfen. Hier ist der Code.

import pandas as pd
import matplotlib.pyplot as plt

all_results = pd.DataFrame(pandas_results + duckdb_results + sqlite_results)

measure_order = (
    "Complete transaction worth",
    "Group by area",
    "Filter by location",
    "Group by area & location",
)
engine_colors = {"Pandas": "#1f77b4", "DuckDB": "#ff7f0e", "SQLite": "#2ca02c"}

fig, axes = plt.subplots(2, 2, figsize=(12, 8))
axes = axes.ravel()

for i, q in enumerate(measure_order):
    d = all_results(all_results("question") == q)
    axes(i).barh(d("engine"), d("reminiscence"), 
                 colour=(engine_colors(e) for e in d("engine")))
    for y, v in enumerate(d("reminiscence")):
        axes(i).textual content(v, y, f" {v:.1f}", va="heart")
    axes(i).set_title(q, fontsize=10)
    axes(i).set_xlabel("MB")

fig.suptitle("Per-Measure Comparability — Reminiscence Utilization", fontsize=14)
plt.tight_layout()
plt.present()

Hier ist die Ausgabe.

DuckDB vs. SQLite vs. PandasDuckDB vs. SQLite vs. Pandas

Dieses Diagramm zeigt, dass SQLite bei der Speichernutzung zwischen der besten und der schlechtesten Leistung schwankt, Pandas mit zwei besten und zwei schlechtesten Fällen extrem ist, während DuckDB bei allen Abfragen konstant im Mittelfeld bleibt. Infolgedessen erweist sich DuckDB insgesamt als die ausgewogenste Wahl und liefert eine konstant schnelle Leistung bei moderater Speichernutzung. Pandas zeigt Excessive – manchmal die schnellsten, manchmal die schwersten –, während SQLite mit der Geschwindigkeit zu kämpfen hat und beim Speicher oft auf der ineffizienten Seite landet.

Nate Rosidi ist Datenwissenschaftler und in der Produktstrategie tätig. Er ist außerdem außerordentlicher Professor für Analytik und Gründer von StrataScratch, einer Plattform, die Datenwissenschaftlern hilft, sich mit echten Interviewfragen von High-Unternehmen auf ihre Interviews vorzubereiten. Nate schreibt über die neuesten Traits auf dem Karrieremarkt, gibt Ratschläge zu Vorstellungsgesprächen, stellt Knowledge-Science-Projekte vor und behandelt alles rund um SQL.



[ad_2]

]]>
https://chatgpz.de/data-analytics/wir-haben-duckdb-sqlite-und-pandas-in-1-million-zeilen-verglichen-folgendes-ist-passiert/feed/ 0 13073