Garis keturunan InfluxDB

InfluxDB 3.x bukan versi mayor yang berbentuk peningkatan inkremental terhadap versi sebelumnya, melainkan desain ulang dari nol yang memutus garis keturunan teknis 1.x dan 2.x. Topik ini menelusuri tiga era InfluxDB dalam satu pelajaran, yaitu era 1.x dengan mesin penyimpanan TSM dan InfluxQL, era 2.x yang memperkenalkan Flux beserta model bucket, lalu era 3.x yang membangun kembali storage di atas Apache Arrow dan mengangkat SQL menjadi bahasa query utama. Setelah membaca topik ini, alasan 3.x disebut sebagai patahan, bukan kelanjutan, menjadi jelas.

Era 1.x: TSM dan InfluxQL#

InfluxDB 1.x memperkenalkan format penulisan line protocol dan mesin penyimpanan Time-Structured Merge Tree (TSM) yang dirancang untuk menyerap telemetri berkecepatan tinggi. TSM menyimpan data dalam bentuk baris yang dikelompokkan per seri, dan setiap seri adalah kombinasi unik dari measurement serta keseluruhan nilai tag. InfluxQL menjadi bahasa query utama, dengan sintaks yang menyerupai SQL tetapi tidak dapat dieksekusi pada basis data relasional, sebab klausa GROUP BY pada InfluxQL mengelompokkan per tag atau per jendela waktu, bukan per kolom biasa. Konsep skema berputar di sekitar measurement, tag, field, retention policy, dan database sebagai unit organisasi paling atas.

Kelemahan paling kentara era 1.x adalah series cardinality explosion. Bila salah satu tag memuat ID unik per perangkat, jumlah seri tumbuh linier dengan jumlah perangkat, dan setiap seri menyimpan indeks, struktur kompresi, serta metadata tersendiri di dalam memori. Pada beban IoT dengan jutaan perangkat unik, basis data 1.x mudah tumbang sebelum mencapai kapasitas disk yang sebenarnya, sebab memori habis lebih dulu untuk indeks seri. Pola ini menjadi alasan utama banyak pengguna IoT yang akhirnya berpindah ke TimescaleDB atau ke mesin kolumnar lain pada era berikutnya.

Era 2.x: Flux dan model bucket#

InfluxDB 2.x mempertahankan TSM sebagai mesin penyimpanan, sehingga kelemahan struktural 1.x tidak benar-benar hilang. Yang berubah adalah bahasa query dan model organisasi. Flux diperkenalkan sebagai bahasa utama, yaitu bahasa fungsional dengan pipe operator yang mampu berinteraksi dengan sumber data eksternal dan menyusun pipeline transformasi yang panjang. Pada level skema, database diganti menjadi bucket, dan organization serta token menjadi unit autentikasi wajib yang memperketat model multi-tenant. Konsep measurement, tag, dan field tetap dipertahankan tanpa perubahan, sehingga kompleksitas model data 1.x tidak berkurang, melainkan hanya dibungkus istilah baru.

Flux sangat ekspresif untuk pipeline yang panjang, tetapi kurva belajarnya curam bagi pengguna yang terbiasa dengan SQL, dan bahasa ini tidak punya padanan pada mesin lain. Banyak pengguna yang mengeluhkan bahwa transformasi sederhana, misalnya rerata bergerak atau join dua deret, memerlukan sintaks yang tidak intuitif dan eksekusi yang lambat pada data besar. Selain itu, ekosistem alat di luar InfluxDB tidak mengadopsi Flux, sehingga keahlian yang dibangun tidak portabel. Posisi Flux pada akhirnya menjadi beban, bukan keunggulan, dan ini menjadi salah satu alasan kuat untuk desain ulang pada 3.x.

Patahan pada 3.x#

