Elasticsearch Snapshot and Restore Data

Halo Sobat Nostra, pada kali in saya akan berbagi tutorial bagaimana cara membuat snapshot (backup) dan restore data pada elasticsearch dengan mudah. Apa itu elasticsearch? elasticsearch adalah adalah salah satu database yang masuk ke dunia NoSQL dengan fokus di search engine database. Kenapa kita memerlukan backup data? Apabila suatu ketika kita memiliki kerusakan data atau kehilangan data kita dapat mengambil kembali dari data yang sudah kita backup sebelumnya. Karena data itu sangat penting sehingga kita harus memiliki backup. Snapshot juga dapat kita lakukan apabila kita ingin migrasi ke elastic versi yang lebih baru. Sebelum kita mulai, elasticsearch harus sudah terinstall dan pastikan sudah listen di port default elasticsearch 9200 dan 9300. Mari kita mulai tutorialnya.

Hal pertama yang kita lakukan adalah menambahkan lokasi repo.path di elasticsearch.yml. Path ini adalah filesystem lokal dimana snapshot akan disimpan.

Kita buat folder di /home/elasticsearch/backup

 mkdir –p /home/elasticsearch/backup  
 chown -R elasticsearch. /etc/elasticsearch/backup  

Tambahkan konfigurasi di elasticsearch.yml

 path.repo: ["/etc/elasticsearch/backup"]  

Restart service elasticsearch

 systemctl restart elasticsearch  

Setup the snapshot repository

Sebelum kita snapshot dan restore, kita harus mendaftarkan path repository di Elasticsearch dengan menggunakan perintah:

 curl -XPUT "http://localhost:9200/_snapshot/es_backup" -H 'Content-Type: application/json' -d'  
 {  
   "type": "fs",  
   "settings": {  
     "location": ["/etc/elasticsearch/backup "  
     , "compress": true  
   }  
 }'  

Untuk mengeceknya dengan command:
curl -XGET 'localhost:9200/_snapshot/es_backup?pretty'

Take snapshots

Sekarang kita sudah bisa melakukan backup atau restore. Kita lanjut cara backup data (index).
cek list index pada elasticsearch

 curl -XGET 'localhost:9200/_cat/indices?v&pretty'  

Create snapshot dengan perintah:

 curl -XPUT 'localhost:9200/_snapshot/es_backup/snapshot_1?wait_for_completion=true&pretty'  

Defaultnya semua index yang open dan start akan disnapshot. Kita dapat membuat snapshot hanya index yang kita ingin backup dengan cara dibawah ini:

 curl -XPUT 'localhost:9200/_snapshot/es_backup/snapshot_1?pretty' -H 'Content-Type: application/json' -d'  
 {  
  "indices": "index_1,index_2",  
  "ignore_unavailable": true,  
  "include_global_state": false  
 }'  

Untuk melihat hasil semua snapshot dengan perintah:

 curl -XGET 'localhost:9200/_snapshot/es_backup/_all?pretty'  

Untuk menghapus snapshot dapat menggunakan:

 curl -XDELETE 'localhost:9200/_snapshot/es_backup/snapshot_1?pretty'  

Restore snapshots

Kita akan merestore data dari snapshot ke elasticsearch. Ada yang harus kita perhatikan sebelum restore data. Pertama index yang kita snapshot sebelumnya akan memiliki nama yang sama dengan  index pada elasticsearch sehingga kita harus close atau delete index tersebut.

 curl -XPOST 'localhost:9200/my_index/_close'  

Kemudian lakukan restore snapshot:

 curl -XPOST 'localhost:9200/_snapshot/es_backup/snapshot_1/_restore?pretty'  

Untuk memonitor progress restore/snapshot dengan perintah:

 curl -XGET 'localhost:9200/_snapshot/es_backup/snapshot_1?pretty'  

Jika kita ingin memindahkan hasil snapshot ke mesin lain, hal yang kita lakukan adalah dengan mencopy folder dimana snapshot kita simpan ke mesin tersebut dan selanjutnya merestore snapshot ke elasticsearch.


Elasticdump

Ada cara lain untuk membackup data elasticsearch yaitu dengan menggunakan elasticdump. Kekurangan elasticdump adalah sulit untuk restore. Jadi apabila kita hanya ingin menyimpan datanya tanpa ingin restore kita dapat menggunakan elasticdump. Hasil dari backup index tersebut akan berupa json dan dapat kita buat langsung ke dalam gzip file.

Pertama install terlebih dahulu service elasticdump:

 npm install elasticdump –g  

Kemudian lakukan backup:

 elasticdump \  
  --input=localhost:9200/my_index \  
  --output=$ \  
  | gzip > /home/elasticsearch/backup/my_index.json.gz  

Sekian dari saya semoga apa yang saya share dapat bermanfaat.
Terima kasih :)        

