Mungkin teman-teman sudah pernah mendengar mengenai SOLID Principle yah. Pada artikel ini kita membahas mengenai Dependency Inversion yang merupakan D dari SOLID. Dependency Inversion ini mengatakan bahwa
“High level modules should not depend on low level modules, both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions. “
High module di sini dapat berupa kelas yang akan mengimplementasikan fitur-fitur yang biasanya merupakan class ViewController. Low module ini sendiri ialah sub-module yang akan akan digunakan oleh High Module, contoh umumnya seperti NetworkService, DataService, UserDefaultService dll.
Dependency Inversion di sini berfungsi agar kode yang kita tulis dapat bersifat lebih flexible dan mudah untuk dimodifikasi atau biasanya disebut dengan “Loose Coupling”
Code Example
Nah ini contoh pattern yang umum sering dijumpai pada project iOS yang ada.
Biasanya kita membuat sebuah class Singleton dan memanggil dalam class ViewController yang ada. Ini merupakan contoh kode yang menyalahi aturan DependencyInversion, karena class ViewController tahu DataSourceServicesecaradetail tanpa melalui Abstraction.
Memang tidak ada yang salah dengan kode ini, karena aplikasi yang ada juga berjalan dengan baik. Namun setiap kali terjadi perubahan, maka kita harus merefactor/mengganti kode-kode yang ada. Atau misalnya beberapa bulan ke depan, datasource yang ada berubah dari Firebase menjadi MonggoDB, BackEndservicedll. Nah di sini principle DependencyInversion memiliki peran yang sangat penting.
Hands On
Di sini class ViewController bergantung pada abstraction seperti DataProviderProtocol. Nah di sini, class ViewController tidak lagi peduli bahwa data yang ada berasal dari mana, yang penting bahwa melalui abstraction ini class ViewController akan mendapatkan data.
Nah pada class SceneDelegate, kita tinggal melakukan dependency injection melalui initialzer terhadap class ViewController ini. Nah contohnya di sini kita menggunakan FirebaseDataProvider.
Seandainya beberapa minggu yang ada, tiba-tiba terjadi migration backend service dari Firebase ke dalam BackEnd company sendiri. Kita tidak perlu lagi mengganti kode yang ada pada class ViewController setiap kali ada perubahan.
Conclusion
Selama sebuah class comform terhadap DataProviderProtocol ini, kita bisa mengganti/melakukan update dengan mudah tanpa merusak kode yang sudah ada. Dengan mengerti aturan dari SOLID ini, kita bisa membuat arsitektur kode yang lebih flexible dan tentunya kode yang ada bersifat testable.
Semoga bisa bermanfaat dan memberikan insight terhadap teman-teman.
Full Project https://github.com/windywu812/DependencyInversionDemo
MVC (Model-View-Controller) adalah salah satu architecture pattern yang menjadi base dari projek baru dari iOS. Saya cukup yakin jika semua iOS developer tentunya tahu dengan pattern ini. Secara umum MVC terdiri 3 komponen yaitu:
Model Komponen atau layer ini berisi data model aplikasi, networking service, data persistence dll. Intinya komponen ini berisi logik yang berhubungan data yang ada pada aplikasi kita.
View Untuk komponen ini sendiri pastinya kita sudah tahu yaitu Storyboard yang berfungsi untuk membuat view dari aplikasi kita.
Controller Komponen ini biasanya kita sebut dengan ViewController, yang berfungsi menjadi jembatan antara model dan view. Di mana controller ini bertugas untuk memanggil data dan mengupdatenya ke dalam view, atau mengirim sebuah respon atau action ketika view seperti button, textfield dll mengalami perubahaan state.
Problem
Untuk architecture ini sendiri menurut saya sangat cocok untuk aplikasi yang masih sederhana, namun kenyataannya implementasi yang ada masih salah. Biasanya dalam project yang ada, kita selalu menempatkan semua logic yang ada dalam ViewController bukan? Biasanya untuk melakukan fetching data, maka kita memanggil Singleton ke dalam ViewController yang ada. Sehingga yang ada bukanlah MVC(Model-View-Controller), melainkan Massive View Controller.
Beberapa masalah yang terjadi:
Menyalahi aturan Single Responsibility Principle di mana ViewController menghandle terlalu banyak operasi, ViewController seharusnya hanya bertugas untuk memanggil dan melakukan update.
ViewController seharusnya tidak mengetahui implementasi detail dari operasi tersebut, dalam kasus ini kita telah menyalahi aturan dari Dependency Inversion Principle, “Module shoud not depend on Detail/Implementation (Concrete Class), it should depend on abstraction”. Dengan menyalahi aturan tersebut, class ViewController menjadi Tighly Couple dengan Singleton yang ada, dan menyebabkan kode yang ada susah untuk ditest.
Nah untuk mengatasi hal tersebut tidaklah susah, kita cukup memanfaatkan Dependency Injection dan mengikuti aturan Dependency Inversion. Ayo kita langsung hands-on aja.
Silahkan membuka branch Main, aplikasi ini ialah aplikasi sederhana yang memuat games dari API dan menampilkannya pada tableview yang ada. Struktur kode tersebut merupakan struktur kode yang sering kita lihat dalam beberapa project. Secara sekilas struktur kode yang ada sudah cukup rapi, namun masih dapat dikembangkan. Dalam kode ini, ViewController masih bergantung pada class NetworkService, sehingga ketika membuat test kita harus menguji implementasi yang asli (memanggil data langsung) yang biasanya memakan waktu cukup lama, padahal sebuah UnitTesting harus berjalan dengan cepat.
1. Mendefine sebuah Protocol
Membuat sebuah protocol, nantinya ViewController akan bergantung pada protocol ini (abstraction), bukan class NetworkService(Concrete Type) secara langsung.
2. Membuat class yang akan mengimplementasi protocol tersebut
Sekarang kode pada fungsi getAllGames pada class ViewController dapat dipindahkan ke dalam class GameImplementation ini.
3. Refactor kode pada class ViewController
Menambah sebuah dependency yaitu GameProtocol(Abstraction) tersebut dan menghandle completion dari fungsi getAllGames
Unit Test
Dengan membuat kode kita menjadi seperti ini, maka kita akan dapat melakukan test dengan mudah dan cepat.
1. Membuat Mock Object
Dengan membuat mock object, kita tidak perlu lagi melakukan test dengan real APICall. Kita dapat membuat data dummy kita sendiri
2. Write Unit Test
Karena ViewController bergantung dengan abstraction, kita dapat dengan mudah untuk mengganti dependency yang ada. Di sini kita tidak lagi menggunakan class GameImplementation, melainkan MockGameImplementation yang berisi data dummy kita.
Kesimpulan
Dengan membuat kode seperti ini, kita dapat membuat class/kode memiliki ruang untuk bernafas yaitu tidak bergantung pada class tertentu (Loose Coupling). Unit Test yang ditulis dapat dijalankan dengan cepat dan secara offline. Jika kita mengetest dengan memanggil API Call secara langsung, maka beberapa masalah yang dapat terjadi ialah:
Masalah Internet yang sangat mempengaruhi kecepatan Unit Testing kita, sehingga hasil yang ada tidak konsisten. Apalagi jika kita berada di jangkauan yang tidak memiliki sinyal internet, maka kita tidak dapat melakuakan test. Test yang ada juga relative cepat yaitu hanya memerlukan waktu sekitar 0.1 detik, jika dibandingkan dengan ApiCall yang asli maka akan membutuhkan waktu beberapa detik.
Kendala terhadap API Call limit pada beberapa API, sehingga akan menghambat proses development yang ada
Untuk melihat hasil akhir, Anda bisa checkout ke dalam branch Final. Semoga dapat memberikan insight baru dan dapat bermanfaat bagi teman-teman.
Halo gaes !! kali ini saya akan berbagi pengalaman ketika menggunakan Cypress dan mocha dalam tools pengujian automation test. Berdasarkan pengalaman pribadi saya saat menggunakan mocha dan cypress yang mana ketika menggunakan mocha jika kita ingin menjalankan semua file testing yang ada di dalam folder satu, maka kita perlu untuk mengubah kode default dan itu akan membutuhkan effort yang bisa berdampak pada pekerjaan. Seperti contoh struktur file dan folder dibawah ini :
SharedPreferences merupakan penyimpanan key-value data sederhana pada Android. SharedPreferences seringkali digunakan untuk menyimpan setting pada aplikasi, sering juga digunakan sebagai session yang menyimpan info login yang memuat token user untuk login padahal sebenarnya menyimpan data penting seperti user token di SharedPreferences merupakan hal yang fatal dan bisa menyebabkan system di bobol oleh hacker karena SharedPreferences bisa diakses dan dibaca oleh user yang memiliki akses root pada devicenya.
PSR atau singkatan dari PHP Standards Recommendations, yang mana artinya adalah rekomendasi-rekomendasi penulisan kode agar setiap programmer memiliki standar penulisan kode, sehingga mudah untuk melakukan kolaborasi atau kerja sama dalam menulis kode PHP, lebih lagi para programmer dapat membuat berbagai library hingga framework dari bahasa pemrograman PHP dengan standarisasi penulisan kode yang sama.
Saat ini performa system merupakan hal yang sangat penting dan perlu diperhatikan bagi para developer. Semakin baik performa suatu system tentu akan membuat pengguna semakin nyaman menggunakannya. Untuk itu developer seperti kita perlu untuk melakukan Benchmark Code.
Apa itu Benchmark?
Benchmark adalah metode/langkah untuk mengukur serangkaian kode yang ada dalam sebuah fungsi. Dengan melakukan benchmark, kita bisa membandingkan kinerja kode mana yang lebih baik sehingga dapat mengoptimalkan system kita.
Untuk melakukan Benchmark Code, kita akan menggunakan tools dari DotNet yaitu BenchmarkDotNet.
Telegram merupakan salah satu aplikasi chatting gratis dan memiliki berbagai fitur. Salah satu fitur yang disediakan yaitu Bot. Telegram Bot adalah aplikasi pihak ketiga yang dapat dikontrol menggunakan HTTPS Request ke API Bot yang telah disediakan telegram. Dokumentasi mengenai API Bot dapat dipelajari pada halaman web core telegram.
Pandemi Covid-19 yang terjadi di Indonesia mulai dari awal tahun 2020 sampai sekarang membuat perubahan mekanisme diberbagai sektor. Beberapa sektor yang berdampak adalah mekanisme pendidikan dan pekerjaan. Pada sektor pendidikan yang biasanya secara offline tatap muka di sekolah (luring) menjadi interaktif berbasis online dengan memanfaatkan berbagai platform (daring) yang dilakukan dari rumah. Seperti halnya pendidikan, pada mekanisme pekerjaan pun sama yaitu yang biasanya tatap muka dan melakukan produktifitas di kantor atau yang biasa disebut WFO untuk semua karyawan menjadi produktifitas dilakukan secara interaktif online dari rumah atau WFH untuk sebagian karyawan maupun semua karyawan tergantung pada masing-masing bidang pekerjaan.
Architecture Pattern adalah bagaimana susunan kode kita pada saat membuat program / aplikasi. contoh dari Architecture Pattern adalah MVC (Model View Controller), MVP (Model View Presenter), dan MVVM (Model View ViewModel). sebagian dari kita mungkin lebih familiar dengan istilah design pattern bahkan salah menganggap kalau MVC, MVP, dan MVVM adalah design pattern. padahal Design Pattern dan Architectural Pattern adalah 2 hal yang berbeda. Design Pattern adalah istilah yang merujuk pada solusi umum yang digunakan untuk memecahkan masalah yang sering terjadi dalam konteks tertentu, contoh dari Design Pattern adalah Factory Pattern, Adapter Pattern, Singleton Pattern, Builder Pattern, dan lain sebagainya. Design Pattern akan saya bahas di artikel yang lain, tetap stay tune di blog ini.
Penggunaan Architecture Pattern cukup penting dan cenderung memudahkan kita dalam proses development, apalagi jika kita berada dalam satu tim development. karena Architecture Pattern membagi tiap koding sesuai dengan fungsinya masing-masing, jadi kita tidak melakukan koding di satu class saja namun dipisah-pisah menjadi beberapa class sesuai dengan fungsinya masing-masing. disini kita akan membahas salah satu dari Architecture Pattern yang paling sering dipakai dalam Android Development, yaitu MVP.
Apache Druid adalah Open Source untuk mendistribusikan data penyimpanan. Core Desain Druid menggabungkan ide-ide dari Data Warehouse Timeseries Database, dan Search System untuk membuat analisa dengan performa terbaik untuk pencarian di database secara realtime khusus kasus tertentu. Apache Druid paling tepat digunakan untuk analisa Big Data.
1.Kapan harus menggunakan Apache Druid
Druid digunakan untuk mendistribusikan sesuai dengan sekenario berikut:
·Pada saat proses Menambah data atau INSERT sangat tinggi, dan UPDATE data rendah.
·Kebanyakan menggunakan query untuk reporting seperti Grouping, tapi juga bias untuk query pencarian.
·Lama ekseskusi query antara 0.1 detik sampai beberapa detik.
·Data memiliki komponen waktu.
·Saat banyak sekali Table, tapi query hanya mengambil dari Table yang memiliki data yng Besar.
·Banyak kolom Cardinal (numeric) yang membutuhkaan perhitungan cepat dan melakukan pemeringkatan.
·Data yang akan di proses dari atau dalam bentuk Apache Kafka, HDFS, flat files dan Object Storage seperti Amazon S3.
2.Kapan tidak harus menggunanakan Apache Druid
Druid tidak bisa digunakan untuk mendistribusikan sesuai dengan sekenario berikut:
·Butuh waktu cepat untuk update Data. Druid mendukung untuk Streaming INSERT tapi tidak mendukung Streaimng UPDATE (bisa melakukan update tapi harus menggunakan batchs job dan memakan resource tentunya).
·Menyediakan reporting historical data dalam bentuk data mentah, tanpa adanya grouping.
·Membuat reporting system secara offline menghiraukan kecepatan proses data.
·Query yang memiliki join antara Big Table, yang mana kamu nyaman dengan query yang memakan waktu yang lama.
3.Integration
Figure 2 Integration
Druid bisaa digunakan beberapa opensource untuk terintegrasi diantaranya Apache Kafka, HDFS, System processor, dan kemudian out put dari integrasi Apache Druid diantaranya SQL Queries, Custom Aplications dan Monitoring & BI Tools.
4.Ingestion
Figure 3 Ingestion
Druid mengolah data dalam bentuk Row Data hasil dari Event Streaming dan Barch File yang kemudian diolah sesuai dengan Spec dan akan menghasil kan druid segment yang bisa dugunakan. Bisa dilihat di dokumentasi: Link
5.Storage
Figure 4 Storage Druid
Seperti Data Store lainnya, Druid memiliki Colomn, data type (String, Num dll) dan tentunya druid menyediakan data partition berdasarkan waktu ingestion dari segment. Optimized Filter atau Query bisa di lakukan pada saat Proses Ingestion / Input Row Data. bisa dilihat dokumentasi: Link
6.Querying
Figure 5 Querying
Querying dalam Druid bisa menggunakan JSON dan SQL, untuk SQL sepenuhnya querying akan sama dengan SQL seperti JOIN, GROUPING dll dalam bentuk aggregation. Silakan lihat dokumentasi: Link
Druid memiliki Architecture seperti Figure 6, berikut runtutan penjelasannya:
·Raw Data (Stream Data/Batch Data) : Dalam bentuk Event Streaming atau dalam bentuk file (JSON, csv, txt dll).
·Data Node: Dalam data node terjadi Ingestion dengan indexer dan olah data untuk menjadi history Segment.
·Deep Storage: Dalam Deep Storage adalah data yang sudah di Ingestion akan tersimpan dalam Storage Druid dan data siap digunakan .
·Query Node: dalam query node ini adalah proses untuk mengambil data dan proses akhir analisa yang dibutuhkan.
B.Penggunaan Apache Druid
Dalam penggunaan Apache Druid yang saya praktik kan hanya menggunakan Load data Batch File dalam bentuk CSV. Druid bisa realtime hanya bisa menggunakan Event Streamer yaitu Apache Kafka,Kinesis, HDFS, Amazon S3. Dalam riset ini saya menggunakan Raw Data Batch File
Kenapa tidak Riset menggunakan Apache Kafka:
·Setelah berdiskusi apabila harus install apache Kafka harus menambah RAM kurang lebih 8 GB.
·Harus riset tapa itu Apache Kafka.
·Apabila kebutuhan untuk optimization Time Load bisa menggunaakan Chace seperti Redis.
Methode Raw Data Batch File tidak akan bisa mendapatkan Data Realtime dan data terupdate, dikarenakan saya upload melalui overlord secara manual walaupun bisa kita buat sebuahh strategi update batch file disimpan dalam storage kemudian kita buat Task Spec Granularity update setiap beberapa menit akan mengabil data secara terus menerus.
Akhirnya kami memutuskan untuk Riset menggunakan Batch File Load data dari storage. Dikarenakan Percobaan Batch File 4 Juta data gagal maka saya punya ide untuk partial dibagi per 200 Ribu. Dalam percobaan Load data dengan 4 Juta data saya mengalami permasalahan yaitu Pada saat Ingestion dimana Status akan selalu ‘WAITING’ dan apabila saya kill Task Ingestion maka akan hilang namun pada saat Load data lagi maka akan GAGAL seperti Figure 7. Akhirnya Harus install Ulang Apache Druid dan saya mencoba method maksimal Load data 200 Ribu dan setting Append sehingga data bisa menambah.
Figure 7 Cannot Kill Task Ingestion
1.Load Data
Proses Load data ini bertujuan untuk menentukan proses Raw data yang akan diinputkan menggunakan method apa dan pengatusan Spec. Berikut Proses Load Data.
·Pilih Menu Load Data yang berada paling kiri Atas, dapat dilihat di Figure 8.
Figure 8 Menu Utama Druid
·Start: Pilih Menu Local Disk kemudian pilih Connect.
Figure 9 Menu Load untuk Start
·Connect: Masukan informasi Source Type, Base Directory dan nama file csv. Kemudian klik Applyy dan kemudian file akan terload di Raw Data.
Figure 10 Content Connect
·Parse Data: Parsing data sebelum diolah di Parse Time, Parsing jenis data Raw Data yaitu Input Format (jenis format yang diinputkan),Find Colomn Fron Header (semacam filter dalam field apabila false akan ada permintaan nama colomn yang dihindari untuk di cari).
Figure 11 Content Parse Data
·Parse Time: Druid akan selalu berbasi skan waktu untuk mengolah data, sehingga dafult aka nada file bernama ( _time ) yang mengambil dari salah satu filed asli disini mengambil dari created_at . Dalam Parse Time kita bisa mengatur Timestamp bisa From Colomn ( dari colomn) atau bisa diisi sendiri (Constant Value).
Figure 12 Content Parse Time
·Transform: Dalam Transform Colomn lebih semacar Grouping dll dan bisa juga untuk alter field/Colomn.
Figure 13 Transform
·Filter: Dalam Filter bisa memilih Add Colomn Filter dan Add global Filter seperti di Figure 14. Dalam Add Colomn Filter (Figure 15) ada Type filter, Dimension dan Value ini sama dengan di SQL type seperti SELECT Dimension seperti nama field dan value. Untuk Add Global Filter (Figure 16) bisa set Intervals dan Filter dalam Bentuk HJSON.
·Configure Schema: dalam Configure Schema ini ada untuk membuat liast Aggregation sesuai dengan type data.Terdapat Add Dimension bisa untuk menambah Field dan Add Metric untuk menambah Schema perhitungan di Filed Baru. Dan Set Granularity yaitu Setting Query akan diupdate setiap Waktu tertentu atau juga bisa tidak diatur.
Figure 17 Configure Schema
·Partition: Dalam Partition ada beberapa Fitur namun fitur utama nya adalah Partition By Time dan Secondary Partition, kebetulan disini saya setting Type Uniform dan segment granularity By HOUR selebihnya default dari Druid Learn More.
Figure 18 Partition
·Tune: Disini untuk mengatur properties dari Ingestion data untuk men setting kecepatan memory task dll. Learn More
Figure 19 Tune
·Publish: dalam publish terdapat configurasi Datasource Name atau istilahnya dalah SQL Table Name, dn kemudian bisa di Append data apabila terjadi Task berulang maka data akan menambah dan tidak di rebase. Parse Error untuk menyimpan setiap Log Error pada saat menjalankan Task.
Figure 20 Publish
·Edit Spec: Spec adalah ringkasa dari semua Configurasi muli dari Start sampai Publish yng di simpan dalam bentuk JSON. Apabilasudah mkaa siap Untuk Di submit dan masuk ke Task Ingestion.
Figure 21 Edit Spec
2.Ingestion
Menu Ingestion ada 2 Fitur yaitu Untuk Supervisor dan Tasks yang mana untuk memperlihatkan proses Ingestion yang terjadi di Overlord Learn More. Beberapa Status dalam Task Ingestion:
·RUNNING : menunjukan proses Task ingestion dalam proses (Figure 22)
·PENDING: Menunjukan harus menunggu Task yang running menjadi tidak success.
·FAILED: Apabila Task memiliki Spec yang tidak valid seperti Raw Data yg sebenaarnya tidak ada.
·WAITING: Waiting terjadi pada saat menunggu proses Deep Storage dari system belum selesai.
·SUCCESS: Sukses adalah proses yang menunjukan Task sudah selesai dan Data source, service, Segment dan Query sudah terbuat dan bisa digunakan.
Figure 22 Task Ingestion Status RunningFigure 23 Ingestion Task status SuccessFigure 24 Task menunjukan beberapa Status
3.Data Source
Dalam data source akan terlihat list nya dan mana yg aktif atau pun tidak dan beberapa field yang menunjukan informasi Datasource.
Figure 25 Datasource
4.Segments
Dalam segment terdapat informasi hasil ingestion yang dibuat dalam bentuk segment.
Figure 26 Segements
5.Services
Service menunjukan informasi service PoRT yang berjalan dan Informasi Max Sice Usage daan Detail.
Figure 27 Services
6.Query
Querying dalam Apache Druid bisa dibuat dalam bentuk Model MYSQL juga bisa dalam Bentuk JSON. Ada beberapa property yang bisa dugunakan didalam druid bisa dipelajari disini Learn More
Figure 28 QuerB
C. Queries Library
Depedensi Library yang bisa digunakan untuk Fetch atu olah Query Apache Druid terdaapat hampir disemua Platform dan Bahasa Pemrograman silahkan kunjungi Learn More.
Figure 29 Query Libraries
A.Benchmark Performance
Dalam Benchmark ini saya membandingkan Performa dengan Druid dengan MYSQL dan Query Service HTTP (API Druid) Dengan MYSQL. Dengan menggunakan schema Querying di Druid dan di MYSQL. Sebelumnya ada beberapa langkah dalam ingestion yang saya buat default saya sesuaikan agar bisa Load Data sebanyak 4 Juta data. Berikut List Datasource yang bisa kita gunakan Figure 30.
Figure 30 Datasource Siap untuk Querying
Mengesampingkan spesifikasi Server disini saya akan mencoba membandikan Druid Query dengan MYSQL Query dan Service HTTP (API Druid) dengan MYSQL Query untuk mendapatkan performa secara latency time. Disini kita menggunakan Query yang sama dengan jumlah data yang sama sebagai Acuan.
Proses Cara Perbandingan:
·Druid Query
Figure 31 Query menggunakan Overlord Druid
Dalam Console Druid saya akan membuat Query dan kemudian saya menghilangkan Smart Query Limit untuk menghilangkan fitur limit sehingga akan diload semua sesuai dengan Query yang sama.
·MYSQL Query
Dalam MYSQL Query saya menggunakan HEIDISQL.
·Service Druid (API Druid).
Figure 31 Query menggunakan Overlord Druid
Dalam Service ini saya menggunakan POSTMAN sebagai Tools untuk Client Service HTTP.
Saya harus setting sebagai berikut
i.Authorization: menggunakan Basic Auth
ii.Header : KEY: Content-Type Value : application/json
iii.End Point: https://linkendpoint/druid/v2/sql
iv.Request rody: raw JSON
Berikut hasil dari perbandingan performa :
·Druid Query VS MYSQL Query
·Service HTTP (API Druid) dengan MYSQL Query
Dari perbandingan Druid dengan MYSQL berdasarkan lama latency load data terdapat beberapa hasil sebagai berikut:
1.Untuk Pencarian dengan sepesifik field dan filter Druid bisa lebih cepat 2 kali lipat bahkan lebih Query Biasa melalui MYSQL.
2.Untuk Pencarian Flat Table Serrch All Content pakai OR Query maka MYSQL Query bisa lebih cepat hampir 2 kali lipat.
3.Untuk mengambil data Flat table dan multi join sebanyak 4 Juta Data terjadi Error.
4.Untuk Service HTTP API Druid akan mengalami Error response size apabila memasuki data berjuta, selama masih belum masuk berjuta masih Aman.
E.Kesimpulan
Apache Druid adalah Open Source untuk mendistribusikan data penyimpanan. Core Desain Druid menggabungkan ide-ide dari Data Warehouse Timeseries Database, dan Search System untuk membuat analisa dengan performa terbaik untuk pencarian di database secara realtime khusus kasus tertentu. Apache Druid paling tepat digunakan untuk analisa Big Data.
Druid memiliki Architecture seperti Figure 6, berikut runtutan penjelasannya:
·Raw Data (Stream Data/Batch Data) : Dalam bentuk Event Streaming atau dalam bentuk file (JSON, csv, txt dll).
·Data Node: Dalam data node terjadi Ingestion dengan indexer dan olah data untuk menjadi history Segment.
·Deep Storage: Dalam Deep Storage adalah data yang sudah di Ingestion akan tersimpan dalam Storage Druid dan data siap digunakan .
·Query Node: dalam query node ini adalah proses untuk mengambil data dan proses akhir analisa yang dibutuhkan.
Dalam Riset ini saya menggunakan Raw Data Batch File sehingga proses input data masih manual karena beberapa alasan. Apabila ingin di otomatisasi bisa buat sebuah cronjob untuk create batch file yg akan diload oleh Druid secara berkala namun memerlukan waktu dan effort. Selain itu juga bisa menggunakan Event Streamer Seperti Apache Kafka dimana data akan selalu Realtime dengan granulity dibuat lebih pendek seperti per minute.
Druid memiliki kemampuan untuk filtering untuk setiap dimensi atau field pada saat ingestion sehingga apabila menggunakan event streamer walau pun dengan data 500GB tetap akan bisa diambil dengan cepat dengaan filtering berdasarkan interval segment yang dibuat.
Dari Hasil Benchmark menunjukan Druid memiliki kemampuan latency time dari segi Query filtering yang baik bahkan lebih baik 2 kali lipat Query MYSQL, namun saya menemukan bahwa Druid akan lama pada saat melakukan filter untuk semua field dengan filter ‘OR’ lebih lama dibandingkan MYSQL. Untuk Service HTTP API Druid hanya mengalami Response size Error namun untuk query dengan jumlah data dibawah 1 Juta masih bisa dieksekusi dengan cepat.
Smartphone diciptakan untuk mempermudah kehidupan manusia, termasuk yang memiliki keterbatasan fisik. OS Android juga diciptakan untuk mereka yang memiliki keterbatasan fisik, maka dari itu Android menyediakan fitur Accessibility secara default pada menu Pengaturan untuk membantu mereka dalam menjalankan Smartphone. fitur Accessibility tidak akan berjalan optimal jika Developer sembarangan dalam membuat aplikasi. terdapat beberapa guide agar fitur Accessibility dapat berjalan optimal dan bisa mempermudah pengguna disabilitas dalam menggunakan aplikasi kita.
