Topik ini membandingkan Lindorm dengan database open source lainnya.
Informasi latar belakang
Lindorm kompatibel dengan berbagai API standar, seperti Apache HBase, S3, TSDB, HDFS, dan Apache Solr. Layanan ini mendukung berbagai model data, termasuk wide table, time series, object, text, queue, dan spatial. Lindorm ideal untuk menyimpan dan menganalisis berbagai jenis data seperti log, tagihan, dan tag, dengan kinerja tinggi serta biaya rendah.
Topik ini membandingkan Lindorm dengan alternatif open source seperti Apache HBase, OpenTSDB, Elasticsearch, Apache Solr, dan HDFS. Perbandingan mencakup fitur inti, kinerja, dan biaya untuk membantu Anda memahami keunggulan Lindorm.
Perbandingan fitur
Lindorm vs. Apache HBase
LindormTable adalah mesin penyimpanan terdistribusi yang dirancang untuk volume besar data terstruktur dan semi-terstruktur. Layanan ini kompatibel dengan API standar open source, termasuk Apache HBase dan Phoenix (SQL). Tabel berikut membandingkan LindormTable dengan Apache HBase.
|
Fitur |
Lindorm |
Apache HBase |
|
|
Fitur inti |
Model data |
Mendukung berbagai model data, seperti wide table, time series, search, dan file. Model wide table mendukung beberapa endpoint dan API. |
Hanya wide table |
|
Akses API |
Mendukung HBase API dan Phoenix SQL. Data dapat saling dioperasikan di berbagai endpoint. |
HBase API atau Phoenix SQL |
|
|
SQL |
Kompatibel dengan JDBC dan Phoenix, menawarkan stabilitas dan kinerja unggul. |
Memerlukan dukungan eksternal Phoenix. |
|
|
Tipe data |
Mendukung beragam tipe data. Untuk informasi selengkapnya, lihat Tipe data. |
Hanya mendukung |
|
|
TTL |
Menyediakan TTL tingkat enterprise pada level tabel, baris, dan sel. |
Mendukung TTL level tabel dan sel. |
|
|
Konsistensi kuat |
Mendukung berbagai tingkat konsistensi, termasuk konsistensi kuat dan konsistensi akhir. |
Didukung |
|
|
Indeks sekunder global |
Menyediakan indeks sekunder global bawaan. Fitur ini memungkinkan kueri transparan, memberikan kinerja tinggi, dan memungkinkan redundansi on-demand untuk kolom non-indeks. |
Memerlukan konfigurasi kompleks komponen eksternal. |
|
|
Pengambilan multi-dimensi |
Berintegrasi secara mulus dengan LindormSearch untuk menyediakan akses terpadu bagi penyimpanan data skala besar, kueri multi-dimensi, dan pencarian teks lengkap. Untuk informasi selengkapnya, lihat Ikhtisar indeks pencarian. |
Tidak didukung |
|
|
Kinerja |
Throughput |
Memberikan throughput hingga 7 kali lipat dari satu node Apache HBase. Untuk informasi selengkapnya, lihat Analisis hasil pengujian. |
Tidak berlaku |
|
Lonjakan latensi permintaan |
Mengurangi latensi P99 menjadi sepersepuluh dari Apache HBase. Untuk informasi selengkapnya, lihat Analisis hasil pengujian. |
Sering terjadi lonjakan latensi |
|
|
Biaya |
Biaya penyimpanan |
Menawarkan berbagai jenis penyimpanan, seperti Performance, Standard, dan Capacity, mengurangi biaya hingga 80% dibandingkan instans self-managed pada cloud disk. |
Berdasarkan cloud disk atau disk lokal self-managed, yang mahal dan tidak elastis. |
|
Pemisahan komputasi dan penyimpanan |
Ya. Resource penyimpanan dan komputasi dapat diskalakan secara independen. |
Tidak |
|
|
Kompresi data |
Menggunakan algoritma kompresi bawaan yang dioptimalkan secara mendalam untuk mencapai rasio kompresi lebih dari 10:1, yang lebih dari 50% lebih tinggi daripada Snappy. |
Mendukung Snappy, LZ4, dan LZO, tetapi rasio kompresinya rendah. |
|
|
Encoding |
Menggunakan encoding adaptif yang mempertimbangkan tipe data untuk mencapai rasio kompresi tinggi. Hal ini memungkinkan pencarian cepat tanpa decoding. |
Mendukung DIFF dengan kompresi moderat. Data yang di-encode tidak dapat dicari. |
|
|
Pemisahan data hot dan cold |
Secara otomatis melakukan tiering data. Data cold dipindahkan ke penyimpanan hemat biaya dengan kompresi tinggi untuk mengurangi biaya hingga 80%, sekaligus meningkatkan kinerja akses data hot sebesar 15%. Untuk informasi selengkapnya, lihat Pemisahan data hot dan cold. |
Tidak didukung |
|
|
Skalabilitas dan elastisitas |
Skala minimum |
Tidak berlaku. |
Minimal 3 node |
|
Skalabilitas |
Sangat skalabel. Mendukung skalabilitas horizontal hingga ribuan node. |
Sangat skalabel. Mendukung skalabilitas horizontal hingga ribuan node. |
|
|
Keandalan |
Redundansi aktif-aktif |
Menyediakan kemampuan lanjutan seperti failover pemulihan bencana otomatis dan permintaan konkuren di dua kluster. Mendukung pembangunan arsitektur hybrid primary/standby dengan kluster Apache HBase self-managed. |
Bukan fitur yang diprodukkan. Failover tidak didukung. |
|
Konsistensi kuat lintas-AZ |
Mendukung penerapan lintas availability zone (AZ), memastikan pemulihan otomatis dan konsistensi data kuat jika terjadi kegagalan tingkat AZ. |
Tidak didukung |
|
|
Backup dan pemulihan |
Mendukung backup dataset yang lebih besar dari 100 TB ke OSS. Menyediakan fitur lanjutan seperti backup on-demand, pemulihan pada titik waktu (PITR), dan Recovery Time Objective (RTO) kurang dari 30 menit yang tidak bergantung pada ukuran data. Untuk informasi selengkapnya, lihat Aktifkan backup dan pemulihan. |
Didukung, tetapi dengan kemampuan terbatas. |
|
|
Redundansi geo aktif |
Didukung. Memungkinkan penerapan di beberapa wilayah geografis dan unit dengan sinkronisasi data on-demand. |
Tidak didukung |
|
|
Multi-tenancy dan keamanan |
Otentikasi dan ACL |
Mendukung otentikasi username dan password serta ACL. Untuk informasi selengkapnya, lihat Kelola pengguna. |
Tidak didukung |
|
Isolasi resource |
Menyediakan kelompok sumber daya untuk mengaktifkan isolasi fisik resource antar penyewa. |
Tidak didukung |
|
|
Kuota |
Mendukung kuota global untuk penyewa, termasuk permintaan dan penyimpanan. |
Tidak mendukung multi-tenancy. |
|
|
Enkripsi saat diam |
Didukung. Kunci dikelola oleh KMS, dan semua data serta log dienkripsi. |
Didukung, tetapi dengan kemampuan terbatas. |
|
|
Blacklist RPC |
Mendukung blacklist RPC untuk membatasi panggilan tertentu. |
Tidak didukung |
|
|
Auditing |
Saat ini tidak didukung. |
Tidak didukung |
|
|
Fitur lanjutan |
Keranjang daur ulang tabel |
Lindorm memindahkan tabel yang dihapus ke keranjang daur ulang, tempat tabel tersebut dapat dipulihkan untuk mencegah kehilangan data akibat kesalahan. |
Tidak didukung |
|
Pemisahan bertingkat |
Region dapat dipisah secara berturut-turut tanpa menunggu compaction selesai, secara signifikan meningkatkan skalabilitas dan load balancing. |
Tidak didukung |
|
|
TTL diskrit |
Memungkinkan Anda menyimpan data dari beberapa periode waktu yang tidak berurutan. |
Tidak didukung |
|
|
Operasi dan diagnostik |
Tool O&M |
Menyediakan tool manajemen kluster berbasis GUI untuk mengelola tabel, namespace, kelompok, dan ACL. Untuk informasi selengkapnya, lihat Masuk ke sistem manajemen kluster. |
HBase Shell |
|
Kueri data |
Mendukung kueri SQL interaktif dalam sistem manajemen kluster berbasis GUI. Untuk informasi selengkapnya, lihat Kueri Data. Juga mendukung tool open source seperti HBase Shell dan CQLsh. |
HBase Shell |
|
|
Ekosistem |
Migrasi data |
Mendukung migrasi online, lintas-versi, otomatis, dan efisien dari berbagai versi Apache HBase. Proses migrasi tidak berdampak pada aplikasi Anda dan tidak memerlukan perubahan kode. Untuk informasi selengkapnya, lihat Lindorm Tunnel Service. |
Hanya migrasi offline yang didukung. |
|
Sinkronisasi data MySQL |
Mendukung impor penuh dan sinkronisasi inkremental data MySQL ke Lindorm menggunakan Lindorm Tunnel Service. |
Memerlukan tool pihak ketiga. Tidak mendukung sinkronisasi inkremental online. |
|
|
Analisis Spark |
Menawarkan integrasi produk yang mendalam. Anda dapat melakukan sinkronisasi inkremental data Lindorm ke Spark, menganalisisnya dengan Spark SQL, dan menulis kembali hasilnya ke Lindorm. |
Tidak dioptimalkan. Integrasi data memerlukan upaya pengembangan signifikan. |
|
|
MaxCompute |
Menyediakan integrasi produk untuk mengarsipkan data Lindorm secara inkremental ke MaxCompute. |
Integrasi data memerlukan upaya pengembangan signifikan. |
|
|
Log Service |
Mendukung langganan data real-time dari Log Service ke Lindorm menggunakan Lindorm Tunnel Service. |
Integrasi data memerlukan upaya pengembangan signifikan. |
|
|
Layanan dan dukungan |
SLA ketersediaan |
Didukung oleh SLA. Menyediakan ketersediaan 99,95% untuk instans single-AZ dan 99,975% untuk instans multi-AZ. |
Tidak disediakan |
|
Biaya operasional |
Layanan terkelola penuh yang menghilangkan kebutuhan akan operasi database kompleks. |
Biaya operasional tinggi |
|
|
Tim teknis |
Tim ahli yang terdiri dari anggota Apache Project Management Committee (PMC) dan Committers menyediakan dukungan teknis. |
Tidak disediakan |
|
|
Pengalaman terbukti |
Telah terbukti pada skala besar dengan puluhan ribu instans yang diterapkan, mendukung Festival Belanja Global 11.11 Alibaba selama sembilan tahun. |
Tidak berlaku |
|
Lindorm vs. OpenTSDB
LindormTSDB adalah mesin database deret waktu berkinerja tinggi, hemat biaya, dan andal. Layanan ini menyediakan operasi baca/tulis yang efisien, rasio kompresi data tinggi, serta agregasi data deret waktu. LindormTSDB sangat kompatibel dengan protokol OpenTSDB dan memberikan kemampuan deret waktu yang kuat melalui teknologi proprietary untuk indexing, pemodelan data, dan agregasi aliran. Tabel berikut membandingkan LindormTSDB dengan OpenTSDB.
|
Fitur |
LindormTSDB |
OpenTSDB |
|
|
Operasi dan manajemen |
Ketersediaan layanan |
99,9% |
Anda harus membangun dan mengelola kluster serta dependensi untuk memastikan ketersediaan. |
|
Keandalan data |
99,9999% |
Anda harus membangun dan mengelola kluster serta dependensi untuk memastikan keandalan. |
|
|
Investasi perangkat keras dan perangkat lunak |
Tidak ada investasi perangkat keras atau perangkat lunak. Pay as you go. |
Biaya relatif tinggi untuk server database. |
|
|
Biaya pemeliharaan |
Layanan terkelola |
Memerlukan administrator basis data (DBA) khusus, menyebabkan biaya tenaga kerja tinggi. |
|
|
Penerapan dan penskalaan |
Menyediakan aktivasi instan, penerapan cepat, dan skalabilitas elastis. |
Memerlukan waktu untuk pengadaan perangkat keras, hosting pusat data, dan penerapan mesin. |
|
|
Dependensi |
Tanpa O&M |
Tergantung pada AsyncHBase dan HBase, yang menyebabkan biaya operasional tinggi. |
|
|
Penyetelan parameter |
Menggunakan parameter default berdasarkan praktik terbaik. |
Memerlukan penyetelan manual parameter seperti SALT, jumlah koneksi, flushing sinkron, dan compaction. |
|
|
Pernyataan pembuatan tabel |
Pembuatan tabel dikelola oleh layanan dan transparan bagi pengguna. |
Memerlukan personel O&M untuk menulis pernyataan pembuatan tabel statis. |
|
|
Pemantauan dan peringatan |
Menyediakan pipeline pemantauan mandiri yang lengkap. |
Memerlukan tool eksternal untuk penyiapan. |
|
|
Fitur |
Model data |
Mendukung model data multi-nilai dan nilai tunggal. |
Hanya mendukung model data nilai tunggal. |
|
SDK |
Java SDK |
SDK open source tidak mendukung kueri. |
|
|
Variasi tipe data |
Mendukung berbagai tipe data, seperti numerik, boolean, dan string. |
Hanya mendukung tipe numerik. |
|
|
Kemampuan kueri SQL |
Mendukung SQL untuk kueri analitis. |
Tidak didukung |
|
|
Dukungan karakter Tionghoa |
Mendukung karakter Inggris dan Tionghoa. |
Hanya mendukung karakter Inggris. |
|
|
Persyaratan tag |
Tag bersifat opsional. |
Tag wajib digunakan. |
|
|
Jumlah kunci tag |
Hingga 16 |
Hingga 8 |
|
|
Integrasi |
Menawarkan ekosistem kaya dengan integrasi tanpa hambatan dengan Flink dan IoT Platform. |
Sebagai produk open source, memiliki kemampuan integrasi terbatas dengan layanan cloud. |
|
|
Biaya penyimpanan |
Kompresi data |
Menggunakan algoritma kompresi khusus untuk data deret waktu, mencapai rasio kompresi tinggi. |
Menggunakan algoritma kompresi tujuan umum, menghasilkan rasio kompresi rendah. |
|
Stabilitas |
Bacaan data |
Memisahkan kolam thread baca dan tulis untuk manajemen koneksi yang mudah dan kinerja baca/tulis yang stabil. |
Menggabungkan operasi baca dan tulis, yang dapat menyebabkan kehabisan koneksi dan tingkat kegagalan baca/tulis tinggi. |
|
Agregator |
Menggunakan agregasi aliran dengan manajemen memori detail halus untuk kontrol lebih baik. |
Menggunakan agregasi materialisasi in-memory, yang mudah menyebabkan error kehabisan memori (OOM). |
|
LindormSearch vs. Elasticsearch dan Solr
LindormSearch adalah mesin pencarian dan penyimpanan terdistribusi yang dirancang untuk dataset skala besar. Layanan ini kompatibel dengan API standar Apache Solr. Tabel berikut membandingkan LindormSearch dengan Elasticsearch dan Apache Solr.
|
Fitur |
LindormSearch |
Elasticsearch |
Apache Solr |
|
|
Fitur inti |
Model data |
Mendukung berbagai model data, seperti wide table, time series, search, dan file. Mesin pencarian dapat berfungsi secara mulus sebagai penyimpanan indeks untuk mesin lainnya. |
Hanya pencarian |
Hanya pencarian |
|
Akses API |
Mendukung Phoenix SQL dan Solr API. |
ES API |
Solr API |
|
|
TTL |
Menyediakan TTL tingkat enterprise pada berbagai granularitas, seperti tabel dan baris. |
Hanya TTL level tabel yang didukung. |
Hanya TTL level tabel yang didukung. |
|
|
Penyimpanan dan pengambilan terpadu |
Berintegrasi secara mulus dengan LindormTable dan LindormTSDB untuk menyediakan penyimpanan dan pengambilan multi-modal terpadu. |
Tidak berlaku |
Tidak berlaku |
|
|
Kinerja dan biaya |
Throughput |
Memberikan throughput 130% hingga 200% dari satu node Apache Solr. |
Tidak berlaku |
Tidak berlaku |
|
Biaya penyimpanan |
Menawarkan berbagai jenis penyimpanan, seperti Performance, Standard, dan Capacity. Mengurangi biaya penyimpanan hingga 80% dibandingkan instans self-managed pada cloud disk. |
Berdasarkan cloud disk atau disk lokal self-managed, yang mahal dan tidak elastis. |
Berdasarkan cloud disk atau disk lokal self-managed, yang mahal dan tidak elastis. |
|
|
Pemisahan komputasi dan penyimpanan |
Ya. Resource penyimpanan dan komputasi dapat diskalakan secara independen. |
Tidak |
Tidak |
|
|
Kompresi data |
Menggunakan algoritma kompresi bawaan yang dioptimalkan secara mendalam untuk mencapai rasio kompresi lebih dari 10:1, yang lebih dari 50% lebih tinggi daripada Snappy. |
Tidak berlaku |
Tidak berlaku |
|
|
Pemisahan data hot dan cold |
Secara otomatis memisahkan data ke dalam tabel berdasarkan atribut waktu. Data cold menggunakan penyimpanan hemat biaya dengan kompresi tinggi untuk mengurangi biaya, sekaligus meningkatkan kinerja akses data hot. |
Tidak didukung |
Tidak didukung |
|
|
Elastisitas |
Elastisitas penyimpanan |
Tinggi. Memisahkan penyimpanan dari komputasi dan mendukung penskalaan satu klik. Penskalaan penyimpanan berlaku dalam hitungan detik, dan penskalaan komputasi berlaku dalam hitungan menit. |
Rendah. Penskalaan keluar memerlukan migrasi data dan memakan waktu berjam-jam. |
Rendah. Penskalaan keluar memerlukan migrasi data dan memakan waktu berjam-jam. |
|
Penulis tunggal, pembaca ganda |
Shard data mendukung model penulis tunggal, pembaca ganda. Replika baca saja dapat diskalakan secara horizontal online, dengan perubahan berlaku dalam hitungan detik. |
Didukung, tetapi penambahan replika baca saja memerlukan migrasi data dan memakan waktu berjam-jam. |
Didukung, tetapi penambahan replika baca saja memerlukan migrasi data dan memakan waktu berjam-jam. |
|
|
Ekosistem |
Migrasi data |
Mendukung migrasi data online, otomatis, dan efisien dari kluster Apache Solr atau Elasticsearch ke Lindorm tanpa dampak pada aplikasi atau perubahan kode. Untuk informasi selengkapnya, lihat Lindorm Tunnel Service. |
Hanya migrasi offline yang didukung. |
Hanya migrasi offline yang didukung. |
|
Sinkronisasi data MySQL |
Mendukung impor penuh dan sinkronisasi inkremental data MySQL ke Lindorm menggunakan Lindorm Tunnel Service. |
Memerlukan tool pihak ketiga. Tidak mendukung sinkronisasi inkremental online. |
Memerlukan tool pihak ketiga. Tidak mendukung sinkronisasi inkremental online. |
|
|
Analisis Spark |
Menawarkan integrasi produk yang mendalam. Anda dapat menganalisis data Lindorm dengan Spark SQL, melakukan sinkronisasi inkremental data Lindorm ke Spark, dan menulis kembali hasil analisis offline ke Lindorm. |
Tidak dioptimalkan. Integrasi data memerlukan upaya pengembangan signifikan. |
Tidak dioptimalkan. Integrasi data memerlukan upaya pengembangan signifikan. |
|
|
Log Service |
Mendukung langganan data real-time dari Log Service ke Lindorm menggunakan Lindorm Tunnel Service. |
Integrasi data memerlukan upaya pengembangan signifikan. |
Integrasi data memerlukan upaya pengembangan signifikan. |
|
|
Layanan dan dukungan |
SLA ketersediaan |
Didukung oleh SLA. Menyediakan ketersediaan 99,95% untuk instans single-AZ dan 99,975% untuk instans multi-AZ. |
Tidak disediakan |
Tidak disediakan |
|
Biaya operasional |
Layanan terkelola penuh yang menghilangkan kebutuhan akan operasi database kompleks. |
Tidak berlaku |
Tidak berlaku |
|
|
Tim teknis |
Tim ahli yang terdiri dari anggota Apache PMC dan Committers menyediakan dukungan teknis. |
Tidak disediakan |
Tidak disediakan |
|
|
Pengalaman terbukti |
Telah terbukti pada skala besar dengan puluhan ribu instans yang diterapkan, mendukung Festival Belanja Global 11.11 Alibaba selama sembilan tahun. |
Tidak berlaku |
Tidak berlaku |
|
Lindorm vs. HDFS
LindormDFS adalah layanan penyimpanan file cloud-native yang kompatibel dengan protokol HDFS. Tabel berikut membandingkan LindormDFS dengan HDFS.
|
Fitur |
LindormDFS |
HDFS |
|
|
Posisi produk |
Sistem file terdistribusi |
Sistem file terdistribusi |
|
|
Kompatibilitas HDFS |
Protokol komunikasi HDFS |
Didukung |
Didukung |
|
API baca/tulis dasar |
Didukung sepenuhnya |
Didukung sepenuhnya |
|
|
API manajemen lanjutan |
Didukung sepenuhnya |
Didukung sepenuhnya |
|
|
Biaya |
Harga penyimpanan (Harga aktual di halaman pembelian berlaku.) |
Mulai dari USD 0,019/GB/bulan |
Mulai dari USD 0,023/GB/bulan |
|
Elastisitas penyimpanan |
Mendukung penskalaan online yang lancar. |
Ambang batas masuk tinggi dan peningkatan penskalaan besar. |
|
|
Pemisahan komputasi dan penyimpanan |
Didukung. Dipisahkan dari mesin komputasi untuk penskalaan independen. |
Tidak didukung. Ditempatkan bersama mesin komputasi. |
|
|
Penyimpanan bertingkat |
Penyimpanan multi-tier dengan tiering data cerdas. |
Tidak didukung |
|
|
Skalabilitas |
Jumlah node |
Tidak berlaku |
0 hingga 1.000 |
|
Kapasitas penyimpanan |
0 hingga 1 EB |
0 hingga 10 PB |
|
|
Jumlah file |
Mendukung ratusan miliar file. |
Puluhan juta |
|
|
Ekosistem |
Ekosistem big data open source seperti Hadoop dan Spark, serta ekosistem data Alibaba Cloud. |
Ekosistem big data open source seperti Hadoop dan Spark. |
|
|
Usabilitas |
LindormDFS bebas O&M dan mudah dipelihara. |
Layanan stateful yang kompleks untuk dipelihara. |
|