InfluxDB 3.x memutus garis keturunan teknis kedua era sebelumnya. Mesin penyimpanan TSM ditinggalkan dan diganti dengan Apache Arrow sebagai format in-memory serta Apache Parquet sebagai format on-disk, sehingga data disimpan dalam tata letak kolumnar, bukan per seri. Apache DataFusion menjadi mesin query, dan SQL diangkat menjadi bahasa utama, sedangkan InfluxQL tetap didukung sebagai opsi kompatibilitas untuk pengguna 1.x yang bermigrasi, dan Flux dinyatakan tidak akan dikembangkan lebih lanjut. Pada level skema, bucket kembali menjadi database, measurement menjadi table, sedangkan tag dan field menjadi kolom biasa yang dapat digunakan dalam klausa SQL apa pun.

Pilihan desain ini menyederhanakan model data sekaligus membuka pintu pada ekosistem alat yang sudah mahir dengan Arrow, Parquet, dan SQL. Sebuah berkas Parquet yang ditulis oleh InfluxDB 3.x dapat dibaca langsung oleh DuckDB, pandas, atau Spark, sehingga basis data tidak lagi menjadi pulau. Diagram berikut memperlihatkan tiga era dalam satu pandangan, beserta komponen kunci yang berubah pada setiap peralihan.

Alasan desain ulang#

Tiga kelemahan struktural era 1.x dan 2.x menjadi alasan desain ulang 3.x. Pertama, series cardinality explosion pada TSM membatasi skala pada beban IoT dengan jutaan perangkat unik, sehingga penambahan perangkat keras tidak menyelesaikan masalah, sebab hambatannya ada di struktur penyimpanan. Kedua, Flux tidak diadopsi oleh ekosistem di luar InfluxDB, sehingga pengguna harus mempelajari bahasa yang tidak portabel ke mesin lain. Ketiga, TSM adalah row store yang dioptimalkan untuk penulisan, tetapi lemah pada query analitik yang menyentuh banyak kolom sekaligus, sebab setiap pembacaan harus melewati dekompresi per seri.

Apache Arrow dan DataFusion mengatasi ketiganya sekaligus. Format kolumnar menyingkirkan seri sebagai unit penyimpanan, sehingga kardinalitas tag tidak lagi menjadi beban memori yang linier. SQL menjadi bahasa yang akrab di banyak ekosistem, sehingga keahlian pengguna menjadi portabel. Column pruning membuat query analitik menjadi efisien tanpa membebani penulisan, sebab kolom yang tidak disentuh tidak perlu dibaca dari disk. Skrip berikut merangkum perbedaan tiga era dalam bentuk tabel yang dicetak ke layar, sebagai ringkasan mekanis yang dapat dibaca ulang.

"""Cetak ringkasan tiga era InfluxDB sebagai tabel perbandingan.

Skrip ini tidak menjalankan SQL atau perintah influx. Tujuannya menyusun
ringkasan mekanis atas perbedaan tiga era InfluxDB sebagai tabel cetak,
agar pembaca dapat melihat sekilas komponen mana yang berubah dan mana
yang bertahan dari 1.x ke 2.x ke 3.x.
"""

ERA = [
    {
        "era": "1.x",
        "storage": "TSM (row store, per seri)",
        "query": "InfluxQL (mirip SQL, tidak portabel)",
        "organisasi": "database, retention policy",
        "skema": "measurement / tag / field",
    },
    {
        "era": "2.x",
        "storage": "TSM (row store, per seri)",
        "query": "Flux (fungsional, pipe operator)",
        "organisasi": "organization, bucket, token",
        "skema": "measurement / tag / field",
    },
    {
        "era": "3.x",
        "storage": "Apache Arrow + Parquet (kolumnar)",
        "query": "SQL (DataFusion), InfluxQL kompatibilitas",
        "organisasi": "database, table",
        "skema": "table / kolom tag / kolom field",
    },
]

KEPALA = ("era", "storage", "query", "organisasi", "skema")


def main() -> None:
    lebar = {k: max(len(k), max(len(baris[k]) for baris in ERA)) for k in KEPALA}
    garis = "+" + "+".join("-" * (lebar[k] + 2) for k in KEPALA) + "+"
    print(garis)
    print("| " + " | ".join(k.upper().ljust(lebar[k]) for k in KEPALA) + " |")
    print(garis)
    for baris in ERA:
        print("| " + " | ".join(baris[k].ljust(lebar[k]) for k in KEPALA) + " |")
    print(garis)
    print()
    print("Yang berubah dari 2.x ke 3.x: storage, query, organisasi, dan skema.")
    print("Yang bertahan dari 1.x ke 2.x: storage dan skema (TSM + measurement/tag/field).")