References:

• https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-snapshots.html

• https://www.npmjs.com/package/elasticdump

Import Data from .csv to Elasticsearch Index

       Halo sobat Nostra, artikel selanjutnya kita akan membahas tentang cara import data dalam bentuk .csv kedalam sebuah index yang ada didalam Elasticsearch dengan menggunakan Python script. Elasticsearch adalah "RESTful search and analytics engine" yang merupakan salah satu database yang masuk ke dunia NoSQL dengan fokus di search engine database. Elasticsearch mengasumsikan indeks sebagai "database", types sebagai "tabel" dan dokumen sebagai record atau row, sedangkan mapping dapat diasumsikan sebagai "skema tabel". Sebelum kita masuk ke import data, kita belajar untuk add dan mapping sebuah index ke Elasticsearch. Pada dasarnya Elasticsearch akan membuka port 9200(HTTP) dan 9300(TCP) untuk diakses oleh user. 

Setelah kita selesai create dan mappping index, siapkan file .csv yang sudah berisikan data dengan struktur yang sama dengan mapping (id, name, type). Dalam kasus ini kita akan import file consumer.csv dengan data :

Next install python, request module, dan siapkan scriptnya :

Setelah itu jalankan file script.py dengan command :

Done, data didalam consumer.csv akan masuk ke dalam index consumer/consumer_detail. 

Terimakasih, semoga bermanfaat.

Referensi :

• https://www.elastic.co/products/elasticsearch
• https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html
• https://www.codepolitan.com/pengenalan-singkat-elasticsearch

Implementasi Full-text Search dengan ElasticSearch dan Firebase

Kembali lagi pada sesi pembahasan mengenai implementasi Firebase pada blog Nostra ini. Seperti yang pernah dibahas pada beberapa tulisan sebelumnya, Firebase merupakan sebuah layanan Backend as a Service (Baas) yang sudah diakuisisi oleh Google. Oke, kalau Firebase merupakan layanan BaaS, lalu apakah kita masih perlu sebuah server dengan Backend yang kita kembangkan sendiri? Jawabannya adalah tergantung pada desain/arsitektur aplikasi yang dikembangkan.

Pada dasarnya Firebase dapat diimplementasikan dengan tiga pilihan cara, sesuai dengan tulisan pada artikel milik Firebase. Berdasarkan artikel tersebut, bagaimana caranya untuk mengimplementasikan ElasticSearch (ES) bersamaan dengan Firebase? dan apa sebenarnya ES itu sendiri? Pada tulisan ini, kami akan mencoba untuk menjelaskan secara singkat mengenai ES dan bagaimana mengimplementasikannya dengan Firebase.

Pertama mari kita bahas terlebih dahulu mengenai ES. Secara sederhana ES adalah sebuah open source search engine yang dibangun diatas Apache Lucene. ES juga dapat dikatakan sebagai sebuah RESTful search engine, karena ES berkomunikasi dengan menggunakan RESTful API. Secara arsitektur ES terdiri atas node dan cluster sehingga ES sebaiknya dipasang pada Virtual Machine (VM) tersendiri, sehingga ES dapat memiliki performa maksimal. Apakah sudah terbayang mengenai apa itu ES? Jika belum, maka sebaiknya melakukan eksperimen dengan mengikuti panduan resmi milik ES.

Apabila ES dipasang sebagai sebuah VM tersendiri, lalu bagaimana ES dapat diimplementasikan bersama dengan Firebase? berdasarkan artikel yang telah diberikan pada bagian awal tulisan ini, maka implementasi tersebut berada pada arsitektur kedua, yang dapat dilihat pada gambar berikut.

Lalu dengan arsitektur tersebut, dimana letak VM dari ES seperti yang telah disebutkan?

.

.

.

.

.

.

.

