membuat aplikasi terdistribusi, sync problem
Achmad Mardiansyah
mau nanya dong,
saya lagi buat aplikasi pelaporan untuk company yang punya beberapa
cabang dibeberapa kota. nah mulanya saya berencana untuk membuat
web-based application.
jadi semua aktivitas dilakukan disana:
- registrasi pengguna baru
- catatan transaksi penjualan
- activity log, dll
namun, tidak semua tempat memiliki koneksi internet cepat/selalu online.
jika lambat/ngak connect, maka bisnis bisa lambat/terhenti dan customer
bakal mencak2.
nah saya berpikir, gimana kalo buat aplikasi yang bersifat lokal,
sehingga tidak harus selalu online dengan website pusat. namun, data2
local dapat di-sync ke pusat.
pertanyaan:
- gimana best practice untuk mensync data2 tersebut? apakah harus
membuat aplikasi yang desktop based, atau bagaimana? apa harus membuat
aplikasi socket lagi?
- gimana antisipasi beberapa issue yang mungkin terjadi saat sync.
misal: sinkronisasi waktu, security, duplikasi data, dan kemungkinan
lainnya?
salam,
eRQee
pertanyaan:
- gimana best practice untuk mensync data2 tersebut? apakah harus membuat aplikasi yang desktop based, atau bagaimana? apa harus membuat aplikasi socket lagi?
- synchronous --> ini live update. kalo dalam konteks DBMS itu, situ bisa coba bikin service kecil2an utk connect ke remote server dan kirimkan update data terbaru di local server ke pusat. Atau mungkin bisa coba koneksi menggunakan federated storage engine. Dan kalo dalam konteks programming, bisa macam2 tekniknya. Tapi tentu saja teknik ini memerlukan koneksi yang stabil (nggak musti cepat sih, yg penting stabil). Bisa dilakukan di jam-jam idle.
- asynchronous --> ini teknik sinkronisasi dimana 2 titik yg mau men-sync itu nggak perlu dalam modus "sama-sama online". Analoginya adalah telepon (synchronous) dan SMS (asynchronous). Komunikasi menggunakan telepon akan enabled kalo dua orang itu sama-sama ngangkat telpon-nya. Kalo pihak yang ditelpon kagak ngangkat2 telpon-nya, kirim SMS, dan komunikasi asynchronous yg akan terjadi... :D
- gimana antisipasi beberapa issue yang mungkin terjadi saat sync. misal: sinkronisasi waktu, security, duplikasi data, dan kemungkinan lainnya?
--
Wassalam,
Rizky Prihanto
Chief Software Architect @ PT Cinox Media Insani
Blog: http://quotes.prihanto.web.id
☎ 0812 535 22 392 • Twitter: @erqee • FB: erqee • Y!M: prihantovic
Aris Setyawan
> ngangkat2 telpon-nya, kirim SMS, dan komunikasi asynchronous yg akan terjadi... :D
Benar, gunakan metode ini menggnakan aplikasi service kecil. Jangan
coba menggunakan mysql cluster atau mysql asynchronous replication
jika belum memiliki pengalaman menggunakannya dalam network yang tidak
stabil (since everything will go crazy).
> Teknik async ini cukup suitable utk menjamah environment2 sistem terdistribusi yang nggak memiliki infrastruktur komunikasi yang bagus.
> Caranya piye?
> Salah satunya adalah EMAIL.
Saya lebih suka menggunakan HTTPS, karena insyaalloh tidak akan ada
ISP yang memblock port 80. Dan kenapa tidak HTTP, karena data perlu
dienkripsi dahulu, sebelum berkelana di jagat internet.
Penggunaan EMAIL juga bagus. Good trick.
-aris
> --
> Untuk memposting, silakan reply email ini atau kirim email baru ke alamat: mysql-i...@googlegroups.com
> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat: mysql-indones...@googlegroups.com
>
> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi alamat: http://groups.google.com/group/mysql-indonesia?hl=id
Endy Muhardin
> halo semua
> namun, tidak semua tempat memiliki koneksi internet cepat/selalu online.
> jika lambat/ngak connect, maka bisnis bisa lambat/terhenti dan customer
> bakal mencak2.
>
> nah saya berpikir, gimana kalo buat aplikasi yang bersifat lokal, sehingga
> tidak harus selalu online dengan website pusat. namun, data2 local dapat
> di-sync ke pusat.
>
> pertanyaan:
> - gimana best practice untuk mensync data2 tersebut? apakah harus membuat
> aplikasi yang desktop based, atau bagaimana? apa harus membuat aplikasi
> socket lagi?
> - gimana antisipasi beberapa issue yang mungkin terjadi saat sync. misal:
> sinkronisasi waktu, security, duplikasi data, dan kemungkinan lainnya?
>
Ini namanya aplikasi dengan database terdistribusi.
Kita punya satu project yang arsitekturnya seperti ini, yaitu aplikasi
dealer motor.
Masing-masing cabang bisa entri transaksi sendiri, lalu bisa sync ke pusat.
Sinkronisasi dilakukan melalui email (GMail, karena clientnya gak
punya server dengan IP public)
Semua cabang dan pusat, pake koneksi spidi.
Format data yang dikirim adalah JSON.
Dari pengalaman kita bikin itu, best practicesnya :
1. Jangan dilakukan !!!
Effort untuk maintenance datanya sangat luar biasa besar.
Sebisa mungkin yakinkan clientnya bahwa single database is the best
2. Kalau memang terpaksa dilakukan, definisikan dengan jelas,
siapa yang melakukan maintenance data.
Kalo kita yang lakukan, mendingan siapin aja quotation mandaysnya.
Jangan lupa nilai projectnya juga harus dikalikan 3 dari estimasi
standar, karena kita harus implement hal2 pada poin berikutnya.
3. Setelah urusan non-teknis dibereskan, definisikan dengan jelas data
apa yang perlu di sync, dan gimana arahnya.
Contohnya : data master (kode produk, harga, dsb) itu cuma satu arah
dari pusat ke cabang.
Jadi kalo ada merek motor baru, entri harus di pusat.
Data penjualan, satu arah dari cabang ke pusat dan tidak perlu
dibroadcast ke cabang lain.
Data mutasi antar cabang, hanya melibatkan cabang2 yang terpengaruh, dan pusat.
Dan rule2 lain seperti itu, sebelum mulai coding harus jelas dulu.
4. Seperti katanya eRQee, pakai UUID untuk primary key, jangan pakai
autoincrement
5. Harus ada kolom version dan last updated di tiap tabel.
Pada intinya, kita harus reimplement fitur Subversion[1] di aplikasi
kita, lengkap dengan
deteksi versi gak up to date, sama conflict resolution (gimana kalo
ada yang ngedit barengan).
6. Implement status pengiriman message, handler untuk mendeteksi dan
mengatasi kalo :
- gagal kirim
- sudah berangkat, tapi gak sampe ke mailbox penerima
- sudah terkirim ke mailbox penerima, tapi gak didonlod sampe seminggu
- sudah dikirim, sudah didonlod, tapi gagal proses gara2 message incomplete
- sudah dikirim, didonlod dengan komplit, tapi konflik karena record
yang sama sudah diedit di local.
7. Konversi data
Data yang mau disync harus dikonversi lagi supaya hemat bandwidth.
Gak bisa apa adanya hasil query langsung dikirim.
Perlu dipertimbangkan juga apakah perlu dikompres juga.
Kira2 demikian, jangan lupa, poin pertama adalah yang paling penting ;p
[1] http://subversion.apache.org
--
Endy Muhardin
http://endy.artivisi.com
dhika kiting
tapi Bagaimana klo jumlah datanya besar?
apakah masih memungkinkan dikirim dengan email?
misalkan dijadwalkan pengirimannya seminggu sekali.
ternyata dalam waktu seminggu saja udah ada puluhan ribu row.
kira2 apa solusinya jika kasusnya data tersebut cukup besar namun di
site cabang hanya ada akses internet menggunakan modem USB yg syukur
alhamdulillah sinyalnya GPRS?
thanks :D
>> Dengan demikian, isu waktu& duplikasi data bisa diminimize.
C-I
terdistribusi lagi tetapi lebih banwith issue bagaimana ingin transfer
data besar dgn koneksi pas pasan.
Ada batasan yang sangat jelas antara issue tentang aplikasi
terdistribusi atau issue bandwith
Pada saat koneksi internet sudah tidak memadai utk pengiriman data dgn
size tertentu, maka sudah saat nya utk upgrade bandwith atau gunakan
cara manual yaitu copy data ke hard disk external dan kirim lewat kurir.
--
thanks
C-I
http://www.hell0w0rld.co.cc
When Kn0wledge as free as bee(r)
Achmad Mardiansyah
2011/8/4 Achmad Mardiansyah <a.mard...@gmail.com>pertanyaan:
- gimana best practice untuk mensync data2 tersebut? apakah harus membuat aplikasi yang desktop based, atau bagaimana? apa harus membuat aplikasi socket lagi?
Nggak perlu desktop ah. Web based juga bisa, tapi diconnect-in ke local server aja. Atau bisa juga di standalone server (xampp/mowes/dan sekitarnya).
Untuk sync-nya, --setau gw-- ada 2 teknik:
- synchronous --> ini live update. kalo dalam konteks DBMS itu, situ bisa coba bikin service kecil2an utk connect ke remote server dan kirimkan update data terbaru di local server ke pusat. Atau mungkin bisa coba koneksi menggunakan federated storage engine. Dan kalo dalam konteks programming, bisa macam2 tekniknya. Tapi tentu saja teknik ini memerlukan koneksi yang stabil (nggak musti cepat sih, yg penting stabil). Bisa dilakukan di jam-jam idle.
berarti sama seperti rencana awal saya yang membuat web-based application sentralistik, yang diakses oleh sebuah cabang.
- asynchronous --> ini teknik sinkronisasi dimana 2 titik yg mau men-sync itu nggak perlu dalam modus "sama-sama online". Analoginya adalah telepon (synchronous) dan SMS (asynchronous). Komunikasi menggunakan telepon akan enabled kalo dua orang itu sama-sama ngangkat telpon-nya. Kalo pihak yang ditelpon kagak ngangkat2 telpon-nya, kirim SMS, dan komunikasi asynchronous yg akan terjadi... :D
Teknik async ini cukup suitable utk menjamah environment2 sistem terdistribusi yang nggak memiliki infrastruktur komunikasi yang bagus.Caranya piye?
Salah satunya adalah EMAIL.
di aplikasi cabang, data-data baru akan direkap, compose dalam format CSV, XML, YML, JSON, atau yg lain... trus di-email-kan ke kantor pusat.Setelah itu di kantor pusat akan menerima email tsb, lalu akan mendecompose-nya dan memasukkannya ke database pusat.
Prosedur rekap - kirim - terima - decompose - extract ini bisa dilakukan secara manual atau automatic.
trik yang bagus.
2011/8/4 Achmad Mardiansyah <a.mard...@gmail.com>- gimana antisipasi beberapa issue yang mungkin terjadi saat sync. misal: sinkronisasi waktu, security, duplikasi data, dan kemungkinan lainnya?
Menurut gw, issue terpenting sebenarnya adalah di struktur data.
Struktur data dari aplikasi terdistribusi (terkhusus di database pusat) itu kudu sustainable untuk menampung data2 yang berasal dari banyak (dan beragam) data source. Rata-rata sistem terdistribusi yang tangguh adalah sistem yang SEJAK AWAL udah dirancang untuk menangani model terdistribusi. Misalnya ada composite key (id_cabang, id_something) kah, atau mempergunakan UUID, dsb dsb. Juga ada kolom timestamp kapan data masuk, kapan data di-update, kapan data udah di-sync (meskipun ini kadang 'ngerusuhi' struktur data -- tapi seringkali informasi yang tersimpan di kolom-kolom ini cukup membantu proses sync)
Dengan demikian, isu waktu & duplikasi data bisa diminimize.
yang menjadi issue lagi waktu yang berkaitan dengan timezone,
karena cabangnya bisa beda time zone dengan pusat.
nah best practicenya gimana yah?
- apakah semua zona waktu harus diseragamkan? okelah ada aturan kalo tiap cabang harus sync waktu ke NTP server, namun kalo salah ngeset timezone gimana yah?
- atau mysql tersebut memang support time zone?
Achmad Mardiansyah
>> asynchronous --> ini teknik sinkronisasi dimana 2 titik yg mau men-sync itu nggak perlu dalam modus "sama-sama online". Analoginya adalah telepon (synchronous)
>> dan SMS (asynchronous). Komunikasi menggunakan telepon akarn enabled kalo dua orang itu sama-sama ngangkat telpon-nya. Kalo pihak yang ditelpon kagak
>> ngangkat2 telpon-nya, kirim SMS, dan komunikasi asynchronous yg akan terjadi... :D
> Benar, gunakan metode ini menggnakan aplikasi service kecil. Jangan
> coba menggunakan mysql cluster atau mysql asynchronous replication
> jika belum memiliki pengalaman menggunakannya dalam network yang tidak
> stabil (since everything will go crazy).
untuk cluster kliatannya saya memang ngak kepikiran kesitu mas,
dulu pernah kerja jadi sysadmin yang systemnya pake oracle RAC.
kadang2 itu system (database) bisa gila juga, pernah sekali ngehang gila
sampe shutdown.
customer mencak2 dan setelah diselidiki dari oracle log, system log,
ngak jelas tuh penyebabnya apa.
yang saya cerita diatas itu system clusternya sebelah-sebelahan loh,
apalagi kalo beda lokasi seperti indo?
hehehe
>> Teknik async ini cukup suitable utk menjamah environment2 sistem terdistribusi yang nggak memiliki infrastruktur komunikasi yang bagus.
>> Caranya piye?
>> Salah satunya adalah EMAIL.
> Saya lebih suka menggunakan HTTPS, karena insyaalloh tidak akan ada
> ISP yang memblock port 80. Dan kenapa tidak HTTP, karena data perlu
> dienkripsi dahulu, sebelum berkelana di jagat internet.
>
> Penggunaan EMAIL juga bagus. Good trick.
>
> -aris
>
Achmad Mardiansyah
tapi kondisi di lapangan dimana koneksi ke pusat ngak selalu ada, bakal
susah juga.
btw, kalo aplikasi reservasi tiket pesawat seperti yang ada di travel
agent gitu apakah menggunakan metode synchronous bukan yah? kalo dari
yang saya liat, mereka ngetik2 di konsole gitu, sehingga bisa jadi tipe
aplikasinya adalah centralised & realtime.
> 2. Kalau memang terpaksa dilakukan, definisikan dengan jelas,
> siapa yang melakukan maintenance data.
> Kalo kita yang lakukan, mendingan siapin aja quotation mandaysnya.
> Jangan lupa nilai projectnya juga harus dikalikan 3 dari estimasi
> standar, karena kita harus implement hal2 pada poin berikutnya.
>
> 3. Setelah urusan non-teknis dibereskan, definisikan dengan jelas data
> apa yang perlu di sync, dan gimana arahnya.
> Contohnya : data master (kode produk, harga, dsb) itu cuma satu arah
> dari pusat ke cabang.
> Jadi kalo ada merek motor baru, entri harus di pusat.
> Data penjualan, satu arah dari cabang ke pusat dan tidak perlu
> dibroadcast ke cabang lain.
> Data mutasi antar cabang, hanya melibatkan cabang2 yang terpengaruh, dan pusat.
> Dan rule2 lain seperti itu, sebelum mulai coding harus jelas dulu.
sejauh pikiran saya, interaksinya antar cabang & pusat saja.
dan pusat itu sebagai central clearing house dari semua cabang, jadi
semuanya memang harus lewat pusat.
nah bisa dijelaskan contoh kasus yang melibatkan antar cabang?
> 4. Seperti katanya eRQee, pakai UUID untuk primary key, jangan pakai
> autoincrement
>
> 5. Harus ada kolom version dan last updated di tiap tabel.
> Pada intinya, kita harus reimplement fitur Subversion[1] di aplikasi
> kita, lengkap dengan
> deteksi versi gak up to date, sama conflict resolution (gimana kalo
> ada yang ngedit barengan).
>
> 6. Implement status pengiriman message, handler untuk mendeteksi dan
> mengatasi kalo :
> - gagal kirim
> - sudah berangkat, tapi gak sampe ke mailbox penerima
> - sudah terkirim ke mailbox penerima, tapi gak didonlod sampe seminggu
> - sudah dikirim, sudah didonlod, tapi gagal proses gara2 message incomplete
> - sudah dikirim, didonlod dengan komplit, tapi konflik karena record
> yang sama sudah diedit di local.
ada teknik untuk memastikan bahwa data local sudah 100% sesuai dengan
pusat? dan sebaliknya?
> 7. Konversi data
> Data yang mau disync harus dikonversi lagi supaya hemat bandwidth.
> Gak bisa apa adanya hasil query langsung dikirim.
> Perlu dipertimbangkan juga apakah perlu dikompres juga.
sekedar ide, gimana kalo SQL statements tersebut ditulis ke file selain
juga ke database local, kemudian file ini dikirim ke pusat via SCP (port
22), terus dibuka oleh server pusat dan dimasukkan ke database pusat?
ada yang pernah implementasi ini?
> Kira2 demikian, jangan lupa, poin pertama adalah yang paling penting ;p
>
> [1] http://subversion.apache.org
>
Achmad Mardiansyah
hehehe
kalo fixed line sih ada, tuh pake telkomnyet...
xixixixi
On 08/05/2011 01:27 PM, dhika kiting wrote:
> nice trick.
> tapi Bagaimana klo jumlah datanya besar?
> apakah masih memungkinkan dikirim dengan email?
> misalkan dijadwalkan pengirimannya seminggu sekali.
> ternyata dalam waktu seminggu saja udah ada puluhan ribu row.
> kira2 apa solusinya jika kasusnya data tersebut cukup besar namun di
> site cabang hanya ada akses internet menggunakan modem USB yg syukur
> alhamdulillah sinyalnya GPRS?
> thanks :D
>
Endy Muhardin
>
> btw, kalo aplikasi reservasi tiket pesawat seperti yang ada di travel agent
> gitu apakah menggunakan metode synchronous bukan yah? kalo dari yang saya
> liat, mereka ngetik2 di konsole gitu, sehingga bisa jadi tipe aplikasinya
> adalah centralised & realtime.
Aplikasi transaksi keuangan harus selalu synchronous,
soalnya harus langsung ketahuan transaksinya gagal atau berhasil.
Kan urusannya mendebet deposit/rekening.
Indikator sync/async itu bukan dilihat dari konsole atau webbased.
Tapi dari status transaksinya.
Kalo sync, status transaksi = gagal/berhasil
Kalo async, ada status pending, yaitu belum jelas gagal/berhasil
karena belum ada reply dari yang berwenang.
> sejauh pikiran saya, interaksinya antar cabang & pusat saja.
> dan pusat itu sebagai central clearing house dari semua cabang, jadi
> semuanya memang harus lewat pusat.
> nah bisa dijelaskan contoh kasus yang melibatkan antar cabang?
Misalnya mutasi barang dari cabang A ke cabang B.
Atau penjualan dilakukan oleh cabang A,
tapi karena dia gak punya barangnya ngutang dulu dari cabang B.
> ada teknik untuk memastikan bahwa data local sudah 100% sesuai dengan pusat?
> dan sebaliknya?
Mana bisa dilakukan?
Datanya pusat pasti beda sama data cabang, karena di pusat ada semua
data, dan di cabang hanya ada datanya dia sendiri.
Kalopun mau dicek satu per satu record, maka akan boros bandwidth.
Misalnya satu cabang sehari ada 100 aktivitas, berarti 100 data harus
disync ke server.
Nah, kalo 100 itu mau dicek satu2, ya harus gelar FO sendiri ;p
Belum lagi kalo cabangnya ada 10.
Makanya biasanya kita cek pas kirim/terima data aja pake checksum (md5
atau sha).
Misalnya, datanya berformat json, kita gzip, setelah itu kita sha2sum.
Setelah itu, kirim gz nya dan sha2sum nya.
Di sisi penerima, diverifikasi isinya.
Kalo mau lebih secure, jangan cuma di-checksum, tapi di-sign juga.
Untuk memastikan yang kirim bukan orang lain.
> sekedar ide, gimana kalo SQL statements tersebut ditulis ke file selain juga
> ke database local, kemudian file ini dikirim ke pusat via SCP (port 22),
> terus dibuka oleh server pusat dan dimasukkan ke database pusat?
> ada yang pernah implementasi ini?
Daripada implement ini, mendingan kirim binlog aja bukan?
Formatnya udah optimized untuk keperluan ini.
Lagipula, gak selalu bisa serta merta SQL langsung dijalankan.
Soalnya biasanya ada business process yang harus dijalankan.
Misalnya, dari cabang kirim transaksi penjualan, di pusat harus approve dulu.
Pangki Arifin
| BIKIN NGILU AJA NI JAWABANNYA, MANTAPLAH INI KAWAND2 --- Pada Jum, 5/8/11, Endy Muhardin <endy.m...@gmail.com> menulis: |
|
|
Achmad Mardiansyah
BIKIN NGILU AJA NI JAWABANNYA, MANTAPLAH INI KAWAND2
Achmad Mardiansyah
> 2011/8/5 Achmad Mardiansyah<a.mard...@gmail.com>:
>> btw, kalo aplikasi reservasi tiket pesawat seperti yang ada di travel agent
>> gitu apakah menggunakan metode synchronous bukan yah? kalo dari yang saya
>> liat, mereka ngetik2 di konsole gitu, sehingga bisa jadi tipe aplikasinya
> Aplikasi transaksi keuangan harus selalu synchronous,
> soalnya harus langsung ketahuan transaksinya gagal atau berhasil.
> Kan urusannya mendebet deposit/rekening.
>
> Indikator sync/async itu bukan dilihat dari konsole atau webbased.
> Tapi dari status transaksinya.
> Kalo sync, status transaksi = gagal/berhasil
> Kalo async, ada status pending, yaitu belum jelas gagal/berhasil
> karena belum ada reply dari yang berwenang.
kan ya?
jika iya, pool ini dalam implementasinya seperti apa?
apa pake temporary tabel gitu? ntar kalo udah approved bakal dimasukin
ke tabel yang permanen.
>> sejauh pikiran saya, interaksinya antar cabang& pusat saja.
>> dan pusat itu sebagai central clearing house dari semua cabang, jadi
>> semuanya memang harus lewat pusat.
>> nah bisa dijelaskan contoh kasus yang melibatkan antar cabang?
> Misalnya mutasi barang dari cabang A ke cabang B.
> Atau penjualan dilakukan oleh cabang A,
> tapi karena dia gak punya barangnya ngutang dulu dari cabang B.
>
>
>> ada teknik untuk memastikan bahwa data local sudah 100% sesuai dengan pusat?
>> dan sebaliknya?
> Mana bisa dilakukan?
> Datanya pusat pasti beda sama data cabang, karena di pusat ada semua
> data, dan di cabang hanya ada datanya dia sendiri.
> Kalopun mau dicek satu per satu record, maka akan boros bandwidth.
> Misalnya satu cabang sehari ada 100 aktivitas, berarti 100 data harus
> disync ke server.
> Nah, kalo 100 itu mau dicek satu2, ya harus gelar FO sendiri ;p
> Belum lagi kalo cabangnya ada 10.
maksudnya gini om, gimana kalo saya mendesain sebuah tabel penjualan
yang isinya khusus untuk cabang tertentu. jadi kan ngak nyampur dengan
cabang lain toh?
desain ini hanya untuk tabel2 yang sync nya dari cabang ke pusat.
dengan metode ini, saya bisa compare table ini antara pusat & cabang
tertentu saja.
> Makanya biasanya kita cek pas kirim/terima data aja pake checksum (md5
> atau sha).
> Misalnya, datanya berformat json, kita gzip, setelah itu kita sha2sum.
> Setelah itu, kirim gz nya dan sha2sum nya.
> Di sisi penerima, diverifikasi isinya.
nah ngirim checksumnya pake jalur apa?
apa sama menggunakan jalur untuk ngirim data?
> Kalo mau lebih secure, jangan cuma di-checksum, tapi di-sign juga.
> Untuk memastikan yang kirim bukan orang lain.
>> sekedar ide, gimana kalo SQL statements tersebut ditulis ke file selain juga
>> ke database local, kemudian file ini dikirim ke pusat via SCP (port 22),
>> terus dibuka oleh server pusat dan dimasukkan ke database pusat?
>> ada yang pernah implementasi ini?
> Daripada implement ini, mendingan kirim binlog aja bukan?
> Formatnya udah optimized untuk keperluan ini.
bukannya binlog itu sebagai backup seluruh database ya?
kalo iya, ya berarti kegedean.
yang dikirimkan adalah SQL statements yang berhubungan dengan tabel
tertentu saja yang arahnya dari cabang ke pusat.
> Lagipula, gak selalu bisa serta merta SQL langsung dijalankan.
> Soalnya biasanya ada business process yang harus dijalankan.
> Misalnya, dari cabang kirim transaksi penjualan, di pusat harus approve dulu.
jika kirim data via email dari cabang ke pusat dan semuanya automatic
(begitu terima langsung eksekusi) berarti kan automatic approved? sama
aja toh dengan kirim file via scp yang dikompress & di sign-in?
btw, ada satu hal lagi yang masih jadi issue, yaitu timezone.
silahkan idenya dari rekan2 sekalian...
crazynuxer
>> asynchronous --> ini teknik sinkronisasi dimana 2 titik yg mau men-sync itu nggak perlu dalam modus "sama-sama online". Analoginya adalah telepon (synchronous)
>> dan SMS (asynchronous). Komunikasi menggunakan telepon akarn enabled kalo dua orang itu sama-sama ngangkat telpon-nya. Kalo pihak yang ditelpon kagak
>> ngangkat2 telpon-nya, kirim SMS, dan komunikasi asynchronous yg akan terjadi... :D
>
> Benar, gunakan metode ini menggnakan aplikasi service kecil. Jangan
> coba menggunakan mysql cluster atau mysql asynchronous replication
> jika belum memiliki pengalaman menggunakannya dalam network yang tidak
> stabil (since everything will go crazy).
>
>> Teknik async ini cukup suitable utk menjamah environment2 sistem terdistribusi yang nggak memiliki infrastruktur komunikasi yang bagus.
>> Caranya piye?
>> Salah satunya adalah EMAIL.
>
> Saya lebih suka menggunakan HTTPS, karena insyaalloh tidak akan ada
> ISP yang memblock port 80. Dan kenapa tidak HTTP, karena data perlu
> dienkripsi dahulu, sebelum berkelana di jagat internet.
setahu saya http itu 80 dan https itu 443 , cmiiw
ada juga teman yang mengimplementasikan dengan menulis ke file dengan
format mysql import
lalu dalam interval waktu tertentu diimport kedatabase ,
--
-biasakan bottom post dan delete yang tidak perlu
-everything will be okay in the end, if it's not okay, it's not the end
-tumbang tujuh kali, itu berarti kita harus mampu berdiri delapan kali
-If I Fail, I try again and again and again. Cause I Believe, there is
GAIN in aGAIN!"
-simpati: 08119625241
Achmad Mardiansyah
>> Saya lebih suka menggunakan HTTPS, karena insyaalloh tidak akan ada
>> ISP yang memblock port 80. Dan kenapa tidak HTTP, karena data perlu
>> dienkripsi dahulu, sebelum berkelana di jagat internet.
> setahu saya http itu 80 dan https itu 443 , cmiiw
> ada juga teman yang mengimplementasikan dengan menulis ke file dengan
> format mysql import
> lalu dalam interval waktu tertentu diimport kedatabase ,
dalam implementasi, koneksi SSL (https) bisa pake port berapa aja.
muhammad subair
Walaupun bukan sebagai developer, tetapi di sisi support, saya pernah
terlibat dengan implementasi sistem terdisitribusi yang cukup besar
dan berskala nasional ttapi dulu bukan pakai MySQL, melainkan database
lain yang belinya aja mahal bener. Alasan utama memang karena alasan
infrastruktur untuk menerapkan sistem terpusat. Akan tetapi setelah
dicoba 1 tahun lebih ternyata effort dan masalah yang ditimbulkan
synch ini sangat besar, sehingga kemudian diputuskan aplikasi ditulis
ulang untuk dibuat terpusat dan diusahkan mencari infrastruktur
khususnya koneksi di cabang yang lebih baik.
2011/8/6 Achmad Mardiansyah <a.mard...@gmail.com>:
> --
> Untuk memposting, silakan reply email ini atau kirim email baru ke alamat:
> mysql-i...@googlegroups.com
> Untuk berhenti keanggotaan, silakan kirim email kosong ke alamat:
> mysql-indones...@googlegroups.com
>
> Untuk melihat arsip milis, member, atau hal-hal lainnya silakan kunjungi
> alamat: http://groups.google.com/group/mysql-indonesia?hl=id
--
Muhammad Subair
+62 8176583311
Endy Muhardin
>
> berarti kalo async, bakal ada semacam pool gitu untuk naruh transaksi kan
> ya?
> jika iya, pool ini dalam implementasinya seperti apa?
> apa pake temporary tabel gitu? ntar kalo udah approved bakal dimasukin ke
> tabel yang permanen.
Iya, pakai tabel database biasa saja sudah cukup.
> maksudnya gini om, gimana kalo saya mendesain sebuah tabel penjualan yang
> isinya khusus untuk cabang tertentu. jadi kan ngak nyampur dengan cabang
> lain toh?
> desain ini hanya untuk tabel2 yang sync nya dari cabang ke pusat.
> dengan metode ini, saya bisa compare table ini antara pusat & cabang
> tertentu saja.
>
Maksudnya, seperti ini?
tbl_sales_cabang_a
tbl_sales_cabang_b
tbl_sales_cabang_c
Gitu?
Apa gak malah makin ajaib bentuknya?
Gimana kalo :
- mau rekap penjualan semua cabang.
- mau nambah cabang baru
> nah ngirim checksumnya pake jalur apa?
> apa sama menggunakan jalur untuk ngirim data?
Iya disamain aja gpp, tapi jangan dimasukkan ke zip yang sama.
Jadi tiap kirim ada 2 jenis file :
1. zip berisi data transaksi
2. checksum dari zip tersebut dan masing-masing file di dalamnya.
> bukannya binlog itu sebagai backup seluruh database ya?
> kalo iya, ya berarti kegedean.
> yang dikirimkan adalah SQL statements yang berhubungan dengan tabel tertentu
> saja yang arahnya dari cabang ke pusat.
Hmm maksud saya di atas bukan usulan beneran.
Cuma sekedar mengingatkan saja, fitur itu sudah ada di MySQL.
Kalo kita mau reimplement satu fitur yang sudah ada, *biasanya* itu
adalah jalan yang salah.
> jika kirim data via email dari cabang ke pusat dan semuanya automatic
> (begitu terima langsung eksekusi) berarti kan automatic approved? sama aja
> toh dengan kirim file via scp yang dikompress & di sign-in?
Ya beda dong.
Kalo kita terima data, maka kita akan bikin logic untuk memprosesnya
di dalam aplikasi kita.
Di sini kita bisa pasang logika untuk verifikasi dsb, dan bisa saja menolaknya.
Kalo langsung SQL insert, ya gak bisa diverifikasi dulu.
Kalopun mau, harus dilakukan melalui stored procedure dan trigger.
> btw, ada satu hal lagi yang masih jadi issue, yaitu timezone.
> silahkan idenya dari rekan2 sekalian...
Issuenya apa?
Kalo isunya adalah jam mesin yang beda2, ya pakailah ntp.
Untuk deployment terpisah antara app dan db saja, sudah harus pakai ntp.
Apalagi ini benar2 terdistribusi.
Nah, benar kan kata saya, banyak issue yang harus dihandle.
For the sake of discussion sih ok aja.
Tapi kalo mau implement di project beneran, mendingan disarankan cari
koneksi internet yang reliable aja lalu semuanya synchronous.
FYI : reliable gak harus bandwidth besar, contohnya ATM dan EDC, masih
survive bahkan pakai dialup connection atau GPRS.
Kami menjalankan aplikasi loket pembayaran listrik, pakai synchronous,
satu loket sehari ribuan transaksi no problem pakai GPRS.
Pakai JSON + HTTP Compression biasa aja.
Per transaksi 0.5 KB, seharian (1000 tx) ya cuma 500KB saja.
Minimarket selevel Indomaret, rata2 waktu service kasirnya adalah 3 - 5 menit.
Jam bukanya dari jam 7 pagi sampe jam 22 malam, yaitu 15 jam.
Dengan asumsi dia pakai satu kasir, maka maksimal jumlah sales yang
terjadi adalah
15 jam * 60 menit / 3 menit = 300 transaksi.
Kalo satu transaksi 1 KB, maksimal sehari 300 KB, sebulan 9 MB.
Langganan spidi paket termurah aja atau paket internet unlimited dari
operator seluler sudah cukup
malahan masih bisa langganan Naruto dan One Piece tiap minggu tanpa
menghabiskan quota ;p
Bener deh, pakai synchronous aja, sayang masa mudanya :)
Achmad Mardiansyah
thanks buat replynya...
yah seperti yang saya bilang, opsi nomer satu saya adalah memang untuk
membuat centralized aplication.
cuman saya mau siap2 aja kalo memang terpaksa membuat distributed
application.
makanya saya lempat wacana ini. dan memang banyak sekali issue yang
harus di solve.
hehehehe
On Aug 8, 8:47 am, Endy Muhardin <endy.muhar...@gmail.com> wrote:
> 2011/8/5 Achmad Mardiansyah <a.mardians...@gmail.com>:
>
>
> > berarti kalo async, bakal ada semacam pool gitu untuk naruh transaksi kan
> > ya?
> > jika iya, pool ini dalam implementasinya seperti apa?
> > apa pake temporary tabel gitu? ntar kalo udah approved bakal dimasukin ke
> > tabel yang permanen.
>
> Iya, pakai tabel database biasa saja sudah cukup.
>
> > maksudnya gini om, gimana kalo saya mendesain sebuah tabel penjualan yang
> > isinya khusus untuk cabang tertentu. jadi kan ngak nyampur dengan cabang
> > lain toh?
> > desain ini hanya untuk tabel2 yang sync nya dari cabang ke pusat.
> > dengan metode ini, saya bisa compare table ini antara pusat & cabang
> > tertentu saja.
>
> Maksudnya, seperti ini?
> tbl_sales_cabang_a
> tbl_sales_cabang_b
> tbl_sales_cabang_c
>
> Gitu?
> Apa gak malah makin ajaib bentuknya?
> Gimana kalo :
> - mau rekap penjualan semua cabang.
> - mau nambah cabang baru
create tabel baru. dari sisi desain memang ngak bagus karena itu
berarti arsitekturnya berubah.
dan bakal susah di maintenancenya.
>
> > nah ngirim checksumnya pake jalur apa?
> > apa sama menggunakan jalur untuk ngirim data?
>
> Iya disamain aja gpp, tapi jangan dimasukkan ke zip yang sama.
> Jadi tiap kirim ada 2 jenis file :
> 1. zip berisi data transaksi
> 2. checksum dari zip tersebut dan masing-masing file di dalamnya.
>
juga?
ntar datanya di modify, checksumnya pun juga bisa di modify dong? lah
wong jalur yang dipakai sama...
iya, rencananya memang mau pake synchronous. :-)
> --
> Endy Muhardinhttp://endy.artivisi.com
Endy Muhardin
>
> nah kalo ngirim checksumnya sama dengan data, bukannya itu ngak secure
> juga?
> ntar datanya di modify, checksumnya pun juga bisa di modify dong? lah
> wong jalur yang dipakai sama...
>
Harus dibedakan tujuannya, apakah untuk memastikan filenya gak corrupt
atau memastikan filenya gak diutak-atik orang.
Untuk yang pertama, checksum saja cukup.
Untuk yang kedua, harus pakai digital signature.
Disign pake private key, diverifikasi pake public key.
Achmad Mardiansyah
Harry Sufehmi
> size tertentu, maka sudah saat nya utk upgrade bandwith atau gunakan
> cara manual yaitu copy data ke hard disk external dan kirim lewat kurir.
This :-) di berbagai lokasi di Indonesia, seringkali ini adalah opsi
yang paling feasible lho ;)
Ada salah satu aplikasi saya yang perlu sync juga,
setelah banyak pertimbangan, akhirnya kita gunakan Flashdisk :) yang
lalu dikirim via pos atau kurir, he he.
Masa bodo dibilang low-tech, yang penting solusi tepat untuk kondisi
ybs tho ? :)
Di Flashdisk itu sendiri berisi file dengan format CSV - bukan MySQL dump,
agar :
(1) bisa dicek lagi oleh operator (ada yang rada paranoid, ya sudah,
kita fasilitasi saja)
(2) bisa dimanfaatkan untuk reporting internal mereka - karena file
CSV bisa dibuka di Excel.
Salam, HS