if __name__ == "__main__":
    main()

+-----+-----------------------------------+-------------------------------------------+-----------------------------+---------------------------------+
| ERA | STORAGE                           | QUERY                                     | ORGANISASI                  | SKEMA                           |
+-----+-----------------------------------+-------------------------------------------+-----------------------------+---------------------------------+
| 1.x | TSM (row store, per seri)         | InfluxQL (mirip SQL, tidak portabel)      | database, retention policy  | measurement / tag / field       |
| 2.x | TSM (row store, per seri)         | Flux (fungsional, pipe operator)          | organization, bucket, token | measurement / tag / field       |
| 3.x | Apache Arrow + Parquet (kolumnar) | SQL (DataFusion), InfluxQL kompatibilitas | database, table             | table / kolom tag / kolom field |
+-----+-----------------------------------+-------------------------------------------+-----------------------------+---------------------------------+

Yang berubah dari 2.x ke 3.x: storage, query, organisasi, dan skema.
Yang bertahan dari 1.x ke 2.x: storage dan skema (TSM + measurement/tag/field).

Tabel di atas memperlihatkan bahwa 1.x dan 2.x berbagi storage dan skema, sedangkan 3.x berbeda pada seluruh dimensi. Karena itu, peralihan dari 2.x ke 3.x sebaiknya diperlakukan sebagai migrasi ke produk baru, bukan upgrade versi. Banyak praktik lama, misalnya merancang skema untuk menghindari ledakan seri, tidak lagi relevan pada 3.x, sebab mesin penyimpanan yang menjadi sumber masalah sudah diganti.

Kesalahan umum#

• Menganggap 3.x sebagai kelanjutan 2.x sehingga menulis ulang Flux dengan harapan sintaks lama tetap berjalan. Flux memang masih didukung pada beberapa lini 3.x sebagai opsi kompatibilitas, tetapi pengembangannya telah dihentikan, sehingga kode baru sebaiknya ditulis dalam SQL.
• Membawa asumsi kardinalitas tag dari 1.x ke 3.x dengan tetap membatasi jumlah tag unik secara ketat. Pada 3.x, ledakan seri tidak terjadi sebab storage kolumnar tidak mengindeks per seri, sehingga batas praktis berbeda jauh, meskipun kardinalitas tetap memengaruhi ukuran metadata.
• Mengabaikan kenyataan bahwa Parquet menjadi format on-disk pada 3.x. Bila proses eksternal mengharapkan berkas TSM, integrasi rusak, sebab berkas .tsm tidak ada lagi dan diganti berkas .parquet yang dapat dibuka oleh banyak alat.

Ringkasan#

• InfluxDB 1.x dan 2.x berbagi mesin penyimpanan TSM serta model skema measurement/tag/field, sehingga 2.x sebenarnya adalah perubahan bahasa query dan organisasi, bukan perubahan struktural.
• InfluxDB 3.x memutus garis keturunan dengan mengganti TSM menjadi Apache Arrow dan Parquet, mengganti Flux menjadi SQL di atas DataFusion, dan menyederhanakan model organisasi menjadi database dan table.
• Peralihan dari 2.x ke 3.x sebaiknya diperlakukan sebagai migrasi ke produk baru, bukan upgrade versi, sebab seluruh komponen inti berubah sekaligus.

Referensi#

• InfluxDB 3 Core documentation — InfluxData — Pintu masuk dokumentasi resmi InfluxDB 3 Core, termasuk konsep database, table, dan query SQL.
• InfluxDB architectural overview — InfluxData — Penjelasan resmi tentang arsitektur 3.x dan posisinya terhadap 1.x dan 2.x.
• Apache Arrow — The Apache Software Foundation — Spesifikasi format kolumnar in-memory yang menjadi dasar penyimpanan InfluxDB 3.x.