Benar sekali, berdasarkan arsitektur tersebut maka tidak terdapat VM terpisah dari ES, melainkan ES dipasang langsung pada VM yang sama dengan server. Apabila menggunakan arsitektur tersebut maka ES dan Backend (BE) dari aplikasi kita akan berada pada satu VM yang sama. Hal tersebut sebaiknya dihindari, kenapa? Karena apabila salah satu dari ES ataupun BE aplikasi kita mengalami workload yang berlebihan, maka hal tersebut akan saling mengacaukan performa satu sama lainnya. Oleh karena itu sebaiknya ES dipasang pada VM yang terpisah.

Lalu?

.

.

.

.

.

.

.
Jika kita mengimplementasikan BE dan ES pada dua VM yang berbeda, maka arsitektur dari aplikasi kita kurang lebih akan seperti pada gambar berikut.

Berdasarkan arsitektur tersebut, maka ES akan berkomunikasi secara langsung dengan BE, sedangkan BE juga akan berkomunikasi dengan Firebase. Mengapa kita menggunakan arsitektur model kedua pada artikel diatas? Kenapa bukan arsitektur ketiga? Good questions.

Alasannya adalah karena pada implementasi ini BE akan bersikap sama seperti Fronted (FE), yaitu BE akan me-listen pada node di Firebase. Dengan implementasi tersebut maka kita akan menyimpan konfigurasi search query dan juga search request serta search result pada Firebase Real-time Database seperti pada contoh di bawah.

Seperti yang dapat dilihat, secara realtime Firebase akan mencatat search request yang selanjutnya akan dibaca oleh BE dan kemudian dilemparkan kepada ES untuk melakukan pencarian. Implementasi tersebut dapat dilakukan dengan beberapa tahapan, antara lain:

1. Sinkronisasi data antara Firebase dengan ES yang dapat dilakukan dengan memanfaatkan listener terhadap node yang akan dilakukan pencarian, seperti pada contoh berikut.

2. Memasang listener pada node search request, sehingga setiap ada input pencarian maka BE akan langsung melemparkan query tersebut pada ES untuk mencari data yang dimaksud. Contoh implementasi pada tahap ini dapat dilihat pada gambar berikut.

3. Setelah terdapat pencarian pada node search request, maka langkah selanjutnya adalah melakukan proses pencarian pada ES berdasarkan masukan pada node tersebut. Karena search query sudah kita simpan pada Firebase Real-time Database, maka implementasi pencarian pada ES dapat kita implementasikan seperti pada contoh berikut.

4. Ketika proses pencarian pada ES telah selesai, maka BE akan mengembalikan hasil pencarian ES pada node search result di Firebase seperti pada contoh implementasi berikut.

5. Selanjutnya pada sisi Frontend (FE) juga akan memasang listener pada node search result sehingga ketika BE mengembalikan hasil pencarian pada Firebase maka FE akan langsung mendapatkan hasil tersebut.

Bagaimana? semoga tulisan ini dapat membantu kalian yang ingin mencoba untuk mengimplementasikannya. Good luck and have a nice app!

Sampai berjumpa pada tulisan-tulisan berikutnya.

P.S.

Contoh implementasi lain dari ElasticSearch dengan Firebase dapat dilihat pada link ini.

Referensi:
https://www.elastic.co/guide/en/elasticsearch/guide/current/intro.html
https://qbox.io/blog/what-is-elasticsearch
http://stackoverflow.com/questions/671118/what-exactly-is-restful-programming

Sebuah cara untuk mengatasi error code 429 pada Elasticsearch 2.3.5

(node:2159) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 155): Error: [es_rejected_execution_exception] rejected execution of org.elasticsearch.transport.TransportService$4@518af8b7 on EsThreadPoolExecutor[index, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@ce8e2a8[Running, pool size = 1, active threads = 1, queued tasks = 200, completed tasks = 1030]] :: {"path":"/data/customers-from-orders/%2B62813678456","query":{},"body":"{\"name\":\"Antonov\",\"phone\":\"+6281XXXXXXX\"}","statusCode":429,"response":"{\"error\":{\"root_cause\":[{\"type\":\"es_rejected_execution_exception\",\"reason\":\"rejected execution of org.elasticsearch.transport.TransportService$4@518af8b7 on EsThreadPoolExecutor[index, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@ce8e2a8[Running, pool size = 1, active threads = 1, queued tasks = 200, completed tasks = 1030]]\"}],\"type\":\"es_rejected_execution_exception\",\"reason\":\"rejected execution of org.elasticsearch.transport.TransportService$4@518af8b7 on EsThreadPoolExecutor[index, queue capacity = 200, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@ce8e2a8[Running, pool size = 1, active threads = 1, queued tasks = 200, completed tasks = 1030]]\"},\"status\":429}"}

