Elasticsearch Dasar
Elasticsearch Dasar
● Elasticsearch adalah database management system yang berbasis RESTful API untuk kebutuhan
pencarian data (search engine)
● Elasticsearch adalah salah satu database untuk pencarian yang paling populer dan banyak
digunakan di perusahaan-perusahaan besar
● Elasticsearch adalah aplikasi free dan open source, sehingga bisa digunakan secara bebas
● Kita bisa berkontribusi ke project Elasticsearch di Github https://github.com/elastic/elasticsearch
● Untuk download aplikasi Elasticsearch, kita bisa download di web resmi perusahaan Elastic
https://www.elastic.co/elasticsearch/
db-engines.com/en/ranking/search+engine
Apache Lucene
● Inti dari system Elasticsearch adalah sebuah library untuk Information Retrieval bernama Apache
Lucene
● Apache Lucene adalah library untuk information retrieval yang sangat populer, dan dibuat
menggunakan bahasa pemrograman Java
● Semua fitur di Elasticsearch, sebenarnya menggunakan Apache Lucene untuk mengelolanya
● https://lucene.apache.org/
Istilah Relational DB vs Elasticsearch
Relational DB Elasticsearch
Database
Table Index
SQL JSON
Menginstall Elasticsearch
Download Elasticsearch
● Secara default, di dalam Elasticsearch terdapat fitur bernama X-Pack, fitur ini adalah fitur yang
tidak open source dan dibuat oleh perusahaan Elastic
● Oleh karena itu, di kelas ini kita akan menonaktifkan terlebih dahulu fitur X-Pack, karena itu adalah
plugin tambahan
● Semua konfigurasi di Elasticsearch terdapat di file config/elasticsearch.yml
● Elasticsearch menggunakan format YAML sebagai konfigurasinya
● https://yaml.org/
Menjalankan Elasticsearch
● Postman : https://www.postman.com/
● Insomnia : https://insomnia.rest/
● JetBrains HTTP Client :
https://www.jetbrains.com/help/idea/http-client-in-product-code-editor.html
● Visual Studio Code REST Client :
https://marketplace.visualstudio.com/items?itemName=humao.rest-client
● curl : https://curl.se/
Data Model
Kenapa Perlu Mengerti Data Modeling
● Pindah dari relational database ke Elasticsearch bukanlah hal yang sesederhana hanya dengan
memindahkan semua table ke index
● Penggunaan Elasticsearch tidak akan mendatangkan manfaat besar jika kita tidak mengerti cara
memodelkan data untuk kebutuhan aplikasi kita
● Saat memodelkan data menggunakan relational database, biasanya kita mengacu ke database
normalization
● Saat memodelkan data menggunakan Elasticsearch, kita harus mengacu ke penggunaan aplikasi
dalam melakukan pencarian data
Schema yang Flexible
● Tidak seperti di relational database, di Elasticsearch kita bisa memasukkan data ke index secara
langsung tanpa mendefinisikan schema index nya.
● Schema untuk index di Elasticsearch sangat flexible, namun setelah schema terbentuk, kita tidak
bisa mengubah atribut yang sudah jadi, hanya boleh menambah atribut
● Artinya jika di awal kita membuat atribut A dengan tipe number, kita tidak bisa menambahkan data
baru dengan nilai atribut A bernilai text / string
● Jadi berbeda dengan database MongoDB, yang tidak ada ketentuan nilai atribut di setiap dokumen
nya
Primary Key
● Saat membuat dokumen di Elasticsearch, kita wajib menambahkan primary key atau id
● Tidak seperti relational database yang bebas membuat column untuk primary key, di MongoDB,
primary key wajib menggunakan field _id
● Selain itu primary key tidak bisa lebih dari 1 field, dan tipe _id adalah string, jadi kita bebas
memasukan angka, tanggal, dan lain-lain, namun tetap akan disimpan dalam bentuk string
Data Model
● Saat kita membuat schema index di Elasticsearch, terdapat dua sudut pandang pembuatan schema
● Embedded Document, dan
● Reference Document
Embedded vs Reference
● Antar document saling ketergantungan ● Antar document bisa berdiri sendiri dan
● Embedded document selalu dibutuhkan tidak terlalu ketergantungan satu sama lain
ketika mengambil data document utama ● Bisa melakukan manipulasi data langsung
terhadap reference document
● Reference document tidak selalu
dibutuhkan saat mengambil document
Tipe Data
Tipe Data Dasar
keyword text terstruktur, misal id, email, hostname, zipcode, dan sejenisnya
text text
● Geopoint
● Geoshape
● Point
● Shape
● Rank
● Token
● Completion
Tipe Data Embedded
Tipe Data Embedded
● Saat kita membuat document di Elasticsearch, kita menggunakan format data JSON
● Sedangkan, kita tahu bahwa di JSON, terdapat struktur embedded baik itu dalam bentuk Object,
atau Array
● Lantas pertanyaannya, bagaimana menentukan tipe data tersebut? Dan bagaimana Elasticsearch
menangani atribut embedded
Apache Lucene Document
● Seperti yang dijelaskan di awal, bahwa di Elasticsearch, tidak ada konsep seperti database, jadi kita
bisa langsung membuat index (atau tabel)
● Lantas bagaimana jika kita menggunakan Elasticsearch untuk lebih dari satu aplikasi? Salah satu
praktek yang biasa dilakukan adalah, membuat nama index dengan nama depan aplikasinya,
misalnya: namaaplikasi_namaindex
● Dengan begitu nama index tidak akan bentrok antar aplikasi
Membuat Index
● Untuk menghapus Index yang sudah kita buat, maka sangat mudah, kita bisa menggunakan HTTP
Method DELETE
● Menghapus Index secara otomatis akan menghapus seluruh data di Index tersebut
Dynamic Mapping
Dynamic Mapping
● Saat kita membuat tabel di relational database, kita akan membuat struktur tabel nya terlebih
dahulu
● Di Elasticsearch, pembuatan schema index dinamakan mapping, dan secara default, kita tidak perlu
membuat mapping secara manual
● Elasticsearch memiliki fitur bernama Dynamic Mapping, dimana Elasticsearch bisa mendeteksi tipe
data dari tiap atribut JSON yang kita gunakan, dan secara otomatis membuat mapping
menggunakan tipe data yang sesuai
● Walaupun fitur ini sangat bagus, tapi tetap sebenarnya direkomendasikan untuk membuat
mapping secara manual atau eksplisit
● Materi membuat mapping secara manual akan kita bahas di materi sendiri
Dynamic Field Mapping
double float
long long
● Secara default, Elasticsearch ketika menerima tipe data string, dan belum memiliki mapping untuk
atribut tersebut, dia akan mendeteksi apakah data string tersebut menggunakan format date atau
tidak
● Jika menggunakan format date, maka secara otomatis tipe data akan menggunakan date
● Elasticsearch secara default menggunakan format date : yyyy/MM/dd HH:mm:ss
● Secara default deteksi date aktif ketika kita membuat index, jika tidak ingin aktif, kita harus ubah
mapping attribute date_detection menjadi false
● Dan jika kita ingin mengubah format date, kita harus menggubah mapping attribute
dynamic_date_formats
Deteksi Number
● Walaupun sebenarnya JSON memiliki tipe data number, namun kadang-kadang ada beberapa
pengguna mengirim number dalam format string, misal “100”, atau “12.12”
● Secara default, deteksi number secara otomatis tidak aktif, jika ingin aktif, kita harus mengubah
nilai mapping numeric_detection menjadi true
● Jika mapping untuk atribut tersebut belum tersedia, maka secara otomatis Elasticsearch akan
mencoba mengkonversi ke tipe data number (long atau float), jika bisa maka Elasticsearch akan
menggunakan tipe data number
Create API
Create API
● Setelah kita menyimpan data ke Elasticsearch menggunakan Create API, kita bisa mengambil data
yang sudah kita masukkan menggunakan Get API
● Get API akan mengembalikan data dan informasi metadata-nya, seperti _id, nama index, versi
dokumen, dan lain-lain
● Jika ternyata data yang kita ambil tidak tersedia, maka HTTP Response Code nya akan
mengembalikan 404 Not Found
● Untuk menggunakan Get API, kita bisa menggunakan RESTful API :
GET /<index_name>/_doc/<id>
Get Source API
● Jika kita tidak mau mendapat metadata informasi dari dokumen yang kita ambil, kita bisa
menggunakan Get Source API :
GET /<index_name>/_source/<id>
● Secara otomatis akan mengembalikan seluruh data yang kita insert, tanpa informasi metadata nya,
termasuk tanpa _id, karena _id sudah ada di URL dimana kita melakukan HTTP Call
Check Exists
● Pada beberapa kasus, kadang kita hanya ingin mengecek apakah dokumen ada di Index atau tidak.
Sehingga kita tidak butuh isi data dari dokumen nya
● Pada kasus seperti ini, kita bisa menggunakan Get API, namun menggunakan HTTP Method HEAD
● Elasticsearch akan mengembalikan response 200 empty jika sukses, dan 404 Not Found jika data
tidak ada
Multi Get API
Multi Get API
● Elasticsearch juga menyediakan Multi Get API, yaitu API untuk mendapatkan beberapa dokumen
secara sekaligus
● Kita bisa menggunakan RESTful API :
POST /_mget
POST /<index_name>/_mget
● API ini bisa digunakan untuk mendapatkan dokumen dari beberapa index, sehingga cocok misal
ketika butuh mengambil dokumen ke beberapa index sekaligus, sehingga lebih mudah karena bisa
hanya melakukan sekali API Call saja
Search API
Search API
● Get API digunakan untuk mendapatkan satu dokumen, bagaimana jika kita ingin mencari dokumen,
tidak menggunakan _id? Maka kita bisa menggunakan Search API
● Search API sangat kompleks, sehingga akan dibahas dalam beberapa tahapan, di materi ini kita
akan bahas yang sederhana dulu
● Untuk menggunakan Search API, kita bisa menggunakan RESTful API :
POST /_search
POST /<nama_index>/_search
Pagination
● Search API juga bisa digunakan untuk mengurutkan hasil response, dengan menggunakan query
parameter sort, dengan nilai :
<field>:<direction>
● Dimana direction bisa asc atau desc
● Jika kita butuh mengurutkan dengan lebih dari satu field, kita bisa menggunakan pemisah koma,
misal :
field1:asc,field2:desc,field3:asc
Index API
Index API
● Di Elasticsearch versi baru, untuk membuat dokumen, kita bisa menggunakan Create API
● Namun, dahulu, membuat dokumen di Elasticsearch biasanya menggunakan Index API
● Index API merupakan API yang sifatnya create or replace, yang artinya data tidak ada, maka akan
di create, namun jika data sudah ada, maka akan di replace (dihapus dan dibuat baru)
● Pada Create API, jika dokumen sudah ada, maka akan terjadi error conflict, namun di Index API, hal
itu tidak akan terjadi
● Kita bisa menggunakan RESTful API :
POST/PUT /<index_name>/_doc/<id>
Pilih Create API atau Index API?
● Saat ini, kebanyakan programmer menggunakan Index API untuk menyimpan dokumen ke
Elasticsearch
● Hal ini karena Index API akan aman dari conflict ketika ternyata dokumen sudah tersedia di
Elasticsearch
● Namun jika memang kita tidak mau melakukan replace, maka kita harus menggunakan Create API,
namun disarankan untuk menggunakan Get API untuk mengecek apakah dokumen sudah ada atau
belum di Elasticsearch
Update API
Update API
● Ketika melakukan update menggunakan Index API, Index API akan melakukan replace, artinya
dokumen sebelumnya akan dihapus dan dibuat baru, hal ini mengakibatkan kita harus mengirim
seluruh atributnya lagi, karena jika kita hanya mengirim atribut yang di-update, secara otomatis
akan ditimpa, artinya data di atribut lain bisa hilang
● Jika kita ingin mengupdate beberapa atribut saja di dokumen, tanpa harus mengirim ulang seluruh
atribut, kita bisa menggunakan Update API dengan RESTful API :
POST /<index_name>/_update/<id>
● Jika dokumen yang di update tidak tersedia, maka Elasticsearch akan mengembalikan 404 Not
Found
Delete API
Delete API
● Untuk menghapus dokumen yang sudah kita buat, kita bisa menggunakan Delete API
● Untuk menggunakan Delete API, kita bisa menggunakan RESTful API :
DELETE /<index_name>/_doc/<id>
● Jika dokumen yang dihapus tidak ditemukan, Elasticsearch akan mengembalikan response 404 Not
Found
Bulk API
Bulk API
● Saat melakukan operasi yang sangat banyak ke Elasticsearch, ada baiknya kita menggunakan Bulk
API untuk mempercepat proses, dibandingkan dilakukan satu per satu secara manual
● Elasticsearch menyediakan Bulk API yang bisa digunakan menggabungkan banyak operasi
sekaligus, create, index, update atau delete
● Untuk menggunakan Bulk API, kita bisa menggunakan RESTful API :
POST /_bulk
POST /<index_name>/_bulk
Format Request Body untuk Bulk API
action_and_meta_data\n
optional_source\n
action_and_meta_data\n
optional_source\n
....
action_and_meta_data\n
optional_source\n
Alias
Kenapa Butuh Alias?
● Di Elasticsearch, terdapat fitur Alias (nama samaran) untuk Index yang sudah dibuat
● Fitur Alias itu sangat berguna ketika kita tidak ingin membebankan Client untuk selalu mengubah
nama Index ketika kita mengubah Index
● Memang kenapa nama Index harus diubah?
Index Management
● Elasticsearch tidak seperti database lain, kita kita sudah terlanjut membuat atribut / field, maka
kita tidak bisa menghapus atau mengubah atribut yang sudah terlanjur dibuat
● Oleh karena itu, sering sekali di Elasticsearch kita akan membuat index baru ketika terjadi
perubahan schema
● Karena index baru harus dibuat, maka akan menyulitkan client ketika melakukan request, karena
harus mengubah nama index dengan nama yang baru
● Pada kasus seperti inilah, alias sangat cocok digunakan agar client tidak harus melakukan
perubahan ketika terjadi perubahan nama index
Alias
● Untuk mengakses Alias, itu sama saja seperti mengakses Index. Jadi Elasticsearch akan mencari
Alias terlebih dahulu, jika tidak ada, maka akan langsung mencari Index
● Untuk membuat Alias, kita bisa menggunakan API :
POST /_aliases
● Untuk menambah alias, kita bisa menggunakan action add, dan untuk menghapus alias kita bisa
menggunakan action remove
Reindex API
Reindex API
● Seperti yang dijelaskan di materi Alias, di Elasticsearch kita akan terbiasa membuat index baru
ketika terjadi perubahan schema, sehingga membutuhkan Alias
● Tapi pertanyaannya, bagaimana dengan data yang ada di Index lama?
● Kita bisa insert secara manual, atau kita bisa lakukan proses reindex, yaitu memindahkan data dari
index ke index lain, menggunakan Reindex API :
POST /_reindex
Source
Source Field
● Seperti kita tahu, bahwa Elasticsearch menyimpan data dalam bentuk Apache Lucene Document
Key-Value
● Lantas bagaimana bisa Elasticsearch mengembalikan dalam bentuk response JSON utuh? Hal ini
karena Elasticsearch menyimpan data dokumen JSON utuh dalam key _source di Lucene
Document
● Oleh karena itu jangan kaget jika ukuran data bisa dua kali lipat besarnya, karena memang selain
semua atribut disimpan di Lucene Document, terdapat satu atribut _source yang berisi seluruh
data JSON untuk nanti dikembalikan di response
Select Field
● Secara default, seluruh response di Elasticsearch akan mengembalikan seluruh JSON utuh dari
atribut _source
● Namun, Elasticsearch memiliki fitur untuk kita melakukan include atau exclude sehingga kita bisa
memilih atribut mana yang perlu dikembalikan dalam response ketika kita menggunakan Get API
dan Search API
● Query parameter _source_includes, berisi field-field yang mau di include dalam response, dipisah
menggunakan koma
● Query parameter _source_excludes, berisi field-field yang mau di exclude dalam response, dipisah
menggunakan koma
Mapping
Mapping
● Pada materi sebelumnya kita sudah bahas tentang Dynamic Mapping, sekarang kita bahas tentang
pembuatan Mapping secara manual
● Pada kenyataannya, penggunaan Dynamic Mapping biasanya jarang kita lakukan, karena biasanya
ketika membuat Index, kita ingin menentukan schema sesuai dengan yang kita inginkan
● Oleh karena itu, kita harus mampu dan mengerti cara membuat Mapping secara manual
Properties
● Saat mengubah Mapping pada Index, kita bisa tambahkan properties, yang berisi informasi atribut
dan tipe data atribut tersebut
● Dengan begitu, secara otomatis ketika kita memasukkan dokumen ke Index, secara otomatis akan
menggunakan tipe data yang sudah kita tentukan
Data Customer
● Silahkan masukkan data customer secara bulk yang terdapat di dalam file dibawah ini
● https://gist.github.com/khannedy/0b7c678a98b22f5ecd8e958b260c4a37
Object Field
Object Field
● Bagaimana jika kita butuh membuat atribut dengan tipe data Object? Yang artinya kita butuh
membuat nested atribut?
● Pada kasus seperti itu, kita bisa menggunakan type properties, lalu membuat nested attribute
seperti Mapping biasanya
● Misal, kita coba tambahkan atribut address pada data customer yang sebelumnya kita buat
Data Customer dengan Address
● Silahkan masukkan data customer yang berisi data address secara bulk yang terdapat di dalam file
dibawah ini
● https://gist.github.com/khannedy/28c6dfb8eb81e0569a40ff4240becda8
Array Field
Array Field
● Seperti yang dijelaskan di awal, bahwa Lucene Document menggunakan key-value, dan untuk value
di Lucene Document, dia bisa menyimpan lebih dari satu nilai
● Jadi jika kita memiliki atribut Array, maka kita cukup membuat atribut dengan tipe data yang sesuai
dengan isi Array nya
Array of Object
● Bagaimana jika ternyata tipe data atribut tersebut adalah Array of Object?
● Karena memang Lucene Document tidak mendukungnya, secara otomatis sebenarnya
Elasticsearch akan mengubah data Array of Object, menjadi key-value biasa
● Dengan begitu, kita cukup membuat atribut dengan mapping tipe data object
Data Customer dengan Hobbies dan Banks
● Silahkan masukkan data customer yang berisi data address secara bulk yang terdapat di dalam file
dibawah ini
● https://gist.github.com/khannedy/30efb2f16019d5f9a4da6baa6da19626
Query
Query
● Sebelumnya kita sudah membahas tentang Search API untuk melakukan pencarian data di Index
● Sekarang kita bahas tentang Query yang bisa kita kirim menggunakan Search API
Match All
● Secara default, saat kita menggunakan Search API tanpa request Query, maka dia akan
menggunakan Query Match All
● Query Match All digunakan untuk mengambil seluruh data di index
Paging dan Sorting
● Pada materi Search API, kita melakukan paging dan sorting menggunakan Query Parameter
● Sebenarnya untuk melakukan Paging dan Sorting juga bisa kita gunakan Request Body, ini lebih
mudah dibandingkan menggunakan Query Parameter, dan lebih mudah dibaca juga
Term Query
Term Query
● Term Query adalah jenis query untuk mencari exact value, misal username, product id, harga, dan
lain-lain
● Term Query tidak begitu cocok jika digunakan untuk mencari di atribut dengan tipe data text, hal
ini dikarenakan tipe data text memiliki text analisis yang bisa menyebabkan datanya jadi tidak
sesuai dari yang awal, misal menjadikan lowercase otomatis, menghapus simbol otomatis, dan
lain-lain
● Sehingga tidak cocok jika menggunakan Term Query untuk tipe data text, lebih cocok
menggunakan Match Query
Match Query
Match Query
● Match Query sebenarnya sama dengan Term Query, yang membedakan adalah, Match Query akan
menggunakan Text Analysis yang sama dengan atribut yang dicari
● Maka dari itu, menggunakan tipe data Text, cocok menggunakan Match Query, karena secara
otomatis akan menggunakan Text Analysis yang sama
● Materi Text Analysis akan kita bahas di materi terpisah, karena materi ini lumayan kompleks
● Karena Match Query akan menggunakan Text Analysis, oleh karena itu, cocok digunakan untuk
data Text, tapi tetap Match Query juga bisa digunakan untuk semua tipe data
Standard Analyzer
● Tipe data Text, secara default akan menggunakan StandardAnalyser, sederhananya, ini adalah
object yang digunakan untuk mengubah value asli, menjadi value yang bisa dicari dalam bentuk
token-token yang lebih kecil
● https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/analysis/standard/StandardAnalyz
er.html
● Contoh, saat kita menggunakan value text [email protected], maka StandardAnalyzer akan
mengubah menjadi eko example com, hal ini secara otomatis kita bisa mencari menggunakan kata
eko, example atau com
● Untuk lebih detail, nanti akan dibahas di materi Text Analysis
Match Query Operator
● Saat kita menggunakan Match Query, terdapat atribut bernama operator, yang bernilai OR atau
AND, defaultnya adalah OR
● Maka dari itu ketika kita mencari “bca digital”, maka StandardAnalyzer akan memecah menjadi
“bca” OR “digital”, maka dari itu semua bank BCA atau bank BCA Digital akan keluar dari hasil
pencarian
● Jika kita ingin menggunakan “bca” AND “digital”, maka kita harus mengubah query operator nya
menjadi AND
Terms Query
Terms Query
filter Query harus muncul di dokumen hasil, dan namun tidak berkontribusi
ke score
● Saat kita menggunakan Boolean Query, dan hanya menggunakan should, tanpa must dan filter,
secara default minimal hanya 1 kondisi di dalam should yang harus sesuai dengan dokumen
● Namun ketika kita menambahkan must atau filter, maka nilai minimum should match nya jadi 0,
yang artinya should nya tidak wajib
● Jika kita ingin mengubahnya, kita harus menambah nilai untuk minimum should match
Score
Score
● Secara default, saat kita melakukan Query ke Elasticsearch, hasil dari Query akan diurutkan
berdasarkan Score
● Score adalah hasil relevansi untuk Query pencarian yang kita kirim, semakin besar nilai Score,
artinya menurut Elasticsearch, dokumen tersebut semakin relevan dengan request Query nya
● Secara default, Elasticsearch menggunakan algoritma BM25 untuk menghitung score dari tiap
dokumen
● https://www.elastic.co/blog/practical-bm25-part-2-the-bm25-algorithm-and-its-variables
TF-IDF
● Sebelum menggunakan BM25, Elasticsearch atau lebih tepatnya Apache Lucene, menggunakan
TF-IDF untuk menghitung Score, namun hal ini sering disalahgunakan oleh user karena algoritma
TF-IDF mudah dimodifikasi dengan data
● Salah satunya, semakin banyak value yang dicari di dokumen, maka semakin relevan, contoh di
Toko Online, banyak orang yang sering memasukkan kata-kata brand di deskripsi berkali-kali, agar
hasil pencariannya mendapat Score tinggi.
● Namun dengan BM25, hal itu sudah tidak bisa dilakukan lagi
● https://opensourceconnections.com/blog/2015/10/16/bm25-the-next-generation-of-lucene-rele
vation/
Explain API
● Jika kita ingin melihat bagaimana sebuah score dihitung pada dokumen, kita bisa menggunakan
Query yang kita gunakan di Explain API
● Kita bisa mengirim Query yang kita lakukan, ke API :
POST /<index_name>/_explain/<_id>
Boost Score
Boost Score
● Secara default, bobot tiap Query dalam menentukan nilai score (boost) adalah sama, yaitu 1
● Jika kita ingin meningkatkan bobot nilai score pada salah satu query, kita bisa naikkan nilainya
● Jika kita ingin menurunkan bobot nilai score pada salah satu query, kita bisa turunkan nilainya
● Jika kita ingin menghapus nilai score untuk salah satu query, kita bisa beri nilai boost menjadi 0
Query Lainnya
Query Lainnya
● Sebenarnya masih banyak jenis Query yang didukung oleh Elasticsearch, bahkan terlalu banyak
● Contoh range, wildcard, regexp, geo search, exists, dan lain-lain
● Oleh karena itu, materi untuk Query akan kita bahas khusus di kelas terpisah, yaitu kelas
Elasticsearch Query DSL (Domain Specific Language)
Flattened Field
Flattened Field
● Secara default, setiap field akan disimpan sebagai key di Lucene Document
● Elasticsearch memiliki tipe data flattened, yang digunakan sebagai alternatif cara menyimpan data
di Lucene Document dengan cara mengambil semua value di semua child field, dan menyimpannya
dalam satu key-value sebagai keyword
● Ini cocok untuk kasus tipe data yang dinamis field nya, sehingga kita tidak perlu membuat mapping
terlalu banyak
Flattened Object
● Selain menggunakan field tipe data flattened, kita juga bisa mencari nested field pada flattened
object menggunakan . (titik), sama seperti object biasanya
● Namun perlu diingat, karena tipe data flattened menyimpan semua data dalam tipe data keyword,
artinya bisa dicari menggunakan Query dan juga di Sorting
● Namun hati-hati dengan Sorting, karena datanya keyword, jadi akan diurutkan berdasarkan
lexicographically, jadi bisa saja berbeda hasilnya kalo misal kita memiliki value number
Nested Field
Tipe Data Object dan Array
● Sebelumnya kita sudah bahas tipe data Object dan Array, seperti yang dijelaskan sebelumnya,
bahwa tipe data tersebut tidak didukung oleh Lucene Document, oleh karena itu secara otomatis
dibuat sebagai data flat oleh Elasticsearch
● Namun, terdapat masalah yang terjadi ketika pada kasus tertentu
Mencari Kombinasi di Tipe Data Object
● Sekarang misal kita ingin mencari parents yang memiliki anak dengan nama Joko Nugraha
● Dari data sebelumnya, harusnya kita tidak menemukan data, karena parent Eko Khannedy,
memiliki anak Budi Nugraha dan Joko Morro, tidak ada anak yang bernama Joko Nugraha
● Namun karena data di Lucene Document sudah dibuat menjadi flat, secara otomatis anak dengan
nama Joko Nugraha akan ditemukan di parent Eko Khannedy
Nested Field
● Nested adalah tipe data spesial untuk object yang digunakan untuk menyimpan tiap object di array
pada dokumen yang independen
● Nested field dan Query yang dilakukan ke nested field sebenarnya adalah operasi yang sangat
mahal, oleh karena itu, gunakan dengan bijak ketika menggunakan tipe data nested ini
● Selain itu, karena nested field dilakukan oleh Elasticsearch dengan cara membuat hidden Lucene
Document, oleh karena itu untuk melakukan Query ke nested field, kita juga harus menggunakan
Nested Query
Multi Fields
Multi Fields
● Salah satu fitur yang menarik di Elasticsearch adalah Multi Fields, Multi Fields adalah fitur dimana
kita bisa membuat beberapa nama field dari satu field
● Yang menarik adalah, field tambahan tersebut bisa menggunakan tipe data yang berbeda
● Contoh, kita ingin membuat field name, tapi kita ingin menggunakan tipe data text dan keyword.
Pada kasus ini, kita bisa membuat 2 field misal name dan name_raw, namun kita harus memastikan
dua value tersebut selalu sama
● Dengan Multi Fields, kita tidak perlu membuat 2 field, cukup buat 1 field, lalu membuat Multi Fields
dari field yang sudah ada dengan tipe berbeda
Update by Query API
Update by Query API
● Saat kita misal menambah mapping seperti Multi Fields pada index yang sudah ada dokumennya,
secara otomatis data di dalam Multi Fields tidak tersedia, kita harus melakukan reindex lagi
● Namun untungnya, Elasticsearch memiliki API untuk melakukan Update by Query API
● Jangan bingung dengan nama nya, karena ini bukan untuk mengubah banyak data sekaligus, namun
lebih ke mengupdate Lucene Document dengan mapping baru
● Kita bisa menggunakan API :
POST /<index_name>/_update_by_query
● Lalu gunakan request body Query
Delete by Query API
Delete by Query API
● Sebelumnya kita sudah bahas tentang Delete API menggunakan _id dokumen
● Elasticsearch juga menyediakan API untuk menghapus dokumen menggunakan Query
● API ini bisa berdampak ke banyak dokumen, artinya bisa menghapus banyak dokumen sekaligus
● Kita bisa menggunakan API :
POST /<index_name>/_delete_by_query
● Dan gunakan Query pada request body nya
Search After
Deep Paging Problem
● Saat ini, secara default Elasticsearch membatasi untuk mengembalikan hasil pencarian hanya 10K
data (ingat, hasil pencarian, bukan total dokumen di index), yang artinya kita hanya bisa melihat
hasil pencarian sampai hasil ke 10K
● Hal ini terjadi karena dalam Distributed System, terdapat masalah Deep Paging Problem
● Elasticsearch saat berjalan biasanya nanti akan memiliki lebih dari satu Node (aplikasi yang
berjalan)
● Ketika kita mencari data, Elasticsearch harus mengumpulkan seluruh dari dari semua aplikasi yang
berjalan, dan secara otomatis mengurutkan dan melakukan pagination ulang dari hasil seluruh
aplikasi
● Semakin banyak data hasil pencarian, semakin berat, oleh karena itu hanya dibatasi sampai 10K,
walaupun sebenarnya bisa kita naikkan angkanya, tapi tidak direkomendasikan
Category Data
● Sekarang kita akan coba simulasi deep paging menggunakan data categories
● Silahkan download 20K data categories disini, lalu save menggunakan Bulk API
● https://gist.github.com/khannedy/d87f7a04222fbb47d24b2786de6a2064
Scroll API
● Di Elasticsearch, untuk mengambil seluruh data pencarian, kita bisa menggunakan Scroll API
● Namun penggunaan Scroll API sekarang sudah tidak direkomendasikan lagi, lebih
direkomendasikan menggunakan Search After
● https://www.elastic.co/guide/en/elasticsearch/reference/current/scroll-api.html
Search After
● Lantas bagaimana jika kita ingin mengambil seluruh data pencarian? Misal untuk membuat
dokumen CSV dari seluruh hasil pencarian
● Pada kasus itu, kita bisa memanfaatkan fitur bernama Search After
● Sederhananya, Search After akan selalu mengubah Query pencarian yang kita buat, sehingga hasil
pencarian yang diambil akan selalu pencarian halaman pertama
● Search after membutuhkan sorting, dan dari sorting kita bisa menggunakan nilai tersebut untuk
melakukan query selanjutnya di Search After
Cat API
Cat API
● Compact and aligned text (CAT) APIs adalah API yang disediakan oleh Elasticsearch untuk melihat
informasi yang terdapat di Elasticsearch
● Misal informasi kesehatan, index, shard, nodes, dan lain-lain
● API ini bukan digunakan untuk aplikasi (program yang kita buat), biasanya API ini digunakan untuk
pengguna yang melakukan pemeliharaan Elasticsearch
● Ada banyak sekali API dalam Cat API, kita bisa melihat semuanya di :
GET /_cat
● https://www.elastic.co/guide/en/elasticsearch/reference/current/cat.html
Snapshot
Snapshot
● Sebelum kita membuat snapshot, kita harus terlebih dahulu membuat Repository
● Repository yaitu lokasi kita menyimpan snapshot
● Elasticsearch mendukung banyak sekali lokasi Repository, seperti AWS S3, GCP Storage, Azure
Storage dan lain-lain, namun pada materi ini kita akan bahas yang paling mudah, yaitu
menggunakan File Storage, sehingga bisa kita lakukan di komputer kita
● Untuk membuat lokasi Repository, kita perlu mengubah konfigurasi elasticsearch.yml, setelah kita
kita harus melakukan restart Elasticsearch
Membuat Repository
● Setelah membuat snapshot, kita bisa melakukan Restore snapshot ketika dibutuhkan
● Restore tidak perlu dilakukan untuk seluruh index, kita bisa memilih index mana yang akan kita
restore
● Misal, kita akan coba delete semua data di index categories, lalu kita akan coba restore dari
snapshot yang sudah kita buat
● Untuk melakukan restore, kita bisa menggunakan API :
POST /_snapshot/<nama_repository>/<nama_snapshot>/_restore
Close dan Open
● Saat kita melakukan restore, Elasticsearch mewajibkan kita melakukan close Index
● Close index digunakan untuk menutup index, sehingga proses read dan write akan ditolak. Jadi kita
tidak bisa mengubah dokumen atau membaca dokumen
● Ini diperlukan agar ketika proses restore berjalan, tidak ada perubahan yang terjadi sehingga
mengakibatkan dokumen menjadi corrupt
● Setelah selesai proses restore, kita bisa membuat kembali index menggunakan Open Index API
Menghapus Snapshot
● Jika kita tidak membutuhkan lagi snapshot yang sudah kita buat, kita bisa menghapusnya
menggunakan API :
DELETE /_snapshot/<nama_repository>/<nama_snapshot>
● Atau jika ingin menghapus Repository dan Snapshot yang ada di dalamnya, kita bisa gunakan API :
DELETE /_snapshot/<nama_repository>
Materi Selanjutnya
Materi Selanjutnya