Ya, itulah log dari elasticsearch 2.3.5 yang saya temukan ketika melakukan bulk insert / update ke elasticsearch.

Saya memiliki data di firebase realtime database namun saat blog ini ditulis, firebase realtime database belum memiliki fungsi pencarian selengkap dengan RDBMS, misal MySQL, PostgreSQL ataupun selengkap elasticsearch. Untuk keperluan pencarian tersebut, maka saya men-sync-kan data tersebut ke elasticsearch, dengan harapan dapat memanfaatkan fitur-fitur di elasticsearch untuk mencari pada data tersebut.

Namun karena data yang sudah mulai banyak, dan proses read data secara asynchronous dari firebase, saya menemukan error dengan code 429 tersebut. Ada banyak cara untuk menghandle hal ini, misal :

• melakukan insert / update ke elasticsearch secara batch
• memperbesar queue threadpool elasticsearch
• memperbesar size threadpool elasticsearch
• dan lain-lain :)

Saya mencoba dengan cara yang kedua, memperbesar queue. Queue threadpool elasticsearch 2.3.5 masih dapat diubah, namun jika menggunakan elasticsearch 5.x, configurasi tersebut sudah tidak bisa diubah.

Salah satu cara mengubah configurasi queue threadpool, yaitu :

• Perubahan Permanen
Perubahan ini tetap berlaku walaupun server elasticsearch direstart.
curl -XPUT localhost:9200/_cluster/settings -d '{ "persistent" : { "threadpool.index.queue_size" : 1000 } }'
• Perubahan Sementara
Perubahan ini tidak berlaku setelah server elasticsearch direstart.
curl -XPUT localhost:9200/_cluster/settings -d '{ "transient" : { "threadpool.index.queue_size" : 1000 } }'

Setelah mengubah configurasi tersebut, error pun sudah tidak muncul lagi. Namun hal tersebut masih dapat muncul kembali apabila request insert/update ke elasticearch tidak dapat ditampung di queue threadpool yang baru.

Semoga Bermanfaat dan Tetap Semangat !!!

Iseng-iseng mantau GO-JEK di Twitter

Beberapa bulan terakhir ini di Jakarta lagi booming GO-JEK, biasanya kalo lagi seperti ini pasti di medsos juga lagi rame. Iseng-iseng mantauin Twitter searching pake kata kunci gojek dapetnya begini :

Hasil Pencarian di Twitter

Setelah pulang dari acara Hackathon Merdeka, jadi kepikiran untuk mantau gojek di Twitter pake ELK. Dannn... akhirnya buat juga deh. Berhubung masih punya free account di Google Cloud Platform (GCP),  bikin disana aja deh hehehe... Ini langkah-langkahnya :

1. Buat 3 VM dengan OS Ubuntu 14.04 LTS dengan tipe g1-small (1 vCPU, 1.7 GB Memory)
2. Download Elasticsearch & Logstash & Kibana di VM yang berbeda
3. Install Elasticsearch & Logstash dengan perintah ubuntu sudo dpkg -i DEB_PACKAGE
4. Untuk Kibana cukup ekstrak saja dari file yang sudah didownload
5. Buat Twitter Apps di sini
• Generate Consumer Key (API Key) & Consumer Secret (API Secret)
• Generate Access Token & Access Token Secret
6. Konfig Logstash sebagai pengumpul data dari Twitter
• Buat file /etc/logstash/conf.d/01-twitter-input.conf

input {
        twitter {
        consumer_key => "CONSUMER_KEY"
            consumer_secret => "CONSUMER_SECRET"
            keywords => "gojek"
            oauth_token => "ACCESS_TOKEN"
            oauth_token_secret => "ACCESS_TOKEN_SECRET"
        }
}

• Buat file /etc/logstash/conf.d/30-twitter-output.conf

output {
    elasticsearch {
        protocol => "http"
        action => "index"
        host => "elasticsearch-01"
        index => "twitter-%{+YYYY.MM.dd}"
        workers => 1
    }
    stdout {}
}

7. Biarkan konfigurasi default dari Elasticsearch dan Kibana
8. Jalankan Logstash sudo service logstash start
9. Jalankan Elasticsearch sudo service elasticsearch start
10. Jalankan Kibana dari folder bin hasil ekstrak ./kibana 

Berikut barbuk yang sudah berjalan :

Log dari Logstash

Sense (Chrome Plugin) untuk mencari data pada Elasticsearch

Tambahkan index yang berawalan 'twitter-*'

Menu Discover untuk menampilkan stream dari Twitter 
yang diambil oleh Logstash dan disimpan di Elasticsearch

Yup, sekarang saya bisa memantau Twitter lewat Kibana, Thanks ELK!

Hackathon Merdeka 22-23 Agustus 2015

Hackathon

Pada tanggal 22-23 Agustus 2015, Code4Nation dan Kantor Staf Kepresidenan (KSP) mengadakan acara Hackathon di Gedung Krida Bhakti Sekneg. Menurut informasi dari panitia ada sekitar 80 tim yang terdaftar dalam acara tersebut dan kami dari Nostra merupakan salah satu dari tim yang hadir saat itu.

Permasalahan yang coba dipecahkan dalam acara itu ialah masalah distribusi pangan (gula, beras, daging sapi) entah kebetulan atau tidak, saat itu masalah tingginya harga daging sapi sedang menjadi buah bibir di masyarakat.

Mind Mapping Aplikasi Monitoring Harga Komoditi

Dalam penjelasan masalah yang disampaikan oleh tim KSP, kami menyimpulkan bahwa terjadi selisih harga pangan dari sentra produksi sampai ke sentra konsumsi yang cukup signifikan. Dan secara umum pada rantai distribusi pangan dari sentra produksi ke sentra konsumsi minimal ada satu pihak sebagai penghubung (middleman/tengkulak/broker).

Menurut pendapat saya, adanya penghubung tidak dapat dihindari dan tidak dapat hilangkan karena peran mereka melengkapi dan membantu peran pemerintah dalam menyalurkan komoditi. Namun bagaimana caranya untuk menjaga selisih harga supaya masih dalam taraf wajar ?

Untuk membantu menemukan solusi dari masalah tersebut, kami memiliki ide untuk membuat aplikasi monitoring harga komoditi. Ide tersebut kami tuangkan dalam bentuk Mind Mapping.

Input harga komoditi di sentra konsumsi bisa didapatkan dari Siaran RRI, Email, SMS, Twitter, Mobile App dan untuk input harga komoditi di sentra produksi bisa diinput manual oleh petugas terkait. Dengan demikian akan ada cukup data untuk membandingkan harga di sentra produksi dengan harga di sentra konsumsi.

Sedangkan outputnya yaitu Business Intelligence (BI) Dashboard, yang berguna untuk menampilkan data-data hasil analisa dalam waktu tertentu (harian) sesuai dengan input data yang masuk.

Karena acara Hackathon ini hanya berlangsung selama 2 hari dan 1 malam, maka kami memilih untuk menggunakan Twitter sebagai input datanya. Kenapa kami memilih Twitter karena, Twitter merupakan salah satu media sosial populer di negara kita, sehingga kami percaya bahwa melalui Twitter ini masyarakat Indonesia bisa berpartisipasi untuk ikut menjaga selisih harga supaya masih dalam taraf wajar.

Sedangkan untuk BI Dashboardnya kami menggunakan Kibana.

ELK

ELK merupakan kependekan dari Elasticsearch, Logstash, Kibana.

Logstash menggunakan input plugin untuk mengambil data beragam data source, misalnya Twitter, File, Database, dll. Dan menggunakan output plugin (Elasticsearch plugin) untuk meng-index data di Elasticsearch.

Elasticsearch merupakan mesin pencari dan analisa yang dibangun di atas Apache Lucene. Elasticsearch menggunakan format dokumen JSON sebagai standar komunikasinya.

Kibana merupakan platform analisa dan visualisasi yang didesain dapat bekerja sama dengan Elasticsearch. Dengan Kibana kita bisa mencari, melihat dan membuat dashboard dari data-data yang ada di Elasticsearch.

Berikut capture-capture untuk aplikasi yang sudah kami selesaikan pada Hackathon tersebut.

Input data dari Twitter

Melihat data di Kibana

Membuat visualisasi di Kibana

Dashboard di Kibana yang terdiri dari beberapa visualisasi

Tertarik untuk mengembangkan lebih lanjut? Silahkan hubungi kami. :)